Ed,
Sorry one more thing to try. Can you try against the 1.3 standalone broker
instead of the 1.1 that ships w/ Wildfly? I'm wondering if the auto
creation feature fixes this error.
John
On Tue, Jul 19, 2016 at 11:35 AM Ed Kaltenbach <ekaltenb...@ara.com> wrote:
>
>
> I just modified my test client application so that each client has a
> unique subscription id. Here is the new code:
>
>
>
> String destID = String.format("%d", System.currentTimeMillis());
>
> msg = "SUBSCRIBE\n";
>
> msg = msg + "destination:" + topicName + "\n";
>
> msg = msg + "id:" + destID + "\n";
>
> msg = msg + "ack:auto\n";
>
> msg = msg + "\n";
>
> msg = msg + '\0';
>
>
>
> I still see the same error. When one of the clients ends, the other
> clients start getting the “AMQ339001\c Destination does not exist\c
> jms.topic.ACRS_Exit” error when they try to SEND a message to the JMS topic.
>
>
>
> It all seems to work fine until one of the clients UNSUBSCRIBES,
> DISCONNECTS, and shutdowns the socket. All of the clients were receiving
> all of the messages.
>
>
>
> Here is some new information. If I run multiple instances of my test
> client application (the new one that has unique subscription IDs for each
> client) and then I kill one using “ctrl-c” then I see the same error. The
> other client instance starts getting the “AMQ339001\c Destination does not
> exist\c jms.topic.ACRS_Exit” error when it tries to SEND a message to the
> JMS topic. Therefore, I don’t think the problem is related to the
> “UNSUBSCRIBE” or “DISCONNECT” messages because they were never sent when
> the problem started.
>
>
>
> Ed
>
>
>
> *From:* Martyn Taylor [mailto:mtay...@redhat.com <mtay...@redhat.com>]
> *Sent:* Tuesday, July 19, 2016 9:00 AM
> *To:* dev@activemq.apache.org
> *Cc:* Ed Kaltenbach <ekaltenb...@ara.com>
>
>
> *Subject:* Re: STOMP server quits sending to all subscribers when one
> client disconnects
>
>
>
> Hi Ed,
>
>
>
> You mentioned that using a unique subscription ID does not resolve this
> issue. Can you confirm that using different subscription IDs across all
> your clients is the same? Were you seeing subscription semantics before
> the error (i.e. was every subscription seeing every message?).
>
>
>
> I've taken a quick look and there may be an issue in the STOMP protocol
> handler. The subscription ID is used to identify consumer queues, this
> could cause some issues with multiple clients using the same subscription
> ID during unsubscribe. The subscription ID only needs to be unique within
> connections https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE
>
>
>
> Thanks
> Martyn
>
