Cache Coordination via JMS

[cmathrusse]

Our application is running within a GlassFish v2 cluster that utilizes a REMOTE JMS Cluster. There are only 2 server instances within the cluster at this time. I've provided EclipseLink with an implementation of SessionCustomizer so I can utilize a JMS Topic to perform my Cache Coordination. This proved to be a challenge as GlassFish attempts to share the subscription to the topic when deployed in a cluster. Per one of the Sun engineers:

The behavior is that we are "sharing" the consumer across the cluster.
This behavior is only turned on for a glassfish cluster.

What does share mean ???

For durables what it means is:
if you create two durables with the same name and same clientID on different servers ... they will be considered a "single" durable.
e.g.:
You send 10 messages to topic foo [and create two subscribers with a clientID of cid1 and a durable name of dname]
[gf instance 1: cid1, dname on foo] gets 5 messages
[gf instance 2: cid1, dname on foo] - gets 5 messages

For non-durable subscribers:
If you create two subscribers on the same topic with the same clientID, they will share messages (same as the above durables case)

After reading through this I figured out that I don't want the subscription shared. I needed to turn off sharing to prevent the messages from being distributed over the 2 servers. This was a bit of a challenge but I managed to do this by creating a custom implementation of an InitialContextFactory, binding the Topic Factory into the Spring container and applying some advice to the connection factory to ensure that the connection does not share subscriptions. This works well in my local GlassFish clustered environment. But when I gave it to the Infrastructure Group to deploy in their test environment their GlassFish instances seemed to have issues. They contacted a Sun consultant that helped them configure the environment and he recommended that we not use JMS for EclipseLink Cache Coordination but rather JGroups. I read over their documentation and this is a completely proprietary messaging implementation using IP Multicast. While this looks like a good library, this would be a custom implementation that would not interface well with EclipseLink and would require me to do a considerable amount of work.

Can anyone speak to this? Personally, I find that the JMS implementation of Cache Coordination seems very simple and easy to use. I don't see where there would be any disadvantages to using it nor do I see any reason why I should utilize JGroups.

Thanks for the help...

Chris Mathrusse
christopher.mathrusse@...
Sybase, Inc

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

[James Sutherland]

I'm no Glassfish expert, but I would assume there should be someway to configure JMS to have it function as needed.  At worst case you could plugin some third party JMS implementation, such as Oracle AQ or other such JMS providers.

Another option is using RMI cache coordination in EclipseLink.

EclipseLink does not currently support JGroups cache coordination, although we have done this work before in TopLink, so please log an enhancement request for this.  It should not be too much work to get working on your own if you are adventurous.

cmathrusse wrote:

Our application is running within a GlassFish v2 cluster that utilizes a
REMOTE JMS Cluster. There are only 2 server instances within the cluster
at this time. I've provided EclipseLink with an implementation of
SessionCustomizer so I can utilize a JMS Topic to perform my Cache
Coordination. This proved to be a challenge as GlassFish attempts to share
the subscription to the topic when deployed in a cluster. Per one of the
Sun engineers:

The behavior is that we are "sharing" the consumer across the cluster.
This behavior is only turned on for a glassfish cluster.

What does share mean ???

For durables what it means is:
if you create two durables with the same name and same clientID on
different servers ... they will be considered a "single" durable.
e.g.:
You send 10 messages to topic foo [and create two subscribers with a
clientID of cid1 and a durable name of dname]
[gf instance 1: cid1, dname on foo] gets 5 messages
[gf instance 2: cid1, dname on foo] - gets 5 messages

For non-durable subscribers:
If you create two subscribers on the same topic with the same clientID,
they will share messages (same as the above durables case)

After reading through this I figured out that I don't want the
subscription shared. I needed to turn off sharing to prevent the messages
from being distributed over the 2 servers. This was a bit of a challenge
but I managed to do this by creating a custom implementation of an
InitialContextFactory, binding the Topic Factory into the Spring container
and applying some advice to the connection factory to ensure that the
connection does not share subscriptions. This works well in my local
GlassFish clustered environment. But when I gave it to the Infrastructure
Group to deploy in their test environment their GlassFish instances seemed
to have issues. They contacted a Sun consultant that helped them configure
the environment and he recommended that we not use JMS for EclipseLink
Cache Coordination but rather JGroups. I read over their documentation and
this is a completely proprietary messaging implementation using IP
Multicast. While this looks like a good library, this would be a custom
implementation that would not interface well with EclipseLink and would
require me to do a considerable amount of work.

