activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: STOMP server quits sending to all subscribers when one client disconnects
Date Tue, 19 Jul 2016 01:37:44 GMT
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 <ekaltenbach@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:johndament@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 <ekaltenbach@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message