> I've been trying to resolve this issue for a while
> now with a great deal of confusion and frustration.
> We are deploying to GlassFish v2ur2 in our production
> environment. This is a clustered environment using a
> REMOTE JMS cluster. (2 glassfish instances and 2
> openMQ JMS brokers) Our application used EclipseLink
> 1.1.1 as its JPA implementaiton. The issue that we
> have is that we want to utilize the EclipseLink Cache
> Coordination functionality. This will allow both
> instances of our application to stay in sync with
> each other. Ensuring that when one instance updates
> an object in the cache the other application instance
> receives those updates or invalidates the object.
> EclipseLink does this very easily using a JMS Topic.
(snip>
> GlassFish admin console does not
> provide us a way to turn off sharing, nor is there
> any other way to accomplish this via configuration.
Although the current behaviour (apart from that incorrect error message) is by design I agree it is too restrictive and we (Sun) need to provide the means to disable connection sharing when required.
I am currently looking into adding a new connection factory property this would do that.
> So I manage to handle this in Spring by applying
> advice to the connection factory when a connection is
> requested:
(snip)
Interesting stuff, though I hope you appreciate that you're using non-public API here and I can't give any promises as to how it will behave.
However I would say that if you set a different clientID on every connection then it shouldn't matter whether you set imqEnableSharedSubscriptions. If two subscriptions use different clientID then they will not be shared.
>
> The issue now is that when we deploy our application
> into our test environment, that is clustered the same
> as Production, we see instability on the server. One
> server becomes unstable and inevitably runs out of
> memory. (This does not happen on my local desktop
> clustered environment) The solution in test was to
> disable one JMS instance. This seems to resolve the
> instability but leaves me wondering if the
> environment is configured correctly? as my local
> environment seems to work well.
I can't see any obvious reason why the change you have made (which are client-side) would make the broker run out of memory.
How does the broker behave as it "becomes unstable"? Is one of the destinations becoming very large? I would suggest using the MQ admin commands to monitor what is going on. There's a whole section in the MQ admin guide on memory management.
If you have a support licence I would suggest contacting Sun support for help.
Or you could ask in the MQ email or online forum, which is read by MQ users and developers unconnected with Glassfish.
> Still with me? Thanks...
> Our infrastructure team contacted a Sun consultant
> that helped us configure the environments in the past
> and the consultants recommendation was to not use the
> managed JMS objects for EclipseLink but rather we
> should be using JGroups for our messaging
> communications. Now this seems rather odd to me. Why
> should I simply turn my back on the Managed JMS
> Objects in the container in preference for some other
> library, that will inevitably go directly to the JMS
> servers for the communication? Does this really make
> sense? Is this really the recommendation of Sun?
All I can say is that here in the MQ team we're keen to prevent the "shared subscriptions" feature getting in the way of you using MQ with EclipseLink, and that I am looking into how this might be achieved.
Nigel
(MQ team)
[Message sent by forum member 'nigeldeakin' (nigeldeakin)]
http://forums.java.net/jive/thread.jspa?messageID=353544