Thank you for taking the time to reply Nigel.
[i]"If two subscriptions use different clientID then they will not be shared."[/i]
I'll make that change and test it out. I agree that it is cleaner than setting the imqEnableSharedSubscriptions variable. I still need to perform this step with reflection as there is no way to set the clientID down in the application without an exception being thrown.
Code for the class com.sun.messaging.jms.ra.ConnectionAdapter reads as follows:
145 public void
146 setClientID(String clientId)
147 throws JMSException
148 {
149 _loggerJC.entering(_className, "setClientID()", clientId);
150 //System.out.println("MQRA:CA:setClientID-to-"+clientId);
151 if (!inACC) {
152 throw new com.sun.messaging.jms.JMSException("MQRA:CA:Unsupported-setClientID()");
153 }
154 checkClosed();
155 xac.setClientID(clientId);
156 }
So the way I am currently setting it is all that is available to me. Setting it down in the application always causes an exception to be raised. In reality, this is the best place to set it as GlassFish cannot dynamically assign a unique clientID from the admin console and to assign a unique clientID from with EclipseLink, I would need to make code changes to the EclipseLink library. (not something that I would want to do) This seems to be the least intrusive way to accomplish the goal.
[i]
"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."[/i]
Its not the broker that is running out of memory but rather the GlassFish instance. For some reason when we have a cluster of 2 brokers running as a stand-alone cluster (not managed by GlassFish) and we have a cluster of 2 GlassFish instances, everything seems stable when both clusters come up and run. It is when we deploy the application and start accessing it that one GlassFish instance becomes unstable and runs out of memory. We end up having to kill the instance and restart it and it then seems to be stable but the other GlassFish instance that was stable initially becomes unstable and runs out of memory. The only resolution to the problem that we found was to bring down the second instance of OpenMQ, then GlassFish seems to be stable.
I'll have to watch the brokers for any unusual behavior during this instability to see if there is something related.
[i]"If you have a support licence I would suggest contacting Sun support for help."
[/i]
We do have license support from Sun and we did contact support for help. This was not the experience we expected. After contacting support, we received an initial phone call to confirm the support ticket, and got routed around to multiple individuals on the phone call, to properly route our issue. Finally, we were told that someone would be calling us back to work on the issue with us. 7 days later, after receiving no phone call, we called back to follow up on what happened and were told that the support representative was waiting for our log files. It would have been nice if someone would have shared that information with us rather than making us wait 7 days and have to pursue the case ourselves.
[i]
"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."[/i]
I really appreciate you taking the time to help me with this issue Nigel. The help you and Linda have provided me is great and very much appreciated. Thank you and Linda for your patience.
Chris...
[Message sent by forum member 'cmathrusse' (cmathrusse)]
http://forums.java.net/jive/thread.jspa?messageID=353618