Can anyone speak to this? Personally, I find that the JMS implementation
of Cache Coordination seems very simple and easy to use. I don't see where
there would be any disadvantages to using it nor do I see any reason why I
should utilize JGroups.

Thanks for the help...

Chris Mathrusse
[e-mail]
Sybase, Inc

[cmathrusse]

I'll open an enhancement request. I've looked at the code and, you are correct, it doesn't look too difficult (and I am adventurous) so I may give it a try, but I still think that JMS is the simplest implementation and the most reliable.

Chris Mathrusse
christopher.mathrusse@...
Sybase, Inc
One Sybase Drive
Dublin, CA 94568
[phone]

James Sutherland <jamesssss@...>
Sent by: eclipselink-users-bounces@...

06/30/2009 09:45 AM

Please respond to
EclipseLink User Discussions <eclipselink-users@...>

To	eclipselink-users@...
cc
Subject	Re: [eclipselink-users] Cache Coordination via JMS

I'm no Glassfish expert, but I would assume there should be someway to
configure JMS to have it function as needed.  At worst case you could plugin
some third party JMS implementation, such as Oracle AQ or other such JMS
providers.

Another option is using RMI cache coordination in EclipseLink.

EclipseLink does not currently support JGroups cache coordination, although
we have done this work before in TopLink, so please log an enhancement
request for this.  It should not be too much work to get working on your own
if you are adventurous.



cmathrusse wrote:
>
> Our application is running within a GlassFish v2 cluster that utilizes a
> REMOTE JMS Cluster. There are only 2 server instances within the cluster
> at this time. I've provided EclipseLink with an implementation of
> SessionCustomizer so I can utilize a JMS Topic to perform my Cache
> Coordination. This proved to be a challenge as GlassFish attempts to share
> the subscription to the topic when deployed in a cluster. Per one of the
> Sun engineers:
>
> The behavior is that we are "sharing" the consumer across the cluster.
> This behavior is only turned on for a glassfish cluster.
>
> What does share mean ???
>
> For durables what it means is:
> if you create two durables with the same name and same clientID on
> different servers ... they will be considered a "single" durable.
> e.g.:
> You send 10 messages to topic foo [and create two subscribers with a
> clientID of cid1 and a durable name of dname]
> [gf instance 1: cid1, dname on foo] gets 5 messages
> [gf instance 2: cid1, dname on foo] - gets 5 messages
>
> For non-durable subscribers:
> If you create two subscribers on the same topic with the same clientID,
> they will share messages (same as the above durables case)
>
> After reading through this I figured out that I don't want the
> subscription shared. I needed to turn off sharing to prevent the messages
> from being distributed over the 2 servers. This was a bit of a challenge
> but I managed to do this by creating a custom implementation of an
> InitialContextFactory, binding the Topic Factory into the Spring container
> and applying some advice to the connection factory to ensure that the
> connection does not share subscriptions. This works well in my local
> GlassFish clustered environment. But when I gave it to the Infrastructure
> Group to deploy in their test environment their GlassFish instances seemed
> to have issues. They contacted a Sun consultant that helped them configure
> the environment and he recommended that we not use JMS for EclipseLink
> Cache Coordination but rather JGroups. I read over their documentation and
> this is a completely proprietary messaging implementation using IP
> Multicast. While this looks like a good library, this would be a custom
> implementation that would not interface well with EclipseLink and would
> require me to do a considerable amount of work.
>
> Can anyone speak to this? Personally, I find that the JMS implementation
> of Cache Coordination seems very simple and easy to use. I don't see where
> there would be any disadvantages to using it nor do I see any reason why I
> should utilize JGroups.
>
> Thanks for the help...
>
> Chris Mathrusse
> christopher.mathrusse@...
> Sybase, Inc
>
>


-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink ,  http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki:  http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums:  http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book:  http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/Cache-Coordination-via-JMS-tp24261354p24275419.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.

_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users



_______________________________________________
eclipselink-users mailing list
eclipselink-users@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-users