I concur with what Linda has written. As she explained, error message is misleading; I've submitted a bug to correct it.
This will show up as
http://bugs.sun.com/view_bug.do;?bug_id=6852018
in due course.
Until such time as the sharing of subscriptions can be disabled, then (other than using non-clustered instances) the
workaround is to set clientID.
Note that if you set the same clientID in both Glassfish instances then the non-durable subscription will be "shared"
across the two instances, with each message from the topic being delivered to one or the other instance, but not both.
If this isn't what you want then you need to set a different value of clientID for each clustered instance (which I know
can be administratively inconvenient).
Nigel
Linda Schneider wrote:
> I've added some information to the issue tracker as well ...
>
> I'm not that familiar with how EclipseLink uses MQ ... is there a way to
> update the activationSpec to set clientID ???
>
> (CC'ing someone off the alias who has a better understanding of the
> MQ/GF integration and may be able to help you configure a clientID to
> workaround this issue ... sorry I'm more standalone OpenMQ focused)
>
> At the moment the only workarounds I see are to:
>
> 1. set the clientID to something non-null in the activation
> specification (or in any of the other locations) - note if you use ${u}
> it will substitute in a username.
>
> or
>
> 2. Do not cluster the glassfish instances
>
> NOTE: If you have purchased support for glassfish, you can escalate to
> get one/both of the possible changes (see below) in the current product
> back ported either to the broker or the MQ resource adapter.
>
> What changes are going in for this issue ...
>
> - MQ/GF *is* putting a workaround inside of the ResourceAdapter where
> you could set: useSharedSubscriptionInClusteredContainer in the
> activation spec which would bypass this behavior in our next release.
>
> - I'll also file a bug to allow you turn turn the behavior off on a
> per-MQ broker (and per-destination) basis in our next release. (e.g. so
> someone could just upgrade the broker w/o touching glassfish)
>
> - I'll file a bug to add support for generating a unique clientID
> automatically for a connection (similar to the ${u} syntax above but the
> ID would be random) (probably post: 4.4)
>
>
> To clarify - the behavior is not that we are converting your consumer to
> be durable (the message is misleading) its that we are "sharing" them
> across the cluster.
>
> Also, 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)
>
> Obviously if there is no clientID, the durables can't be shared which
> generated the error you are seeing..
>
> -- Linda
>
>
>> Our production environment is a clustered Glassfish v2ur2 environment.
>> The cluster is configured to use an external (REMOTE) instance of
>> OpenMQ that is also configured as a cluster. Our application is using
>> EclipseLink for the JPA implementation. We want to use a Coordinated
>> Cache to keep application Entities in sync but have run into a
>> showstopper due to an open bug in GlassFish.
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6580
>>
>> While EclipseLink is calling topicSession.createSubscriber(topic) and
>> clearly this is for a non-durable subscription, Glassfish is
>> attempting to make this a durable subscription, but without a client
>> ID. Of course this results in an exception being raised and everything
>> goes to hell. So how can we get around this issue? Does OpenMQ expose
>> an InitialContext where EclipseLink can connect to acquire the
>> ConnectFactory and Topic, allowing us to by-pass Glassfish all together?
>>
>> At this point Glassfish is the impedance and I can't find any options
>> around this issue.
>> [Message sent by forum member 'cmathrusse' (cmathrusse)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=351305
>