Hi Shreedhar,
Thank you again for the speedy reply.
>> The DAS also seems to participate in this as spectator, but as the
>> processing to join in happens at start up time (see stacktrace below),
>> you have to restart the DAS first.
>>
> You should not have to restart the DAS. When a new cluster is created,
> DAS joins that group and being the first in the group becomes the master
> node that would own the responsibility of sending out cluster member
From the following I had the impression a DAS restart was required:
1. I checked the sequence in the source of creation of a cluster and its
instance and of starting it, but in the DAS's process the
GroupManagementServiceImpl class's join method was not invoked. Am I
searching for the wrong method invocation?
2. I took a thread dump of the DAS process after starting the cluster,
there were no GMS/JXTA related looking threads. After restarting the DAS
I took another thread dump, and found about ten GMS/JXTA related looking
threads.
With "related looking" I mean either the thread name had "jxta" in it
("StdRendezVousService Timer for urn:jxta:uuid-28...") or the trace had
(net.jxta.impl...).
> lifecycle events. Also, when DAS is shutdown and restarted, it wold
> join the GMS group of each cluster defined within the domain.
> At what point do you see the stack trace below?
The stacktrace was self-induced for the investigation, it was not caused
by GF.
Thanks,
Dies