Thank you very much for your detailed answers!
Shreedhar Ganapathy schrieb:
> Hi Michael
> Sorry for the late response. We had a pretty intense storm here in
> California and my home lost power for about 30 hours.
no problem. We don't have these kind of weather conditions in Bavaria ;)
> See below for my response:
> Michael Bien wrote:
>> Hello,
>>
>> I have two questions regarding the messaging implementation of shoal.
>>
>> GroupHandle.sendMessage(...) throws GMSException for "any exception
>> while sending message wrapped into GMSException".
>> Do I interpret that correctly that the caller can be sure that the
>> message arrived if he hasn't caught any exception? Or is a "answer
>> message" recommended to make sure that messages don't get lost?
> The API was written with the expectation that exceptions occurring at
> the point of sending a message would be reported. It did not have any
> notion of delivery guarantees. That said, if the underlying
> implementation provided guaranteed message delivery then that would be
> of added benefit.
> The current provider implementation uses Jxta wherein unicast (peer to
> peer) messages use TCP and hence get the reliability of the transport.
> So if your message is being sent to a particular member of the group
> that would go through the TCP channel. Where the message is
> group-wide, it uses UDP which can potentially lose messages under
> load. We don't yet have a reliable multicast layer in this provide
> implementation.
OK, I forgot that JXTA uses TCP for unicast messaging. Thats reliable
enough for now.
>> Are all CallBacks registered with gms.addActionFactory(new
>> ???ActionFactoryImpl(callback)); called from the same thread?
> Each Signal corresponding to an ??ActionFactoryImpl is constructed on
> a dedicated thread from a threadpool with the exception of
> MessageSignal as putting each Message Signal on a separate thread
> would result in ordering issues. For Signals other than MessageSignal
> the call backs could potentially be by different corresponding
> ??Signal threads if the same event is occurring in very quick
> succession before an earlier callback invocation has finished. For
> instance, a FailureNotificationSignal call back could be on multiple
> threads if multiple failure events occur at the same time and an
> earlier callback.processNotification() has not yet finished.
Thank you, thats an important information.
>> And also (just because I am curious ;) ) is there an update interval
>> for the synchronization of the DistributedStateCash?
> The DistributedStateCache synchronizes for each put and also when a
> new member join arrives and a state sync needs to be done.
>>
>> I am currently attempting to distribute a ForkJoinPool (jsr166y -
>> fork join framework) over the network with the help of shoal and have
>> to make sure that every task/computed result arrives to its
>> destination node (https://fishfarm.dev.java.net/).
> We need to study this more. Let us know if any new requirements arise
> out of this. We would be happy to help.
Thanks again,
I have updated the webpage with an code sample. The distribution is
already working but the smallest distributable unit is currently a
submitted ForkJoinTask, the next step is the distribution of sub tasks
(any task in the ForkJoin framework has the ability to fork other tasks
-> sub tasks). But this will require more modifications to the ForkJoin
Framework.
Don't expect much development in the next 5 weeks, I have to write some
exams first ;)
best regards,
Michael
>
> Shreedhar :)
>
>>
>> thank you in advance,
>>
>> Michael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
>> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
>