> As a follow up, I removed the setting of
> imqEnableSharedSubscriptions = false and relyed upon
> the setting of the clientID alone. The end result was
> that I received the Durable Exception message again.
> [i]
> Caused by: com.sun.messaging.jms.JMSException:
> [ADD_CONSUMER_REPLY(15)] [C4036]: A broker error
> occurred. :[412] [B4135]: Cannot add durable consumer
> null. No ClientID was set on connection. user=admin,
> broker=CMATHRUSXP.sybase.com:7001(4521)[/i]
>
> So even though I am setting the clientID on the
> com.sun.messaging.jms.ra.ConnectionAdapter class, it
> seems that it is truly not set. So my only option
> here is to set imqEnableSharedSubscriptions = false .
OK. Thanks for trying it. Certainly setting ClientID through the supported API would do a bit more than just set that field in the conneciton; for example it sends ClientID to the broker.
> Its not the broker that is running out of memory but rather the GlassFish instance
Ah, I see. Obviously there are a lot of components running in that JVM (such as EclipseLink). I'm not an expert on EclipseLink, but is there a way of monitoring whether it is replicating data between the instance correctly?
> The only resolution to the problem that we found was to bring down the second instance of OpenMQ, then GlassFish seems to be stable.
Do you mean "the second instance of Glassfish"?
> We do have license support from Sun and we did contact support for help. This was not the experience we expected
Oh dear. I'll pass your comments on to management.
Nigel
[Message sent by forum member 'nigeldeakin' (nigeldeakin)]
http://forums.java.net/jive/thread.jspa?messageID=353731