Actually, now that I'm thinking about what you're doing a bit more, I think you may want to use a DISCONNECT instead of an UNSUBSCRIBE. You should not reuse the subscription id, its something where you probably want to randomly generate it (or has to be unique to the client).
John On Mon, Jul 18, 2016 at 9:37 PM John D. Ament <johndam...@apache.org> wrote: > Ed, > > Huh ok. Knowing that you're getting destination does not exist helps > pinpoint the problem. > > I think I need someone like Justin, Andy, Martyn or Clebert to comment. > The Artemis code is explicitly deleting the queue on unsubscribe - > https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompSession.java#L325 > > Because you're using the same subscription ID, they're all going to get > the destination deleted. But I can't think of a reason why the broker > would delete the destination if its not temporary. > > John > > > > > On Mon, Jul 18, 2016 at 10:16 AM Ed Kaltenbach <ekaltenb...@ara.com> > wrote: > >> John, >> I usually send the same subscription ID. However, I did try it using >> unique subscription IDs for each client with Wildfly 9 and I still saw the >> same behavior. >> >> Justin Bertram suggested that I open an issue on >> https://issues.apache.org/jira/browse/ARTEMIS. I did open an issue. >> The issue number is 630. I included source code. ( >> https://issues.apache.org/jira/browse/ARTEMIS-630?jql=project%20%3D%20ARTEMIS >> ) >> >> I have also attached a test application to this email. Run multiple >> instances of the program attached. Stagger the starts by a minute or so. >> As soon and one instance of the program completes, all other instances will >> start having problems sending messages to the topic. The server will send >> a response that says "Destination does not exist\c jms.topic.ACRS_Exit". >> If you start another instance then all other running instances will start >> receiving messages and will be able to send messages. >> >> Here is the way STOMP and the JMS topic is defined in the Wildfly >> standalone.xml: >> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> >> <server name="default"> >> <security-setting name="#"> >> <role name="guest" delete-non-durable-queue="true" >> create-non-durable-queue="true" consume="true" send="true"/> >> </security-setting> >> <address-setting name="#" >> message-counter-history-day-limit="10" page-size-bytes="2097152" >> max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" >> dead-letter-address="jms.queue.DLQ"/> >> <http-connector name="http-connector" >> endpoint="http-acceptor" socket-binding="http"/> >> <http-connector name="http-connector-throughput" >> endpoint="http-acceptor-throughput" socket-binding="http"> >> <param name="batch-delay" value="50"/> >> </http-connector> >> <in-vm-connector name="in-vm" server-id="0"/> >> <http-acceptor name="http-acceptor" >> http-listener="default"/> >> <http-acceptor name="http-acceptor-throughput" >> http-listener="default"> >> <param name="batch-delay" value="50"/> >> <param name="direct-deliver" value="false"/> >> </http-acceptor> >> <in-vm-acceptor name="in-vm" server-id="0"/> >> <acceptor name="stomp-acceptor" >> factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory"> >> <param name="protocols" value="STOMP"/> >> <param name="port" value="61613"/> >> </acceptor> >> <jms-queue name="ExpiryQueue" >> entries="java:/jms/queue/ExpiryQueue"/> >> <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/> >> <jms-topic name="ACRS_Exit" >> entries="java:/jms/topic/ACRS_Exit"/> >> <connection-factory name="InVmConnectionFactory" >> entries="java:/ConnectionFactory" connectors="in-vm"/> >> <connection-factory name="RemoteConnectionFactory" >> entries="java:jboss/exported/jms/RemoteConnectionFactory" >> connectors="http-connector"/> >> <pooled-connection-factory name="activemq-ra" >> transaction="xa" entries="java:/JmsXA >> java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/> >> </server> >> </subsystem> >> >> Thanks, >> Ed >> >> >> -----Original Message----- >> From: John D. Ament [mailto:johndam...@apache.org] >> Sent: Sunday, July 17, 2016 11:28 AM >> To: dev@activemq.apache.org >> Subject: Re: STOMP server quits sending to all subscribers when one >> client disconnects >> >> Ed, >> >> If you can share sample code that would be great. I'm curious though, >> what are you sending as your subscription ID? It looks like if all clients >> send the same subscription ID what you're describing could happen. >> >> John >> >> On Thu, Jul 14, 2016 at 5:10 PM Ed Kaltenbach <ekaltenb...@ara.com> >> wrote: >> >> > I am using Wildfly 10.0.0 Final with the built-in ActiveMQ Artemis. I >> > configured ActiveMQ-Artemis to support STOMP. All of my clients use >> > STOMP to connect to a JMS topic. >> > All of my code is working great. I have multiple clients connecting >> > via STOMP and all are able to send and receive messages. The one >> > issue that I have occurs when one of my client applications exits or >> > disconnects from the STOMP server. When one of the clients shuts down >> > or disconnects from the socket, all of the other client applications >> quit receiving messages. >> > If I start a new client application, as soon as it sends a SUBSCRIBE >> > message than all of the other client applications, that had previously >> > sent SUBSCRIBE messages, will begin receiving messages again from the >> > subscribed JMS topic. >> > I have sample client applications in both Java and C# that illustrate >> > the problem. >> > I originally saw this problem when using Wildfly 9.0.2. I posted to >> > the HornetQ developers forums and was advised to try Wildfly 10 and >> > ActiveMQ-Artemis. However, upgrading to the newer versions did not >> > fix the problem. >> > >> > Has anybody else seen this behavior? Does anybody have any >> > suggestions how to fix or work around the problem? >> > >> > Like I said above, I have sample client applications that illustrate >> > the problem that I would be happy to share. >> > >> > Thanks, >> > Ed >> > >> >
