> I can see multicast traffic (? it's addressed to the multicast address
> I've configured, anyway)
> that seems to be related to cluster events (instances stopping/starting)
> but nothing that looks like a session being replicated (or copied
> over) - even when I
> tweak the load balancer to send a client to one node, have them log in
> and then point the
> LB to the other node.
>
Can you restate the steps you followed for the above to help our folks
reproduce this behavior?
I assume you are following the High Availability
<
http://docs.sun.com/app/docs/doc/819-3679> guide.
Just to reaffirm. Your app is availability-enabled and if its a web app
it has the <distributable/> tag in the web.xml.
And at the moment you are using clusterjsp web app. Right?
> Clients have to login again when they hit the other node, so something
> is not right I think, but
> I can't understand why some traffic seems to make it across and other
> traffic doesn't.
>
Do you see any sessions replicated at all or none?
> Do both sessions and cluster events use GMS? Are there any differences?
>
Session replication component uses GMS only for cluster lifecycle events
such as an instance joining, leaving or failing. In other words, GMS
reports cluster lifecycle events to appserver components such as
in-memory replication. GMS uses a service provider implementation which
has group communication semantics and it employs Jxta for its
communications.
In-memory replication component also uses Jxta directly for its
replication traffic using Jxta's JxtaBiDiPipe which is an bidirectional
socket abstraction.
> (URLs are fine at this point :) - I've read
> https://shoal.dev.java.net/ShoalDesignDocument.html
> which was quite useful but not GF specific).
>
> Will have a look at btrace, thanks.
>
> Does anyone know of any introductory reference material on writing a
> GMS client?
>
http://blogs.sun.com/shreedhar/entry/shoal_clustering_101
hth
Shreedhar
> Thanks again.
>
>
>>> From a quick glance over the shoal design docs, it looks like it would
>>> be possible to add a SPECTATOR member to the cluster who could receive
>>> messages
>>> (and log/graph them etc.) without disrupting cluster operation or
>>> requiring a lot of debug-level
>>> logging on the cluster instances themselves.
>>>
>>>
>> Very good thought. A Spectator member collecting monitoring information
>> about cluster members would be a very useful way to present information on
>> cluster messaging and collecting historical information on cluster lifecycle
>> events.
>>
>>> Does anybody know of such a tool, or where I could look to get started
>>> writing my own?
>>>
>>>
>> btrace comes to mind. http://btrace.dev.java.net
>> We are beginning to use it for debug purposes in our load tests and I am
>> hoping that will lead us to write a utility on the above lines.
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>