Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

tejas13

Hi All,
 
Thank in Advance.

Previously we were using version 5.12.0. That time my code was working fine. Subscriber never get offline automatically.

Recently we upgraded to version 5.14.5 as most stable version and new features

I found that my Active Durable Subscriber status is changing automatically to offline Durable Subscriber.

I am using below code for connection.
 
public class ReceiverFor_ECRE_TO_SEQ_Topic {
        private static final Logger logger = Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);

        private TopicSession qsen = null;
        private String JNDI_PROVIDER_URL = null;
        private String topicName = null;
        private String jmsUid = null;
        private String jmsPwd = null;
        private Topic topic = null;
        private ConnectionFactory connFactory;
        private TopicConnection queueConn;

        public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
                this.topicName = topicName;
                this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
                this.jmsUid = jmsUid;
                this.jmsPwd = jmsPwd;
        }

        public void listenTopic() {
                try {
                        Properties env = new Properties();
                        env.put(Context.INITIAL_CONTEXT_FACTORY, Constants.INITIAL_CONTEXT_FACTORY);
                        env.put(Context.PROVIDER_URL, System.getProperty(Context.PROVIDER_URL, JNDI_PROVIDER_URL));
                        env.put(Context.SECURITY_PRINCIPAL, jmsUid);
                        env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
                        env.setProperty("prefetchPolicy.durableTopicPrefetch", "1000");
                        InitialContext inictx = new InitialContext(env);

                        // lookup the queue object
                        topic = (Topic) inictx.lookup(topicName);
                        // lookup the topic connection factory
                        connFactory = (ConnectionFactory) inictx.lookup(Constants.CONN_FACTORY);

                        // System.out.println("1");
                        if (setupJMS()) {

                                isJMSConnected = true;
                                /*
                                 * while(true) { }
                                 */
                        } else {

                                listenTopic();

                        }
                } catch (NamingException ex) {
                        // ex.printStackTrace();
                        logger.error("Unable to connect Server for ECRE Topic");

                        try {
                                Thread.sleep(5000);
                                listenTopic();
                        } catch (InterruptedException ex1) {
                                // ex.printStackTrace();
                                logger.error("Unable to connect  Server for ECRE Topic");
                        }
                }
        }

        public boolean setupJMS()
        {
                try {

                        // create a queue connection
                        String consumerName = ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_SEQ_TOPIC_CONSUMER_Id);
                       
                        queueConn = (TopicConnection) connFactory.createConnection();
                        queueConn.setClientID(consumerName);
                       
                        // create a queue session
                        // if (null == this.qsen)
                        {
                                this.qsen = queueConn.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE);
                        }
                        this.queueConn.setExceptionListener(new ConnectionExceptionListner());
                        MessageListenerFor_ECRE_TO_SEQ_Topic temp = new MessageListenerFor_ECRE_TO_SEQ_Topic();
                        // create a queue subscriber

                        // MessageConsumer queueReceiver = qsen.createConsumer(topic);
                        MessageConsumer queueReceiver = qsen.createDurableSubscriber(topic,
                                        consumerName);

                        queueReceiver.setMessageListener(temp);
                        queueConn.start();
                } catch (Exception e)
                {
                        logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic Setup JMS Exception -" + e.getMessage());
                       
                        //System.gc();
                        try
                        {
                                Thread.sleep(60000);
                        }
                        catch(Exception er)
                        {
                                logger.error("Exception occured in Thread.sleep");
                        }
                        return false;
                }
                return true;
        }

        private volatile boolean isJMSConnected = false;

        private class ConnectionExceptionListner implements ExceptionListener {
                @Override
                public void onException(JMSException exception) {
                        isJMSConnected = false;

                        while (true) {
                                cleanUp();
                                isJMSConnected = setupJMS();

                                if (isJMSConnected)
                                {
                                                return;
                                } else {

                                        try {
                                                //System.gc();
                                               
                                                Thread.sleep(2*60*1000);
                                        } catch (Exception e) {
                                                System.out.println(" "+e.getMessage());
                                        }
                                }
                        }
                }
        }

        private void cleanUp() {
                try {
                        this.queueConn.setExceptionListener(null);
                } catch (Exception e) {
                        // System.out.println("Exception in cleanUP()" + e.getMessage());
                        logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic Exception in JMS cleanUP()" + e.getMessage());

                }
                try {
                        this.queueConn.close();
                } catch (Exception e) {
                        // System.out.println("Exception in connection close()" +
                        // e.getMessage());
                        logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic Exception in JMS connection close()" + e.getMessage());

                }
        }

}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

Tim Bain
When your subscriber shows as being offline, does JMX still show that the
connection is open? Or are you indeed closing the connection?

Tim

On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:

>
> Hi All,
>
> Thank in Advance.
>
> Previously we were using version 5.12.0. That time my code was working
> fine.
> Subscriber never get offline automatically.
>
> Recently we upgraded to version 5.14.5 as most stable version and new
> features
>
> I found that my Active Durable Subscriber status is changing automatically
> to offline Durable Subscriber.
>
> I am using below code for connection.
>
> public class ReceiverFor_ECRE_TO_SEQ_Topic {
>         private static final Logger logger =
> Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
>
>         private TopicSession qsen = null;
>         private String JNDI_PROVIDER_URL = null;
>         private String topicName = null;
>         private String jmsUid = null;
>         private String jmsPwd = null;
>         private Topic topic = null;
>         private ConnectionFactory connFactory;
>         private TopicConnection queueConn;
>
>         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
>                 this.topicName = topicName;
>                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
>                 this.jmsUid = jmsUid;
>                 this.jmsPwd = jmsPwd;
>         }
>
>         public void listenTopic() {
>                 try {
>                         Properties env = new Properties();
>                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> Constants.INITIAL_CONTEXT_FACTORY);
>                         env.put(Context.PROVIDER_URL,
> System.getProperty(Context.PROVIDER_URL,
> JNDI_PROVIDER_URL));
>                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
>                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
>                         env.setProperty("prefetchPolicy.durableTopicPrefetch",
> "1000");
>                         InitialContext inictx = new InitialContext(env);
>
>                         // lookup the queue object
>                         topic = (Topic) inictx.lookup(topicName);
>                         // lookup the topic connection factory
>                         connFactory = (ConnectionFactory)
> inictx.lookup(Constants.CONN_FACTORY);
>
>                         // System.out.println("1");
>                         if (setupJMS()) {
>
>                                 isJMSConnected = true;
>                                 /*
>                                  * while(true) { }
>                                  */
>                         } else {
>
>                                 listenTopic();
>
>                         }
>                 } catch (NamingException ex) {
>                         // ex.printStackTrace();
>                         logger.error("Unable to connect Server for ECRE
> Topic");
>
>                         try {
>                                 Thread.sleep(5000);
>                                 listenTopic();
>                         } catch (InterruptedException ex1) {
>                                 // ex.printStackTrace();
>                                 logger.error("Unable to connect  Server
> for ECRE Topic");
>                         }
>                 }
>         }
>
>         public boolean setupJMS()
>         {
>                 try {
>
>                         // create a queue connection
>                         String consumerName =
> ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> SEQ_TOPIC_CONSUMER_Id);
>
>                         queueConn = (TopicConnection)
> connFactory.createConnection();
>                         queueConn.setClientID(consumerName);
>
>                         // create a queue session
>                         // if (null == this.qsen)
>                         {
>                                 this.qsen = queueConn.createTopicSession(
> false,
> Session.CLIENT_ACKNOWLEDGE);
>                         }
>                         this.queueConn.setExceptionListener(new
> ConnectionExceptionListner());
>                         MessageListenerFor_ECRE_TO_SEQ_Topic temp = new
> MessageListenerFor_ECRE_TO_SEQ_Topic();
>                         // create a queue subscriber
>
>                         // MessageConsumer queueReceiver =
> qsen.createConsumer(topic);
>                         MessageConsumer queueReceiver =
> qsen.createDurableSubscriber(topic,
>                                         consumerName);
>
>                         queueReceiver.setMessageListener(temp);
>                         queueConn.start();
>                 } catch (Exception e)
>                 {
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic Setup
> JMS Exception -" +
> e.getMessage());
>
>                         //System.gc();
>                         try
>                         {
>                                 Thread.sleep(60000);
>                         }
>                         catch(Exception er)
>                         {
>                                 logger.error("Exception occured in
> Thread.sleep");
>                         }
>                         return false;
>                 }
>                 return true;
>         }
>
>         private volatile boolean isJMSConnected = false;
>
>         private class ConnectionExceptionListner implements
> ExceptionListener {
>                 @Override
>                 public void onException(JMSException exception) {
>                         isJMSConnected = false;
>
>                         while (true) {
>                                 cleanUp();
>                                 isJMSConnected = setupJMS();
>
>                                 if (isJMSConnected)
>                                 {
>                                                 return;
>                                 } else {
>
>                                         try {
>                                                 //System.gc();
>
>                                                 Thread.sleep(2*60*1000);
>                                         } catch (Exception e) {
>                                                 System.out.println("
> "+e.getMessage());
>                                         }
>                                 }
>                         }
>                 }
>         }
>
>         private void cleanUp() {
>                 try {
>                         this.queueConn.setExceptionListener(null);
>                 } catch (Exception e) {
>                         // System.out.println("Exception in cleanUP()" +
> e.getMessage());
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Exception in JMS cleanUP()"
> + e.getMessage());
>
>                 }
>                 try {
>                         this.queueConn.close();
>                 } catch (Exception e) {
>                         // System.out.println("Exception in connection
> close()" +
>                         // e.getMessage());
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Exception in JMS connection
> close()" + e.getMessage());
>
>                 }
>         }
>
> }
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

tejas13
Yes JMX Still shown connection is open. I am not getting any exception for same. Previously I was receiving exception for same, So that time connection automatically get reestablished.

Thanks & Regards,
Tejas Ramchandra Sawant
Tata Consultancy Services Ltd.
QBPL, Phase-2, Hinjewadi
Pune, Maharashtra.
cell : +91-8055946458
Mailto: [hidden email]
Website:
http://www.tcs.com

____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________




From:        "Tim Bain [via ActiveMQ]" <[hidden email]>
To:        tejas13 <[hidden email]>
Date:        07/12/2017 12:34 PM
Subject:        Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]




When your subscriber shows as being offline, does JMX still show that the
connection is open? Or are you indeed closing the connection?

Tim

On Jul 12, 2017 12:39 AM, "tejas13" <
[hidden email]> wrote:

>
> Hi All,
>
> Thank in Advance.
>
> Previously we were using version 5.12.0. That time my code was working
> fine.
> Subscriber never get offline automatically.
>
> Recently we upgraded to version 5.14.5 as most stable version and new
> features
>
> I found that my Active Durable Subscriber status is changing automatically
> to offline Durable Subscriber.
>
> I am using below code for connection.
>
> public class ReceiverFor_ECRE_TO_SEQ_Topic {
>         private static final Logger logger =
> Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
>
>         private TopicSession qsen = null;
>         private String JNDI_PROVIDER_URL = null;
>         private String topicName = null;
>         private String jmsUid = null;
>         private String jmsPwd = null;
>         private Topic topic = null;
>         private ConnectionFactory connFactory;
>         private TopicConnection queueConn;
>
>         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
>                 this.topicName = topicName;
>                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
>                 this.jmsUid = jmsUid;
>                 this.jmsPwd = jmsPwd;
>         }
>
>         public void listenTopic() {
>                 try {
>                         Properties env = new Properties();
>                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> Constants.INITIAL_CONTEXT_FACTORY);
>                         env.put(Context.PROVIDER_URL,
> System.getProperty(Context.PROVIDER_URL,
> JNDI_PROVIDER_URL));
>                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
>                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
>                         env.setProperty("prefetchPolicy.durableTopicPrefetch",
> "1000");
>                         InitialContext inictx = new InitialContext(env);
>
>                         // lookup the queue object
>                         topic = (Topic) inictx.lookup(topicName);
>                         // lookup the topic connection factory
>                         connFactory = (ConnectionFactory)
> inictx.lookup(Constants.CONN_FACTORY);
>
>                         // System.out.println("1");
>                         if (setupJMS()) {
>
>                                 isJMSConnected = true;
>                                 /*
>                                  * while(true) { }
>                                  */
>                         } else {
>
>                                 listenTopic();
>
>                         }
>                 } catch (NamingException ex) {
>                         // ex.printStackTrace();
>                         logger.error("Unable to connect Server for ECRE
> Topic");
>
>                         try {
>                                 Thread.sleep(5000);
>                                 listenTopic();
>                         } catch (InterruptedException ex1) {
>                                 // ex.printStackTrace();
>                                 logger.error("Unable to connect  Server
> for ECRE Topic");
>                         }
>                 }
>         }
>
>         public boolean setupJMS()
>         {
>                 try {
>
>                         // create a queue connection
>                         String consumerName =
> ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> SEQ_TOPIC_CONSUMER_Id);
>
>                         queueConn = (TopicConnection)
> connFactory.createConnection();
>                         queueConn.setClientID(consumerName);
>
>                         // create a queue session
>                         // if (null == this.qsen)
>                         {
>                                 this.qsen = queueConn.createTopicSession(
> false,
> Session.CLIENT_ACKNOWLEDGE);
>                         }
>                         this.queueConn.setExceptionListener(new
> ConnectionExceptionListner());
>                         MessageListenerFor_ECRE_TO_SEQ_Topic temp = new
> MessageListenerFor_ECRE_TO_SEQ_Topic();
>                         // create a queue subscriber
>
>                         // MessageConsumer queueReceiver =
> qsen.createConsumer(topic);
>                         MessageConsumer queueReceiver =
> qsen.createDurableSubscriber(topic,
>                                         consumerName);
>
>                         queueReceiver.setMessageListener(temp);
>                         queueConn.start();
>                 } catch (Exception e)
>                 {
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic Setup
> JMS Exception -" +
> e.getMessage());
>
>                         //System.gc();
>                         try
>                         {
>                                 Thread.sleep(60000);
>                         }
>                         catch(Exception er)
>                         {
>                                 logger.error("Exception occured in
> Thread.sleep");
>                         }
>                         return false;
>                 }
>                 return true;
>         }
>
>         private volatile boolean isJMSConnected = false;
>
>         private class ConnectionExceptionListner implements
> ExceptionListener {
>                 @Override
>                 public void onException(JMSException exception) {
>                         isJMSConnected = false;
>
>                         while (true) {
>                                 cleanUp();
>                                 isJMSConnected = setupJMS();
>
>                                 if (isJMSConnected)
>                                 {
>                                                 return;
>                                 } else {
>
>                                         try {
>                                                 //System.gc();
>
>                                                 Thread.sleep(2*60*1000);
>                                         } catch (Exception e) {
>                                                 System.out.println("
> "+e.getMessage());
>                                         }
>                                 }
>                         }
>                 }
>         }
>
>         private void cleanUp() {
>                 try {
>                         this.queueConn.setExceptionListener(null);
>                 } catch (Exception e) {
>                         // System.out.println("Exception in cleanUP()" +
> e.getMessage());
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Exception in JMS cleanUP()"
> + e.getMessage());
>
>                 }
>                 try {
>                         this.queueConn.close();
>                 } catch (Exception e) {
>                         // System.out.println("Exception in connection
> close()" +
>                         // e.getMessage());
>                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Exception in JMS connection
> close()" + e.getMessage());
>
>                 }
>         }
>
> }
>
>
>
>
> --
> View this message in context:
http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>





If you reply to this email, your message will be added to the discussion below:
http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728484.html
To unsubscribe from Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version], click here.
NAML

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

Tim Bain
If you haven't already, I'd turn logging up to DEBUG on both the broker and
your client and see if there is any useful information in either log at the
time that the state changes.

Also, can you characterize in more detail what happens to the consumer
during the test? Presumably it starts in an active state, but then what?
How long till it goes offline? Does it get messages up until that point?
(Are messages even being published? You haven't described any producers in
your test scenario; do you have any?) Are messages received continuously,
or are there long gaps between the messages and/or bursts followed by quiet
periods? Once the subscriber is offline, does it keep getting messages, or
do they stop when it goes offline? How do you know it's offline; what
indicator are you looking at? Does it come back to active and then go
offline again later (maybe many times over), or does it stay offline from
that point onward? Does your operating system show the socket (the same
socket) as still being open after the subscriber goes offline? (You could
use netstat to determine this, if you're on Linux.)

Is this behavior easily and quickly reproducible with a minimum of code? Is
it possible to package up your test scenario (broker configs, producer
code, consumer code - anything beyond what you've shown here) so someone
else could quickly reproduce the behavior on their own machine, or does
this require so much infrastructure and/or time that it's not possible for
someone else to reproduce?

Tim

On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:

> Yes JMX Still shown connection is open. I am not getting any exception for
> same. Previously I was receiving exception for same, So that time
> connection automatically get reestablished.
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto: [hidden email]
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>
>
>
> From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> To:     tejas13 <[hidden email]>
> Date:   07/12/2017 12:34 PM
> Subject:        Re: Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version]
>
>
>
> When your subscriber shows as being offline, does JMX still show that the
> connection is open? Or are you indeed closing the connection?
>
> Tim
>
> On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
>
> >
> > Hi All,
> >
> > Thank in Advance.
> >
> > Previously we were using version 5.12.0. That time my code was working
> > fine.
> > Subscriber never get offline automatically.
> >
> > Recently we upgraded to version 5.14.5 as most stable version and new
> > features
> >
> > I found that my Active Durable Subscriber status is changing
> automatically
> > to offline Durable Subscriber.
> >
> > I am using below code for connection.
> >
> > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> >         private static final Logger logger =
> > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> >
> >         private TopicSession qsen = null;
> >         private String JNDI_PROVIDER_URL = null;
> >         private String topicName = null;
> >         private String jmsUid = null;
> >         private String jmsPwd = null;
> >         private Topic topic = null;
> >         private ConnectionFactory connFactory;
> >         private TopicConnection queueConn;
> >
> >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> >                 this.topicName = topicName;
> >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> >                 this.jmsUid = jmsUid;
> >                 this.jmsPwd = jmsPwd;
> >         }
> >
> >         public void listenTopic() {
> >                 try {
> >                         Properties env = new Properties();
> >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > Constants.INITIAL_CONTEXT_FACTORY);
> >                         env.put(Context.PROVIDER_URL,
> > System.getProperty(Context.PROVIDER_URL,
> > JNDI_PROVIDER_URL));
> >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> >                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
> > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > "1000");
> >                         InitialContext inictx = new InitialContext(env);
>
> >
> >                         // lookup the queue object
> >                         topic = (Topic) inictx.lookup(topicName);
> >                         // lookup the topic connection factory
> >                         connFactory = (ConnectionFactory)
> > inictx.lookup(Constants.CONN_FACTORY);
> >
> >                         // System.out.println("1");
> >                         if (setupJMS()) {
> >
> >                                 isJMSConnected = true;
> >                                 /*
> >                                  * while(true) { }
> >                                  */
> >                         } else {
> >
> >                                 listenTopic();
> >
> >                         }
> >                 } catch (NamingException ex) {
> >                         // ex.printStackTrace();
> >                         logger.error("Unable to connect Server for ECRE
> > Topic");
> >
> >                         try {
> >                                 Thread.sleep(5000);
> >                                 listenTopic();
> >                         } catch (InterruptedException ex1) {
> >                                 // ex.printStackTrace();
> >                                 logger.error("Unable to connect  Server
> > for ECRE Topic");
> >                         }
> >                 }
> >         }
> >
> >         public boolean setupJMS()
> >         {
> >                 try {
> >
> >                         // create a queue connection
> >                         String consumerName =
> > ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> > SEQ_TOPIC_CONSUMER_Id);
> >
> >                         queueConn = (TopicConnection)
> > connFactory.createConnection();
> >                         queueConn.setClientID(consumerName);
> >
> >                         // create a queue session
> >                         // if (null == this.qsen)
> >                         {
> >                                 this.qsen =
> queueConn.createTopicSession(
> > false,
> > Session.CLIENT_ACKNOWLEDGE);
> >                         }
> >                         this.queueConn.setExceptionListener(new
> > ConnectionExceptionListner());
> >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp = new
> > MessageListenerFor_ECRE_TO_SEQ_Topic();
> >                         // create a queue subscriber
> >
> >                         // MessageConsumer queueReceiver =
> > qsen.createConsumer(topic);
> >                         MessageConsumer queueReceiver =
> > qsen.createDurableSubscriber(topic,
> >                                         consumerName);
> >
> >                         queueReceiver.setMessageListener(temp);
> >                         queueConn.start();
> >                 } catch (Exception e)
> >                 {
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Setup
> > JMS Exception -" +
> > e.getMessage());
> >
> >                         //System.gc();
> >                         try
> >                         {
> >                                 Thread.sleep(60000);
> >                         }
> >                         catch(Exception er)
> >                         {
> >                                 logger.error("Exception occured in
> > Thread.sleep");
> >                         }
> >                         return false;
> >                 }
> >                 return true;
> >         }
> >
> >         private volatile boolean isJMSConnected = false;
> >
> >         private class ConnectionExceptionListner implements
> > ExceptionListener {
> >                 @Override
> >                 public void onException(JMSException exception) {
> >                         isJMSConnected = false;
> >
> >                         while (true) {
> >                                 cleanUp();
> >                                 isJMSConnected = setupJMS();
> >
> >                                 if (isJMSConnected)
> >                                 {
> >                                                 return;
> >                                 } else {
> >
> >                                         try {
> >                                                 //System.gc();
> >
> >                                                 Thread.sleep(2*60*1000);
>
> >                                         } catch (Exception e) {
> >                                                 System.out.println("
> > "+e.getMessage());
> >                                         }
> >                                 }
> >                         }
> >                 }
> >         }
> >
> >         private void cleanUp() {
> >                 try {
> >                         this.queueConn.setExceptionListener(null);
> >                 } catch (Exception e) {
> >                         // System.out.println("Exception in cleanUP()" +
>
> > e.getMessage());
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Exception in JMS cleanUP()"
> > + e.getMessage());
> >
> >                 }
> >                 try {
> >                         this.queueConn.close();
> >                 } catch (Exception e) {
> >                         // System.out.println("Exception in connection
> > close()" +
> >                         // e.getMessage());
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Exception in JMS connection
> > close()" + e.getMessage());
> >
> >                 }
> >         }
> >
> > }
> >
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728484.html
>
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

tejas13

Hi,

Thank you for your response. I did all setup and tested.

1] First I tested with 5.14.5 . I started active mq server on laptop L1.
2] I started application on laptop L2 . Both laptops are in same network
3] So connection established, and I found my 2 [ SUB1 and SUB2 ] subscribers active.
4] After 5 minutes I removed LAN Cable of Laptop L1 on which Active MQ Server is running
5] Still I found both subscribers are listed in Active Durable Subscription list
6] Checked in application also no error observed.
7] Using active mq web console I sent one message in SUB1 subscribed topic
8] Then SUB1 went to offline durable subscriber list.
9] SUB2 was in Active Subscriber list only
10] Then I connected LAN cable to Laptop L1.
11] SUB1 was offline he wont come online.
12] SUB2 was in active mode only and able to receive message also.

After that same repeated with version 5.12.3 . In this testing I found my both subscribers active after network connection.

Please give your inputs.

Answers for your queries

How long till it goes offline? 
Every morning, sometimes in mid night. Not fixed time

Does it get messages up until that point? 
No message lost

(Are messages even being published? You haven't described any producers in 
your test scenario; do you have any?) Are messages received continuously, 
or are there long gaps between the messages and/or bursts followed by quiet 
periods? 

Yes messages are produced with time interval but interval may be 5 minutes also or 3 hours also.



Once the subscriber is offline, does it keep getting messages, or 
do they stop when it goes offline? 

No Subscriber doesn't receive any message. After application restart all message get received.


How do you know it's offline; what 
indicator are you looking at? Does it come back to active and then go 
offline again later (maybe many times over), or does it stay offline from 
that point onward? 

End user stop receiving data. Then issue get reported and we come to know about offline case.

Does your operating system show the socket (the same 
socket) as still being open after the subscriber goes offline? (You could 
use netstat to determine this, if you're on Linux.) 

We are using windows server

Is this behavior easily and quickly reproducible with a minimum of code? Is 
it possible to package up your test scenario (broker configs, producer 
code, consumer code - anything beyond what you've shown here) so someone 
else could quickly reproduce the behavior on their own machine, or does 
this require so much infrastructure and/or time that it's not possible for 
someone else to reproduce? 

Yes anyone can do it. Just need 2 machines. One for active mq server and one for application. Application is web application deployed in tomcat server. 
 

Currently team is restarting tomcat so application get restarted and activemq connection get reestablished. Please help me as we recently upgraded active mq version and application is running in production environment.


Thanks & Regards,
Tejas Ramchandra Sawant
Tata Consultancy Services Ltd.
QBPL, Phase-2, Hinjewadi
Pune, Maharashtra.
cell : +91-8055946458
Mailto: [hidden email]
Website:http://www.tcs.com


____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________ 


-----"Tim Bain [via ActiveMQ]" <[hidden email]> wrote: -----
To: tejas13 <[hidden email]>
From: "Tim Bain [via ActiveMQ]" <[hidden email]>
Date: 07/13/2017 09:31AM
Subject: Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

If you haven't already, I'd turn logging up to DEBUG on both the broker and
your client and see if there is any useful information in either log at the
time that the state changes.

Also, can you characterize in more detail what happens to the consumer
during the test? Presumably it starts in an active state, but then what?
How long till it goes offline? Does it get messages up until that point?
(Are messages even being published? You haven't described any producers in
your test scenario; do you have any?) Are messages received continuously,
or are there long gaps between the messages and/or bursts followed by quiet
periods? Once the subscriber is offline, does it keep getting messages, or
do they stop when it goes offline? How do you know it's offline; what
indicator are you looking at? Does it come back to active and then go
offline again later (maybe many times over), or does it stay offline from
that point onward? Does your operating system show the socket (the same
socket) as still being open after the subscriber goes offline? (You could
use netstat to determine this, if you're on Linux.)

Is this behavior easily and quickly reproducible with a minimum of code? Is
it possible to package up your test scenario (broker configs, producer
code, consumer code - anything beyond what you've shown here) so someone
else could quickly reproduce the behavior on their own machine, or does
this require so much infrastructure and/or time that it's not possible for
someone else to reproduce?

Tim

On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:

> Yes JMX Still shown connection is open. I am not getting any exception for
> same. Previously I was receiving exception for same, So that time
> connection automatically get reestablished.
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto: [hidden email]
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                        Business Solutions
>                        Consulting
> ____________________________________________
>
>
>
> From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> To:     tejas13 <[hidden email]>
> Date:   07/12/2017 12:34 PM
> Subject:        Re: Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version]
>
>
>
> When your subscriber shows as being offline, does JMX still show that the
> connection is open? Or are you indeed closing the connection?
>
> Tim
>
> On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
>
> >
> > Hi All,
> >
> > Thank in Advance.
> >
> > Previously we were using version 5.12.0. That time my code was working
> > fine.
> > Subscriber never get offline automatically.
> >
> > Recently we upgraded to version 5.14.5 as most stable version and new
> > features
> >
> > I found that my Active Durable Subscriber status is changing
> automatically
> > to offline Durable Subscriber.
> >
> > I am using below code for connection.
> >
> > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> >         private static final Logger logger =
> > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> >
> >         private TopicSession qsen = null;
> >         private String JNDI_PROVIDER_URL = null;
> >         private String topicName = null;
> >         private String jmsUid = null;
> >         private String jmsPwd = null;
> >         private Topic topic = null;
> >         private ConnectionFactory connFactory;
> >         private TopicConnection queueConn;
> >
> >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> >                 this.topicName = topicName;
> >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> >                 this.jmsUid = jmsUid;
> >                 this.jmsPwd = jmsPwd;
> >         }
> >
> >         public void listenTopic() {
> >                 try {
> >                         Properties env = new Properties();
> >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > Constants.INITIAL_CONTEXT_FACTORY);
> >                         env.put(Context.PROVIDER_URL,
> > System.getProperty(Context.PROVIDER_URL,
> > JNDI_PROVIDER_URL));
> >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> >                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
> > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > "1000");
> >                         InitialContext inictx = new InitialContext(env);
>
> >
> >                         // lookup the queue object
> >                         topic = (Topic) inictx.lookup(topicName);
> >                         // lookup the topic connection factory
> >                         connFactory = (ConnectionFactory)
> > inictx.lookup(Constants.CONN_FACTORY);
> >
> >                         // System.out.println("1");
> >                         if (setupJMS()) {
> >
> >                                 isJMSConnected = true;
> >                                 /*
> >                                  * while(true) { }
> >                                  */
> >                         } else {
> >
> >                                 listenTopic();
> >
> >                         }
> >                 } catch (NamingException ex) {
> >                         // ex.printStackTrace();
> >                         logger.error("Unable to connect Server for ECRE
> > Topic");
> >
> >                         try {
> >                                 Thread.sleep(5000);
> >                                 listenTopic();
> >                         } catch (InterruptedException ex1) {
> >                                 // ex.printStackTrace();
> >                                 logger.error("Unable to connect  Server
> > for ECRE Topic");
> >                         }
> >                 }
> >         }
> >
> >         public boolean setupJMS()
> >         {
> >                 try {
> >
> >                         // create a queue connection
> >                         String consumerName =
> > ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> > SEQ_TOPIC_CONSUMER_Id);
> >
> >                         queueConn = (TopicConnection)
> > connFactory.createConnection();
> >                         queueConn.setClientID(consumerName);
> >
> >                         // create a queue session
> >                         // if (null == this.qsen)
> >                         {
> >                                 this.qsen =
> queueConn.createTopicSession(
> > false,
> > Session.CLIENT_ACKNOWLEDGE);
> >                         }
> >                         this.queueConn.setExceptionListener(new
> > ConnectionExceptionListner());
> >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp = new
> > MessageListenerFor_ECRE_TO_SEQ_Topic();
> >                         // create a queue subscriber
> >
> >                         // MessageConsumer queueReceiver =
> > qsen.createConsumer(topic);
> >                         MessageConsumer queueReceiver =
> > qsen.createDurableSubscriber(topic,
> >                                         consumerName);
> >
> >                         queueReceiver.setMessageListener(temp);
> >                         queueConn.start();
> >                 } catch (Exception e)
> >                 {
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> Setup
> > JMS Exception -" +
> > e.getMessage());
> >
> >                         //System.gc();
> >                         try
> >                         {
> >                                 Thread.sleep(60000);
> >                         }
> >                         catch(Exception er)
> >                         {
> >                                 logger.error("Exception occured in
> > Thread.sleep");
> >                         }
> >                         return false;
> >                 }
> >                 return true;
> >         }
> >
> >         private volatile boolean isJMSConnected = false;
> >
> >         private class ConnectionExceptionListner implements
> > ExceptionListener {
> >                 @Override
> >                 public void onException(JMSException exception) {
> >                         isJMSConnected = false;
> >
> >                         while (true) {
> >                                 cleanUp();
> >                                 isJMSConnected = setupJMS();
> >
> >                                 if (isJMSConnected)
> >                                 {
> >                                                 return;
> >                                 } else {
> >
> >                                         try {
> >                                                 //System.gc();
> >
> >                                                 Thread.sleep(2*60*1000);
>
> >                                         } catch (Exception e) {
> >                                                 System.out.println("
> > "+e.getMessage());
> >                                         }
> >                                 }
> >                         }
> >                 }
> >         }
> >
> >         private void cleanUp() {
> >                 try {
> >                         this.queueConn.setExceptionListener(null);
> >                 } catch (Exception e) {
> >                         // System.out.println("Exception in cleanUP()" +
>
> > e.getMessage());
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Exception in JMS cleanUP()"
> > + e.getMessage());
> >
> >                 }
> >                 try {
> >                         this.queueConn.close();
> >                 } catch (Exception e) {
> >                         // System.out.println("Exception in connection
> > close()" +
> >                         // e.getMessage());
> >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Exception in JMS connection
> > close()" + e.getMessage());
> >
> >                 }
> >         }
> >
> > }
> >
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728484.html
>
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



To unsubscribe from Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version], click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

Tim Bain
When this happens with your real-world server (in the morning or the middle
of the night), are you experiencing network partitions that result in the
subscriber really truly being offline for some period of time? If so, you
completely left that out of your initial description, and it means that
your question is actually, "Why doesn't my consumer reconnect automatically
after a network partition?" If not, why are you doing that during the test
you described here?

With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
but you see identical behavior for all other steps?

Is your consumer using a URI that uses the failover transport, to ensure it
automatically reconnects after the network connection is lost? More
generally, what URI is your client using to connect to the broker?

At what Log4J level is your webapp logging for ActiveMQ-related loggers?
What did you see when you switched them to DEBUG? I find it very surprising
that you would not see any logging by the client when you pull its network
cable; I'd expect that there'd be some logging that would occur after your
TCP session timeout elapses (did you wait that long?) and the client
figures out that it's not connected to the broker, so if you're not seeing
anything (Step 6) then I'd wonder whether you have Log4J configured
correctly.

Is there any difference between what's in the logs (either broker or
webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
switching both the broker and the client JARs?

Tim

On Fri, Jul 14, 2017 at 10:08 PM, tejas13 <[hidden email]> wrote:

>
> Hi,
>
> Thank you for your response. I did all setup and tested.
>
> 1] First I tested with 5.14.5 . I started active mq server on laptop L1.
> 2] I started application on laptop L2 . Both laptops are in same network
> 3] So connection established, and I found my 2 [ SUB1 and SUB2 ]
> subscribers active.
> 4] After 5 minutes I removed LAN Cable of Laptop L1 on which Active MQ
> Server is running
> 5] Still I found both subscribers are listed in Active Durable
> Subscription list
> 6] Checked in application also no error observed.
> 7] Using active mq web console I sent one message in SUB1 subscribed topic
> 8] Then SUB1 went to offline durable subscriber list.
> 9] SUB2 was in Active Subscriber list only
> 10] Then I connected LAN cable to Laptop L1.
> 11] SUB1 was offline he wont come online.
> 12] SUB2 was in active mode only and able to receive message also.
>
> After that same repeated with version 5.12.3 . In this testing I found my
> both subscribers active after network connection.
>
> Please give your inputs.
>
> Answers for your queries
>
> How long till it goes offline?
> Every morning, sometimes in mid night. Not fixed time
>
> Does it get messages up until that point?
> No message lost
>
> (Are messages even being published? You haven't described any producers in
> your test scenario; do you have any?) Are messages received continuously,
> or are there long gaps between the messages and/or bursts followed by quiet
> periods?
>
> Yes messages are produced with time interval but interval may be 5 minutes
> also or 3 hours also.
>
>
>
> Once the subscriber is offline, does it keep getting messages, or
> do they stop when it goes offline?
>
> No Subscriber doesn't receive any message. After application restart all
> message get received.
>
>
> How do you know it's offline; what
> indicator are you looking at? Does it come back to active and then go
> offline again later (maybe many times over), or does it stay offline from
> that point onward?
>
> End user stop receiving data. Then issue get reported and we come to know
> about offline case.
>
> Does your operating system show the socket (the same
> socket) as still being open after the subscriber goes offline? (You could
> use netstat to determine this, if you're on Linux.)
>
> We are using windows server
>
> Is this behavior easily and quickly reproducible with a minimum of code? Is
> it possible to package up your test scenario (broker configs, producer
> code, consumer code - anything beyond what you've shown here) so someone
> else could quickly reproduce the behavior on their own machine, or does
> this require so much infrastructure and/or time that it's not possible for
> someone else to reproduce?
>
> Yes anyone can do it. Just need 2 machines. One for active mq server and
> one for application. Application is web application deployed in tomcat
> server.
>
>
> Currently team is restarting tomcat so application get restarted and
> activemq connection get reestablished. Please help me as we recently
> upgraded active mq version and application is running in production
> environment.
>
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto: [hidden email]
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                       Business Solutions
>                       Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <[hidden email]>
> wrote: -----
> To: tejas13 <[hidden email]>
> From: "Tim Bain [via ActiveMQ]" <[hidden email]>
> Date: 07/13/2017 09:31AM
> Subject: Re: Active Durable Subscriber status automatically changing to
> offline Durable Subscriber [5.14.1 Most Stable Version]
>
> If you haven't already, I'd turn logging up to DEBUG on both the broker and
> your client and see if there is any useful information in either log at the
> time that the state changes.
>
> Also, can you characterize in more detail what happens to the consumer
> during the test? Presumably it starts in an active state, but then what?
> How long till it goes offline? Does it get messages up until that point?
> (Are messages even being published? You haven't described any producers in
> your test scenario; do you have any?) Are messages received continuously,
> or are there long gaps between the messages and/or bursts followed by quiet
> periods? Once the subscriber is offline, does it keep getting messages, or
> do they stop when it goes offline? How do you know it's offline; what
> indicator are you looking at? Does it come back to active and then go
> offline again later (maybe many times over), or does it stay offline from
> that point onward? Does your operating system show the socket (the same
> socket) as still being open after the subscriber goes offline? (You could
> use netstat to determine this, if you're on Linux.)
>
> Is this behavior easily and quickly reproducible with a minimum of code? Is
> it possible to package up your test scenario (broker configs, producer
> code, consumer code - anything beyond what you've shown here) so someone
> else could quickly reproduce the behavior on their own machine, or does
> this require so much infrastructure and/or time that it's not possible for
> someone else to reproduce?
>
> Tim
>
> On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:
>
> > Yes JMX Still shown connection is open. I am not getting any exception
> for
> > same. Previously I was receiving exception for same, So that time
> > connection automatically get reestablished.
> >
> > Thanks & Regards,
> > Tejas Ramchandra Sawant
> > Tata Consultancy Services Ltd.
> > QBPL, Phase-2, Hinjewadi
> > Pune, Maharashtra.
> > cell : +91-8055946458
> > Mailto: [hidden email]
> > Website:http://www.tcs.com
> >
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Consulting
> > ____________________________________________
> >
> >
> >
> > From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> > To:     tejas13 <[hidden email]>
> > Date:   07/12/2017 12:34 PM
> > Subject:        Re: Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version]
> >
> >
> >
> > When your subscriber shows as being offline, does JMX still show that the
> > connection is open? Or are you indeed closing the connection?
> >
> > Tim
> >
> > On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
> >
> > >
> > > Hi All,
> > >
> > > Thank in Advance.
> > >
> > > Previously we were using version 5.12.0. That time my code was working
> > > fine.
> > > Subscriber never get offline automatically.
> > >
> > > Recently we upgraded to version 5.14.5 as most stable version and new
> > > features
> > >
> > > I found that my Active Durable Subscriber status is changing
> > automatically
> > > to offline Durable Subscriber.
> > >
> > > I am using below code for connection.
> > >
> > > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> > >         private static final Logger logger =
> > > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> > >
> > >         private TopicSession qsen = null;
> > >         private String JNDI_PROVIDER_URL = null;
> > >         private String topicName = null;
> > >         private String jmsUid = null;
> > >         private String jmsPwd = null;
> > >         private Topic topic = null;
> > >         private ConnectionFactory connFactory;
> > >         private TopicConnection queueConn;
> > >
> > >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> > > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> > >                 this.topicName = topicName;
> > >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> > >                 this.jmsUid = jmsUid;
> > >                 this.jmsPwd = jmsPwd;
> > >         }
> > >
> > >         public void listenTopic() {
> > >                 try {
> > >                         Properties env = new Properties();
> > >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > > Constants.INITIAL_CONTEXT_FACTORY);
> > >                         env.put(Context.PROVIDER_URL,
> > > System.getProperty(Context.PROVIDER_URL,
> > > JNDI_PROVIDER_URL));
> > >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> > >                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
> > > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > > "1000");
> > >                         InitialContext inictx = new
> InitialContext(env);
> >
> > >
> > >                         // lookup the queue object
> > >                         topic = (Topic) inictx.lookup(topicName);
> > >                         // lookup the topic connection factory
> > >                         connFactory = (ConnectionFactory)
> > > inictx.lookup(Constants.CONN_FACTORY);
> > >
> > >                         // System.out.println("1");
> > >                         if (setupJMS()) {
> > >
> > >                                 isJMSConnected = true;
> > >                                 /*
> > >                                  * while(true) { }
> > >                                  */
> > >                         } else {
> > >
> > >                                 listenTopic();
> > >
> > >                         }
> > >                 } catch (NamingException ex) {
> > >                         // ex.printStackTrace();
> > >                         logger.error("Unable to connect Server for ECRE
> > > Topic");
> > >
> > >                         try {
> > >                                 Thread.sleep(5000);
> > >                                 listenTopic();
> > >                         } catch (InterruptedException ex1) {
> > >                                 // ex.printStackTrace();
> > >                                 logger.error("Unable to connect  Server
> > > for ECRE Topic");
> > >                         }
> > >                 }
> > >         }
> > >
> > >         public boolean setupJMS()
> > >         {
> > >                 try {
> > >
> > >                         // create a queue connection
> > >                         String consumerName =
> > > ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> > > SEQ_TOPIC_CONSUMER_Id);
> > >
> > >                         queueConn = (TopicConnection)
> > > connFactory.createConnection();
> > >                         queueConn.setClientID(consumerName);
> > >
> > >                         // create a queue session
> > >                         // if (null == this.qsen)
> > >                         {
> > >                                 this.qsen =
> > queueConn.createTopicSession(
> > > false,
> > > Session.CLIENT_ACKNOWLEDGE);
> > >                         }
> > >                         this.queueConn.setExceptionListener(new
> > > ConnectionExceptionListner());
> > >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp =
> new
> > > MessageListenerFor_ECRE_TO_SEQ_Topic();
> > >                         // create a queue subscriber
> > >
> > >                         // MessageConsumer queueReceiver =
> > > qsen.createConsumer(topic);
> > >                         MessageConsumer queueReceiver =
> > > qsen.createDurableSubscriber(topic,
> > >                                         consumerName);
> > >
> > >                         queueReceiver.setMessageListener(temp);
> > >                         queueConn.start();
> > >                 } catch (Exception e)
> > >                 {
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Setup
> > > JMS Exception -" +
> > > e.getMessage());
> > >
> > >                         //System.gc();
> > >                         try
> > >                         {
> > >                                 Thread.sleep(60000);
> > >                         }
> > >                         catch(Exception er)
> > >                         {
> > >                                 logger.error("Exception occured in
> > > Thread.sleep");
> > >                         }
> > >                         return false;
> > >                 }
> > >                 return true;
> > >         }
> > >
> > >         private volatile boolean isJMSConnected = false;
> > >
> > >         private class ConnectionExceptionListner implements
> > > ExceptionListener {
> > >                 @Override
> > >                 public void onException(JMSException exception) {
> > >                         isJMSConnected = false;
> > >
> > >                         while (true) {
> > >                                 cleanUp();
> > >                                 isJMSConnected = setupJMS();
> > >
> > >                                 if (isJMSConnected)
> > >                                 {
> > >                                                 return;
> > >                                 } else {
> > >
> > >                                         try {
> > >                                                 //System.gc();
> > >
> > >
>  Thread.sleep(2*60*1000);
> >
> > >                                         } catch (Exception e) {
> > >                                                 System.out.println("
> > > "+e.getMessage());
> > >                                         }
> > >                                 }
> > >                         }
> > >                 }
> > >         }
> > >
> > >         private void cleanUp() {
> > >                 try {
> > >                         this.queueConn.setExceptionListener(null);
> > >                 } catch (Exception e) {
> > >                         // System.out.println("Exception in cleanUP()"
> +
> >
> > > e.getMessage());
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Exception in JMS cleanUP()"
> > > + e.getMessage());
> > >
> > >                 }
> > >                 try {
> > >                         this.queueConn.close();
> > >                 } catch (Exception e) {
> > >                         // System.out.println("Exception in connection
> > > close()" +
> > >                         // e.getMessage());
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Exception in JMS connection
> > > close()" + e.getMessage());
> > >
> > >                 }
> > >         }
> > >
> > > }
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://activemq.2283324.n4.
> > > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > tp4728482p4728484.html
> >
> > To unsubscribe from Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> click
> > here.
> > NAML
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728514.html
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728572.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

tejas13


When this happens with your real-world server (in the morning or the middle 
of the night), are you experiencing network partitions that result in the 
subscriber really truly being offline for some period of time? If so, you 
completely left that out of your initial description, and it means that 
your question is actually, "Why doesn't my consumer reconnect automatically 
after a network partition?" If not, why are you doing that during the test 
you described here? 

Network Partition is one reason. There may be another reason also

With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only 
difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11, 
but you see identical behavior for all other steps? 

In case of 5.12.3 I found both subscriber offline when network cable disconnected and online when connected


Is your consumer using a URI that uses the failover transport, to ensure it 
automatically reconnects after the network connection is lost? More 
generally, what URI is your client using to connect to the broker? 

Yes I am using fail over protocol

At what Log4J level is your webapp logging for ActiveMQ-related loggers? 
What did you see when you switched them to DEBUG? I find it very surprising 
that you would not see any logging by the client when you pull its network 
cable; I'd expect that there'd be some logging that would occur after your 
TCP session timeout elapses (did you wait that long?) and the client 
figures out that it's not connected to the broker, so if you're not seeing 
anything (Step 6) then I'd wonder whether you have Log4J configured 
correctly. 

Yes in case of 5.12.3 I get exception in application. But in 5.14.5 I am not getting any error also.

Is there any difference between what's in the logs (either broker or 
webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client? 
Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you 
switching both the broker and the client JARs? 

I am using 5.14.3 jars.

One change we did recently in activemq.xml and we faced this issue. That change is changing open wire protocol from tcp to nio  and added parameter maxInactivityDuration

<transportConnector name="openwire" uri="nio://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600&amp;wireFormat.maxInactivityDuration=0"/>


Please let me know does this is impacting solution.


Thanks & Regards,
Tejas Ramchandra Sawant
Tata Consultancy Services Ltd.
QBPL, Phase-2, Hinjewadi
Pune, Maharashtra.
cell : +91-8055946458
Mailto: [hidden email]
Website:http://www.tcs.com


____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________ 


-----"Tim Bain [via ActiveMQ]" <[hidden email]> wrote: -----
To: tejas13 <[hidden email]>
From: "Tim Bain [via ActiveMQ]" <[hidden email]>
Date: 07/15/2017 10:30AM
Subject: Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

When this happens with your real-world server (in the morning or the middle
of the night), are you experiencing network partitions that result in the
subscriber really truly being offline for some period of time? If so, you
completely left that out of your initial description, and it means that
your question is actually, "Why doesn't my consumer reconnect automatically
after a network partition?" If not, why are you doing that during the test
you described here?

With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
but you see identical behavior for all other steps?

Is your consumer using a URI that uses the failover transport, to ensure it
automatically reconnects after the network connection is lost? More
generally, what URI is your client using to connect to the broker?

At what Log4J level is your webapp logging for ActiveMQ-related loggers?
What did you see when you switched them to DEBUG? I find it very surprising
that you would not see any logging by the client when you pull its network
cable; I'd expect that there'd be some logging that would occur after your
TCP session timeout elapses (did you wait that long?) and the client
figures out that it's not connected to the broker, so if you're not seeing
anything (Step 6) then I'd wonder whether you have Log4J configured
correctly.

Is there any difference between what's in the logs (either broker or
webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
switching both the broker and the client JARs?

Tim

On Fri, Jul 14, 2017 at 10:08 PM, tejas13 <[hidden email]> wrote:

>
> Hi,
>
> Thank you for your response. I did all setup and tested.
>
> 1] First I tested with 5.14.5 . I started active mq server on laptop L1.
> 2] I started application on laptop L2 . Both laptops are in same network
> 3] So connection established, and I found my 2 [ SUB1 and SUB2 ]
> subscribers active.
> 4] After 5 minutes I removed LAN Cable of Laptop L1 on which Active MQ
> Server is running
> 5] Still I found both subscribers are listed in Active Durable
> Subscription list
> 6] Checked in application also no error observed.
> 7] Using active mq web console I sent one message in SUB1 subscribed topic
> 8] Then SUB1 went to offline durable subscriber list.
> 9] SUB2 was in Active Subscriber list only
> 10] Then I connected LAN cable to Laptop L1.
> 11] SUB1 was offline he wont come online.
> 12] SUB2 was in active mode only and able to receive message also.
>
> After that same repeated with version 5.12.3 . In this testing I found my
> both subscribers active after network connection.
>
> Please give your inputs.
>
> Answers for your queries
>
> How long till it goes offline?
> Every morning, sometimes in mid night. Not fixed time
>
> Does it get messages up until that point?
> No message lost
>
> (Are messages even being published? You haven't described any producers in
> your test scenario; do you have any?) Are messages received continuously,
> or are there long gaps between the messages and/or bursts followed by quiet
> periods?
>
> Yes messages are produced with time interval but interval may be 5 minutes
> also or 3 hours also.
>
>
>
> Once the subscriber is offline, does it keep getting messages, or
> do they stop when it goes offline?
>
> No Subscriber doesn't receive any message. After application restart all
> message get received.
>
>
> How do you know it's offline; what
> indicator are you looking at? Does it come back to active and then go
> offline again later (maybe many times over), or does it stay offline from
> that point onward?
>
> End user stop receiving data. Then issue get reported and we come to know
> about offline case.
>
> Does your operating system show the socket (the same
> socket) as still being open after the subscriber goes offline? (You could
> use netstat to determine this, if you're on Linux.)
>
> We are using windows server
>
> Is this behavior easily and quickly reproducible with a minimum of code? Is
> it possible to package up your test scenario (broker configs, producer
> code, consumer code - anything beyond what you've shown here) so someone
> else could quickly reproduce the behavior on their own machine, or does
> this require so much infrastructure and/or time that it's not possible for
> someone else to reproduce?
>
> Yes anyone can do it. Just need 2 machines. One for active mq server and
> one for application. Application is web application deployed in tomcat
> server.
>
>
> Currently team is restarting tomcat so application get restarted and
> activemq connection get reestablished. Please help me as we recently
> upgraded active mq version and application is running in production
> environment.
>
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto: [hidden email]
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                       Business Solutions
>                       Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <[hidden email]>
> wrote: -----
> To: tejas13 <[hidden email]>
> From: "Tim Bain [via ActiveMQ]" <[hidden email]>
> Date: 07/13/2017 09:31AM
> Subject: Re: Active Durable Subscriber status automatically changing to
> offline Durable Subscriber [5.14.1 Most Stable Version]
>
> If you haven't already, I'd turn logging up to DEBUG on both the broker and
> your client and see if there is any useful information in either log at the
> time that the state changes.
>
> Also, can you characterize in more detail what happens to the consumer
> during the test? Presumably it starts in an active state, but then what?
> How long till it goes offline? Does it get messages up until that point?
> (Are messages even being published? You haven't described any producers in
> your test scenario; do you have any?) Are messages received continuously,
> or are there long gaps between the messages and/or bursts followed by quiet
> periods? Once the subscriber is offline, does it keep getting messages, or
> do they stop when it goes offline? How do you know it's offline; what
> indicator are you looking at? Does it come back to active and then go
> offline again later (maybe many times over), or does it stay offline from
> that point onward? Does your operating system show the socket (the same
> socket) as still being open after the subscriber goes offline? (You could
> use netstat to determine this, if you're on Linux.)
>
> Is this behavior easily and quickly reproducible with a minimum of code? Is
> it possible to package up your test scenario (broker configs, producer
> code, consumer code - anything beyond what you've shown here) so someone
> else could quickly reproduce the behavior on their own machine, or does
> this require so much infrastructure and/or time that it's not possible for
> someone else to reproduce?
>
> Tim
>
> On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:
>
> > Yes JMX Still shown connection is open. I am not getting any exception
> for
> > same. Previously I was receiving exception for same, So that time
> > connection automatically get reestablished.
> >
> > Thanks & Regards,
> > Tejas Ramchandra Sawant
> > Tata Consultancy Services Ltd.
> > QBPL, Phase-2, Hinjewadi
> > Pune, Maharashtra.
> > cell : +91-8055946458
> > Mailto: [hidden email]
> > Website:http://www.tcs.com
> >
> > ____________________________________________
> > Experience certainty.        IT Services
> >                        Business Solutions
> >                        Consulting
> > ____________________________________________
> >
> >
> >
> > From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> > To:     tejas13 <[hidden email]>
> > Date:   07/12/2017 12:34 PM
> > Subject:        Re: Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version]
> >
> >
> >
> > When your subscriber shows as being offline, does JMX still show that the
> > connection is open? Or are you indeed closing the connection?
> >
> > Tim
> >
> > On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
> >
> > >
> > > Hi All,
> > >
> > > Thank in Advance.
> > >
> > > Previously we were using version 5.12.0. That time my code was working
> > > fine.
> > > Subscriber never get offline automatically.
> > >
> > > Recently we upgraded to version 5.14.5 as most stable version and new
> > > features
> > >
> > > I found that my Active Durable Subscriber status is changing
> > automatically
> > > to offline Durable Subscriber.
> > >
> > > I am using below code for connection.
> > >
> > > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> > >         private static final Logger logger =
> > > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> > >
> > >         private TopicSession qsen = null;
> > >         private String JNDI_PROVIDER_URL = null;
> > >         private String topicName = null;
> > >         private String jmsUid = null;
> > >         private String jmsPwd = null;
> > >         private Topic topic = null;
> > >         private ConnectionFactory connFactory;
> > >         private TopicConnection queueConn;
> > >
> > >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName, String
> > > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> > >                 this.topicName = topicName;
> > >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> > >                 this.jmsUid = jmsUid;
> > >                 this.jmsPwd = jmsPwd;
> > >         }
> > >
> > >         public void listenTopic() {
> > >                 try {
> > >                         Properties env = new Properties();
> > >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > > Constants.INITIAL_CONTEXT_FACTORY);
> > >                         env.put(Context.PROVIDER_URL,
> > > System.getProperty(Context.PROVIDER_URL,
> > > JNDI_PROVIDER_URL));
> > >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> > >                         env.put(Context.SECURITY_CREDENTIALS, jmsPwd);
> > > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > > "1000");
> > >                         InitialContext inictx = new
> InitialContext(env);
> >
> > >
> > >                         // lookup the queue object
> > >                         topic = (Topic) inictx.lookup(topicName);
> > >                         // lookup the topic connection factory
> > >                         connFactory = (ConnectionFactory)
> > > inictx.lookup(Constants.CONN_FACTORY);
> > >
> > >                         // System.out.println("1");
> > >                         if (setupJMS()) {
> > >
> > >                                 isJMSConnected = true;
> > >                                 /*
> > >                                  * while(true) { }
> > >                                  */
> > >                         } else {
> > >
> > >                                 listenTopic();
> > >
> > >                         }
> > >                 } catch (NamingException ex) {
> > >                         // ex.printStackTrace();
> > >                         logger.error("Unable to connect Server for ECRE
> > > Topic");
> > >
> > >                         try {
> > >                                 Thread.sleep(5000);
> > >                                 listenTopic();
> > >                         } catch (InterruptedException ex1) {
> > >                                 // ex.printStackTrace();
> > >                                 logger.error("Unable to connect  Server
> > > for ECRE Topic");
> > >                         }
> > >                 }
> > >         }
> > >
> > >         public boolean setupJMS()
> > >         {
> > >                 try {
> > >
> > >                         // create a queue connection
> > >                         String consumerName =
> > > ResourceBundleHelper.applicationData.get(ApplicationConstants.ECRE_TO_
> > > SEQ_TOPIC_CONSUMER_Id);
> > >
> > >                         queueConn = (TopicConnection)
> > > connFactory.createConnection();
> > >                         queueConn.setClientID(consumerName);
> > >
> > >                         // create a queue session
> > >                         // if (null == this.qsen)
> > >                         {
> > >                                 this.qsen =
> > queueConn.createTopicSession(
> > > false,
> > > Session.CLIENT_ACKNOWLEDGE);
> > >                         }
> > >                         this.queueConn.setExceptionListener(new
> > > ConnectionExceptionListner());
> > >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp =
> new
> > > MessageListenerFor_ECRE_TO_SEQ_Topic();
> > >                         // create a queue subscriber
> > >
> > >                         // MessageConsumer queueReceiver =
> > > qsen.createConsumer(topic);
> > >                         MessageConsumer queueReceiver =
> > > qsen.createDurableSubscriber(topic,
> > >                                         consumerName);
> > >
> > >                         queueReceiver.setMessageListener(temp);
> > >                         queueConn.start();
> > >                 } catch (Exception e)
> > >                 {
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > Setup
> > > JMS Exception -" +
> > > e.getMessage());
> > >
> > >                         //System.gc();
> > >                         try
> > >                         {
> > >                                 Thread.sleep(60000);
> > >                         }
> > >                         catch(Exception er)
> > >                         {
> > >                                 logger.error("Exception occured in
> > > Thread.sleep");
> > >                         }
> > >                         return false;
> > >                 }
> > >                 return true;
> > >         }
> > >
> > >         private volatile boolean isJMSConnected = false;
> > >
> > >         private class ConnectionExceptionListner implements
> > > ExceptionListener {
> > >                 @Override
> > >                 public void onException(JMSException exception) {
> > >                         isJMSConnected = false;
> > >
> > >                         while (true) {
> > >                                 cleanUp();
> > >                                 isJMSConnected = setupJMS();
> > >
> > >                                 if (isJMSConnected)
> > >                                 {
> > >                                                 return;
> > >                                 } else {
> > >
> > >                                         try {
> > >                                                 //System.gc();
> > >
> > >
>  Thread.sleep(2*60*1000);
> >
> > >                                         } catch (Exception e) {
> > >                                                 System.out.println("
> > > "+e.getMessage());
> > >                                         }
> > >                                 }
> > >                         }
> > >                 }
> > >         }
> > >
> > >         private void cleanUp() {
> > >                 try {
> > >                         this.queueConn.setExceptionListener(null);
> > >                 } catch (Exception e) {
> > >                         // System.out.println("Exception in cleanUP()"
> +
> >
> > > e.getMessage());
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Exception in JMS cleanUP()"
> > > + e.getMessage());
> > >
> > >                 }
> > >                 try {
> > >                         this.queueConn.close();
> > >                 } catch (Exception e) {
> > >                         // System.out.println("Exception in connection
> > > close()" +
> > >                         // e.getMessage());
> > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Exception in JMS connection
> > > close()" + e.getMessage());
> > >
> > >                 }
> > >         }
> > >
> > > }
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://activemq.2283324.n4.
> > > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > tp4728482p4728484.html
> >
> > To unsubscribe from Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> click
> > here.
> > NAML
> > =====-----=====-----=====
> > Notice: The information contained in this e-mail
> > message and/or attachments to it may contain
> > confidential or privileged information. If you are
> > not the intended recipient, any dissemination, use,
> > review, distribution, printing or copying of the
> > information contained in this e-mail message
> > and/or attachments to it are strictly prohibited. If
> > you have received this communication in error,
> > please notify us by reply e-mail or telephone and
> > immediately and permanently delete the message
> > and any attachments. Thank you
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728514.html
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728572.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



To unsubscribe from Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version], click here.
NAML
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

Tim Bain
A maxInactivityDuration of 0 will disable inactivity detection, whose
purpose is to detect both idle TCP connections and TCP connections that
died ungracefully (e.g. due to network partitions), so I believe that your
addition of that parameter caused this behavior. What was the reason you
set it to that value?

Tim

On Jul 15, 2017 1:11 AM, "tejas13" <[hidden email]> wrote:

>
>
> When this happens with your real-world server (in the morning or the middle
> of the night), are you experiencing network partitions that result in the
> subscriber really truly being offline for some period of time? If so, you
> completely left that out of your initial description, and it means that
> your question is actually, "Why doesn't my consumer reconnect automatically
> after a network partition?" If not, why are you doing that during the test
> you described here?
>
> Network Partition is one reason. There may be another reason also
>
> With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
> difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
> but you see identical behavior for all other steps?
>
> In case of 5.12.3 I found both subscriber offline when network cable
> disconnected and online when connected
>
>
> Is your consumer using a URI that uses the failover transport, to ensure it
> automatically reconnects after the network connection is lost? More
> generally, what URI is your client using to connect to the broker?
>
> Yes I am using fail over protocol
>
> At what Log4J level is your webapp logging for ActiveMQ-related loggers?
> What did you see when you switched them to DEBUG? I find it very surprising
> that you would not see any logging by the client when you pull its network
> cable; I'd expect that there'd be some logging that would occur after your
> TCP session timeout elapses (did you wait that long?) and the client
> figures out that it's not connected to the broker, so if you're not seeing
> anything (Step 6) then I'd wonder whether you have Log4J configured
> correctly.
>
> Yes in case of 5.12.3 I get exception in application. But in 5.14.5 I am
> not getting any error also.
>
> Is there any difference between what's in the logs (either broker or
> webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
> Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
> switching both the broker and the client JARs?
>
> I am using 5.14.3 jars.
>
> One change we did recently in activemq.xml and we faced this issue. That
> change is changing open wire protocol from tcp to nio  and added parameter
> maxInactivityDuration
>
> <transportConnector name="openwire" uri="nio://0.0.0.0:61616?
> maximumConnections=1000&amp;wireFormat.maxFrameSize=
> 104857600&amp;wireFormat.maxInactivityDuration=0"/>
>
>
> Please let me know does this is impacting solution.
>
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto: [hidden email]
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                       Business Solutions
>                       Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <[hidden email]>
> wrote: -----
> To: tejas13 <[hidden email]>
> From: "Tim Bain [via ActiveMQ]" <[hidden email]>
> Date: 07/15/2017 10:30AM
> Subject: Re: Active Durable Subscriber status automatically changing to
> offline Durable Subscriber [5.14.1 Most Stable Version]
>
> When this happens with your real-world server (in the morning or the middle
> of the night), are you experiencing network partitions that result in the
> subscriber really truly being offline for some period of time? If so, you
> completely left that out of your initial description, and it means that
> your question is actually, "Why doesn't my consumer reconnect automatically
> after a network partition?" If not, why are you doing that during the test
> you described here?
>
> With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
> difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
> but you see identical behavior for all other steps?
>
> Is your consumer using a URI that uses the failover transport, to ensure it
> automatically reconnects after the network connection is lost? More
> generally, what URI is your client using to connect to the broker?
>
> At what Log4J level is your webapp logging for ActiveMQ-related loggers?
> What did you see when you switched them to DEBUG? I find it very surprising
> that you would not see any logging by the client when you pull its network
> cable; I'd expect that there'd be some logging that would occur after your
> TCP session timeout elapses (did you wait that long?) and the client
> figures out that it's not connected to the broker, so if you're not seeing
> anything (Step 6) then I'd wonder whether you have Log4J configured
> correctly.
>
> Is there any difference between what's in the logs (either broker or
> webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
> Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
> switching both the broker and the client JARs?
>
> Tim
>
> On Fri, Jul 14, 2017 at 10:08 PM, tejas13 <[hidden email]> wrote:
>
> >
> > Hi,
> >
> > Thank you for your response. I did all setup and tested.
> >
> > 1] First I tested with 5.14.5 . I started active mq server on laptop L1.
> > 2] I started application on laptop L2 . Both laptops are in same network
> > 3] So connection established, and I found my 2 [ SUB1 and SUB2 ]
> > subscribers active.
> > 4] After 5 minutes I removed LAN Cable of Laptop L1 on which Active MQ
> > Server is running
> > 5] Still I found both subscribers are listed in Active Durable
> > Subscription list
> > 6] Checked in application also no error observed.
> > 7] Using active mq web console I sent one message in SUB1 subscribed
> topic
> > 8] Then SUB1 went to offline durable subscriber list.
> > 9] SUB2 was in Active Subscriber list only
> > 10] Then I connected LAN cable to Laptop L1.
> > 11] SUB1 was offline he wont come online.
> > 12] SUB2 was in active mode only and able to receive message also.
> >
> > After that same repeated with version 5.12.3 . In this testing I found my
> > both subscribers active after network connection.
> >
> > Please give your inputs.
> >
> > Answers for your queries
> >
> > How long till it goes offline?
> > Every morning, sometimes in mid night. Not fixed time
> >
> > Does it get messages up until that point?
> > No message lost
> >
> > (Are messages even being published? You haven't described any producers
> in
> > your test scenario; do you have any?) Are messages received continuously,
> > or are there long gaps between the messages and/or bursts followed by
> quiet
> > periods?
> >
> > Yes messages are produced with time interval but interval may be 5
> minutes
> > also or 3 hours also.
> >
> >
> >
> > Once the subscriber is offline, does it keep getting messages, or
> > do they stop when it goes offline?
> >
> > No Subscriber doesn't receive any message. After application restart all
> > message get received.
> >
> >
> > How do you know it's offline; what
> > indicator are you looking at? Does it come back to active and then go
> > offline again later (maybe many times over), or does it stay offline from
> > that point onward?
> >
> > End user stop receiving data. Then issue get reported and we come to know
> > about offline case.
> >
> > Does your operating system show the socket (the same
> > socket) as still being open after the subscriber goes offline? (You could
> > use netstat to determine this, if you're on Linux.)
> >
> > We are using windows server
> >
> > Is this behavior easily and quickly reproducible with a minimum of code?
> Is
> > it possible to package up your test scenario (broker configs, producer
> > code, consumer code - anything beyond what you've shown here) so someone
> > else could quickly reproduce the behavior on their own machine, or does
> > this require so much infrastructure and/or time that it's not possible
> for
> > someone else to reproduce?
> >
> > Yes anyone can do it. Just need 2 machines. One for active mq server and
> > one for application. Application is web application deployed in tomcat
> > server.
> >
> >
> > Currently team is restarting tomcat so application get restarted and
> > activemq connection get reestablished. Please help me as we recently
> > upgraded active mq version and application is running in production
> > environment.
> >
> >
> > Thanks & Regards,
> > Tejas Ramchandra Sawant
> > Tata Consultancy Services Ltd.
> > QBPL, Phase-2, Hinjewadi
> > Pune, Maharashtra.
> > cell : +91-8055946458
> > Mailto: [hidden email]
> > Website:http://www.tcs.com
> >
> > ____________________________________________
> > Experience certainty.        IT Services
> >                       Business Solutions
> >                       Consulting
> > ____________________________________________
> >
> >
> > -----"Tim Bain [via ActiveMQ]" <[hidden email]>
> > wrote: -----
> > To: tejas13 <[hidden email]>
> > From: "Tim Bain [via ActiveMQ]" <[hidden email]>
> > Date: 07/13/2017 09:31AM
> > Subject: Re: Active Durable Subscriber status automatically changing to
> > offline Durable Subscriber [5.14.1 Most Stable Version]
> >
> > If you haven't already, I'd turn logging up to DEBUG on both the broker
> and
> > your client and see if there is any useful information in either log at
> the
> > time that the state changes.
> >
> > Also, can you characterize in more detail what happens to the consumer
> > during the test? Presumably it starts in an active state, but then what?
> > How long till it goes offline? Does it get messages up until that point?
> > (Are messages even being published? You haven't described any producers
> in
> > your test scenario; do you have any?) Are messages received continuously,
> > or are there long gaps between the messages and/or bursts followed by
> quiet
> > periods? Once the subscriber is offline, does it keep getting messages,
> or
> > do they stop when it goes offline? How do you know it's offline; what
> > indicator are you looking at? Does it come back to active and then go
> > offline again later (maybe many times over), or does it stay offline from
> > that point onward? Does your operating system show the socket (the same
> > socket) as still being open after the subscriber goes offline? (You could
> > use netstat to determine this, if you're on Linux.)
> >
> > Is this behavior easily and quickly reproducible with a minimum of code?
> Is
> > it possible to package up your test scenario (broker configs, producer
> > code, consumer code - anything beyond what you've shown here) so someone
> > else could quickly reproduce the behavior on their own machine, or does
> > this require so much infrastructure and/or time that it's not possible
> for
> > someone else to reproduce?
> >
> > Tim
> >
> > On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:
> >
> > > Yes JMX Still shown connection is open. I am not getting any exception
> > for
> > > same. Previously I was receiving exception for same, So that time
> > > connection automatically get reestablished.
> > >
> > > Thanks & Regards,
> > > Tejas Ramchandra Sawant
> > > Tata Consultancy Services Ltd.
> > > QBPL, Phase-2, Hinjewadi
> > > Pune, Maharashtra.
> > > cell : +91-8055946458
> > > Mailto: [hidden email]
> > > Website:http://www.tcs.com
> > >
> > > ____________________________________________
> > > Experience certainty.        IT Services
> > >                        Business Solutions
> > >                        Consulting
> > > ____________________________________________
> > >
> > >
> > >
> > > From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> > > To:     tejas13 <[hidden email]>
> > > Date:   07/12/2017 12:34 PM
> > > Subject:        Re: Active Durable Subscriber status automatically
> > > changing to offline Durable Subscriber [5.14.1 Most Stable Version]
> > >
> > >
> > >
> > > When your subscriber shows as being offline, does JMX still show that
> the
> > > connection is open? Or are you indeed closing the connection?
> > >
> > > Tim
> > >
> > > On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
> > >
> > > >
> > > > Hi All,
> > > >
> > > > Thank in Advance.
> > > >
> > > > Previously we were using version 5.12.0. That time my code was
> working
> > > > fine.
> > > > Subscriber never get offline automatically.
> > > >
> > > > Recently we upgraded to version 5.14.5 as most stable version and new
> > > > features
> > > >
> > > > I found that my Active Durable Subscriber status is changing
> > > automatically
> > > > to offline Durable Subscriber.
> > > >
> > > > I am using below code for connection.
> > > >
> > > > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> > > >         private static final Logger logger =
> > > > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> > > >
> > > >         private TopicSession qsen = null;
> > > >         private String JNDI_PROVIDER_URL = null;
> > > >         private String topicName = null;
> > > >         private String jmsUid = null;
> > > >         private String jmsPwd = null;
> > > >         private Topic topic = null;
> > > >         private ConnectionFactory connFactory;
> > > >         private TopicConnection queueConn;
> > > >
> > > >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName,
> String
> > > > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> > > >                 this.topicName = topicName;
> > > >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> > > >                 this.jmsUid = jmsUid;
> > > >                 this.jmsPwd = jmsPwd;
> > > >         }
> > > >
> > > >         public void listenTopic() {
> > > >                 try {
> > > >                         Properties env = new Properties();
> > > >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > > > Constants.INITIAL_CONTEXT_FACTORY);
> > > >                         env.put(Context.PROVIDER_URL,
> > > > System.getProperty(Context.PROVIDER_URL,
> > > > JNDI_PROVIDER_URL));
> > > >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> > > >                         env.put(Context.SECURITY_CREDENTIALS,
> jmsPwd);
> > > > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > > > "1000");
> > > >                         InitialContext inictx = new
> > InitialContext(env);
> > >
> > > >
> > > >                         // lookup the queue object
> > > >                         topic = (Topic) inictx.lookup(topicName);
> > > >                         // lookup the topic connection factory
> > > >                         connFactory = (ConnectionFactory)
> > > > inictx.lookup(Constants.CONN_FACTORY);
> > > >
> > > >                         // System.out.println("1");
> > > >                         if (setupJMS()) {
> > > >
> > > >                                 isJMSConnected = true;
> > > >                                 /*
> > > >                                  * while(true) { }
> > > >                                  */
> > > >                         } else {
> > > >
> > > >                                 listenTopic();
> > > >
> > > >                         }
> > > >                 } catch (NamingException ex) {
> > > >                         // ex.printStackTrace();
> > > >                         logger.error("Unable to connect Server for
> ECRE
> > > > Topic");
> > > >
> > > >                         try {
> > > >                                 Thread.sleep(5000);
> > > >                                 listenTopic();
> > > >                         } catch (InterruptedException ex1) {
> > > >                                 // ex.printStackTrace();
> > > >                                 logger.error("Unable to connect
> Server
> > > > for ECRE Topic");
> > > >                         }
> > > >                 }
> > > >         }
> > > >
> > > >         public boolean setupJMS()
> > > >         {
> > > >                 try {
> > > >
> > > >                         // create a queue connection
> > > >                         String consumerName =
> > > > ResourceBundleHelper.applicationData.get(
> ApplicationConstants.ECRE_TO_
> > > > SEQ_TOPIC_CONSUMER_Id);
> > > >
> > > >                         queueConn = (TopicConnection)
> > > > connFactory.createConnection();
> > > >                         queueConn.setClientID(consumerName);
> > > >
> > > >                         // create a queue session
> > > >                         // if (null == this.qsen)
> > > >                         {
> > > >                                 this.qsen =
> > > queueConn.createTopicSession(
> > > > false,
> > > > Session.CLIENT_ACKNOWLEDGE);
> > > >                         }
> > > >                         this.queueConn.setExceptionListener(new
> > > > ConnectionExceptionListner());
> > > >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp =
> > new
> > > > MessageListenerFor_ECRE_TO_SEQ_Topic();
> > > >                         // create a queue subscriber
> > > >
> > > >                         // MessageConsumer queueReceiver =
> > > > qsen.createConsumer(topic);
> > > >                         MessageConsumer queueReceiver =
> > > > qsen.createDurableSubscriber(topic,
> > > >                                         consumerName);
> > > >
> > > >                         queueReceiver.setMessageListener(temp);
> > > >                         queueConn.start();
> > > >                 } catch (Exception e)
> > > >                 {
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Setup
> > > > JMS Exception -" +
> > > > e.getMessage());
> > > >
> > > >                         //System.gc();
> > > >                         try
> > > >                         {
> > > >                                 Thread.sleep(60000);
> > > >                         }
> > > >                         catch(Exception er)
> > > >                         {
> > > >                                 logger.error("Exception occured in
> > > > Thread.sleep");
> > > >                         }
> > > >                         return false;
> > > >                 }
> > > >                 return true;
> > > >         }
> > > >
> > > >         private volatile boolean isJMSConnected = false;
> > > >
> > > >         private class ConnectionExceptionListner implements
> > > > ExceptionListener {
> > > >                 @Override
> > > >                 public void onException(JMSException exception) {
> > > >                         isJMSConnected = false;
> > > >
> > > >                         while (true) {
> > > >                                 cleanUp();
> > > >                                 isJMSConnected = setupJMS();
> > > >
> > > >                                 if (isJMSConnected)
> > > >                                 {
> > > >                                                 return;
> > > >                                 } else {
> > > >
> > > >                                         try {
> > > >                                                 //System.gc();
> > > >
> > > >
> >  Thread.sleep(2*60*1000);
> > >
> > > >                                         } catch (Exception e) {
> > > >                                                 System.out.println("
> > > > "+e.getMessage());
> > > >                                         }
> > > >                                 }
> > > >                         }
> > > >                 }
> > > >         }
> > > >
> > > >         private void cleanUp() {
> > > >                 try {
> > > >                         this.queueConn.setExceptionListener(null);
> > > >                 } catch (Exception e) {
> > > >                         // System.out.println("Exception in
> cleanUP()"
> > +
> > >
> > > > e.getMessage());
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > > Exception in JMS cleanUP()"
> > > > + e.getMessage());
> > > >
> > > >                 }
> > > >                 try {
> > > >                         this.queueConn.close();
> > > >                 } catch (Exception e) {
> > > >                         // System.out.println("Exception in
> connection
> > > > close()" +
> > > >                         // e.getMessage());
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > > Exception in JMS connection
> > > > close()" + e.getMessage());
> > > >
> > > >                 }
> > > >         }
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context: http://activemq.2283324.n4.
> > > > nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-
> > > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > >
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > > http://activemq.2283324.n4.nabble.com/Active-Durable-
> Subscriber-status-
> > > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > > tp4728482p4728484.html
> > >
> > > To unsubscribe from Active Durable Subscriber status automatically
> > > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> > click
> > > here.
> > > NAML
> > > =====-----=====-----=====
> > > Notice: The information contained in this e-mail
> > > message and/or attachments to it may contain
> > > confidential or privileged information. If you are
> > > not the intended recipient, any dissemination, use,
> > > review, distribution, printing or copying of the
> > > information contained in this e-mail message
> > > and/or attachments to it are strictly prohibited. If
> > > you have received this communication in error,
> > > please notify us by reply e-mail or telephone and
> > > immediately and permanently delete the message
> > > and any attachments. Thank you
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://activemq.2283324.n4.
> > > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> >
> >
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > tp4728482p4728514.html
> > To unsubscribe from Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> click
> > here.
> > NAML
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728572.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728574.html
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728575.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]

tejas13
Thank you so much for your response.

Issue is resolved after removing that parameter.

Thanks & Regards,
Tejas Ramchandra Sawant
Tata Consultancy Services Ltd.
QBPL, Phase-2, Hinjewadi
Pune, Maharashtra.
cell : +91-8055946458
Mailto: [hidden email]
Website:
http://www.tcs.com

____________________________________________
Experience certainty.        IT Services
                      Business Solutions
                      Consulting
____________________________________________




From:        "Tim Bain [via ActiveMQ]" <[hidden email]>
To:        tejas13 <[hidden email]>
Date:        07/17/2017 06:18 PM
Subject:        Re: Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version]




A maxInactivityDuration of 0 will disable inactivity detection, whose
purpose is to detect both idle TCP connections and TCP connections that
died ungracefully (e.g. due to network partitions), so I believe that your
addition of that parameter caused this behavior. What was the reason you
set it to that value?

Tim

On Jul 15, 2017 1:11 AM, "tejas13" <
[hidden email]> wrote:

>
>
> When this happens with your real-world server (in the morning or the middle
> of the night), are you experiencing network partitions that result in the
> subscriber really truly being offline for some period of time? If so, you
> completely left that out of your initial description, and it means that
> your question is actually, "Why doesn't my consumer reconnect automatically
> after a network partition?" If not, why are you doing that during the test
> you described here?
>
> Network Partition is one reason. There may be another reason also
>
> With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
> difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
> but you see identical behavior for all other steps?
>
> In case of 5.12.3 I found both subscriber offline when network cable
> disconnected and online when connected
>
>
> Is your consumer using a URI that uses the failover transport, to ensure it
> automatically reconnects after the network connection is lost? More
> generally, what URI is your client using to connect to the broker?
>
> Yes I am using fail over protocol
>
> At what Log4J level is your webapp logging for ActiveMQ-related loggers?
> What did you see when you switched them to DEBUG? I find it very surprising
> that you would not see any logging by the client when you pull its network
> cable; I'd expect that there'd be some logging that would occur after your
> TCP session timeout elapses (did you wait that long?) and the client
> figures out that it's not connected to the broker, so if you're not seeing
> anything (Step 6) then I'd wonder whether you have Log4J configured
> correctly.
>
> Yes in case of 5.12.3 I get exception in application. But in 5.14.5 I am
> not getting any error also.
>
> Is there any difference between what's in the logs (either broker or
> webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
> Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
> switching both the broker and the client JARs?
>
> I am using 5.14.3 jars.
>
> One change we did recently in activemq.xml and we faced this issue. That
> change is changing open wire protocol from tcp to nio  and added parameter
> maxInactivityDuration
>
> <transportConnector name="openwire" uri="nio://0.0.0.0:61616?
> maximumConnections=1000&amp;wireFormat.maxFrameSize=
> 104857600&amp;wireFormat.maxInactivityDuration=0"/>
>
>
> Please let me know does this is impacting solution.
>
>
> Thanks & Regards,
> Tejas Ramchandra Sawant
> Tata Consultancy Services Ltd.
> QBPL, Phase-2, Hinjewadi
> Pune, Maharashtra.
> cell : +91-8055946458
> Mailto:
[hidden email]
> Website:
http://www.tcs.com
>
> ____________________________________________
> Experience certainty.        IT Services
>                       Business Solutions
>                       Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <
[hidden email]>
> wrote: -----
> To: tejas13 <
[hidden email]>
> From: "Tim Bain [via ActiveMQ]" <
[hidden email]>
> Date: 07/15/2017 10:30AM
> Subject: Re: Active Durable Subscriber status automatically changing to
> offline Durable Subscriber [5.14.1 Most Stable Version]
>
> When this happens with your real-world server (in the morning or the middle
> of the night), are you experiencing network partitions that result in the
> subscriber really truly being offline for some period of time? If so, you
> completely left that out of your initial description, and it means that
> your question is actually, "Why doesn't my consumer reconnect automatically
> after a network partition?" If not, why are you doing that during the test
> you described here?
>
> With 5.12.3, is SUB1 seen as offline in step 8? That is, is the only
> difference in behavior between 5.12.3 and 5.14.5 what you see in Step 11,
> but you see identical behavior for all other steps?
>
> Is your consumer using a URI that uses the failover transport, to ensure it
> automatically reconnects after the network connection is lost? More
> generally, what URI is your client using to connect to the broker?
>
> At what Log4J level is your webapp logging for ActiveMQ-related loggers?
> What did you see when you switched them to DEBUG? I find it very surprising
> that you would not see any logging by the client when you pull its network
> cable; I'd expect that there'd be some logging that would occur after your
> TCP session timeout elapses (did you wait that long?) and the client
> figures out that it's not connected to the broker, so if you're not seeing
> anything (Step 6) then I'd wonder whether you have Log4J configured
> correctly.
>
> Is there any difference between what's in the logs (either broker or
> webapp) when you use the 5.14.5 client vs. when you use the 5.12.3 client?
> Also, when you said you use 5.12.3 or 5.14.5 for a given test run, are you
> switching both the broker and the client JARs?
>
> Tim
>
> On Fri, Jul 14, 2017 at 10:08 PM, tejas13 <[hidden email]> wrote:
>
> >
> > Hi,
> >
> > Thank you for your response. I did all setup and tested.
> >
> > 1] First I tested with 5.14.5 . I started active mq server on laptop L1.
> > 2] I started application on laptop L2 . Both laptops are in same network
> > 3] So connection established, and I found my 2 [ SUB1 and SUB2 ]
> > subscribers active.
> > 4] After 5 minutes I removed LAN Cable of Laptop L1 on which Active MQ
> > Server is running
> > 5] Still I found both subscribers are listed in Active Durable
> > Subscription list
> > 6] Checked in application also no error observed.
> > 7] Using active mq web console I sent one message in SUB1 subscribed
> topic
> > 8] Then SUB1 went to offline durable subscriber list.
> > 9] SUB2 was in Active Subscriber list only
> > 10] Then I connected LAN cable to Laptop L1.
> > 11] SUB1 was offline he wont come online.
> > 12] SUB2 was in active mode only and able to receive message also.
> >
> > After that same repeated with version 5.12.3 . In this testing I found my
> > both subscribers active after network connection.
> >
> > Please give your inputs.
> >
> > Answers for your queries
> >
> > How long till it goes offline?
> > Every morning, sometimes in mid night. Not fixed time
> >
> > Does it get messages up until that point?
> > No message lost
> >
> > (Are messages even being published? You haven't described any producers
> in
> > your test scenario; do you have any?) Are messages received continuously,
> > or are there long gaps between the messages and/or bursts followed by
> quiet
> > periods?
> >
> > Yes messages are produced with time interval but interval may be 5
> minutes
> > also or 3 hours also.
> >
> >
> >
> > Once the subscriber is offline, does it keep getting messages, or
> > do they stop when it goes offline?
> >
> > No Subscriber doesn't receive any message. After application restart all
> > message get received.
> >
> >
> > How do you know it's offline; what
> > indicator are you looking at? Does it come back to active and then go
> > offline again later (maybe many times over), or does it stay offline from
> > that point onward?
> >
> > End user stop receiving data. Then issue get reported and we come to know
> > about offline case.
> >
> > Does your operating system show the socket (the same
> > socket) as still being open after the subscriber goes offline? (You could
> > use netstat to determine this, if you're on Linux.)
> >
> > We are using windows server
> >
> > Is this behavior easily and quickly reproducible with a minimum of code?
> Is
> > it possible to package up your test scenario (broker configs, producer
> > code, consumer code - anything beyond what you've shown here) so someone
> > else could quickly reproduce the behavior on their own machine, or does
> > this require so much infrastructure and/or time that it's not possible
> for
> > someone else to reproduce?
> >
> > Yes anyone can do it. Just need 2 machines. One for active mq server and
> > one for application. Application is web application deployed in tomcat
> > server.
> >
> >
> > Currently team is restarting tomcat so application get restarted and
> > activemq connection get reestablished. Please help me as we recently
> > upgraded active mq version and application is running in production
> > environment.
> >
> >
> > Thanks & Regards,
> > Tejas Ramchandra Sawant
> > Tata Consultancy Services Ltd.
> > QBPL, Phase-2, Hinjewadi
> > Pune, Maharashtra.
> > cell : +91-8055946458
> > Mailto: [hidden email]
> > Website:
http://www.tcs.com
> >
> > ____________________________________________
> > Experience certainty.        IT Services
> >                       Business Solutions
> >                       Consulting
> > ____________________________________________
> >
> >
> > -----"Tim Bain [via ActiveMQ]" <[hidden email]>
> > wrote: -----
> > To: tejas13 <[hidden email]>
> > From: "Tim Bain [via ActiveMQ]" <[hidden email]>
> > Date: 07/13/2017 09:31AM
> > Subject: Re: Active Durable Subscriber status automatically changing to
> > offline Durable Subscriber [5.14.1 Most Stable Version]
> >
> > If you haven't already, I'd turn logging up to DEBUG on both the broker
> and
> > your client and see if there is any useful information in either log at
> the
> > time that the state changes.
> >
> > Also, can you characterize in more detail what happens to the consumer
> > during the test? Presumably it starts in an active state, but then what?
> > How long till it goes offline? Does it get messages up until that point?
> > (Are messages even being published? You haven't described any producers
> in
> > your test scenario; do you have any?) Are messages received continuously,
> > or are there long gaps between the messages and/or bursts followed by
> quiet
> > periods? Once the subscriber is offline, does it keep getting messages,
> or
> > do they stop when it goes offline? How do you know it's offline; what
> > indicator are you looking at? Does it come back to active and then go
> > offline again later (maybe many times over), or does it stay offline from
> > that point onward? Does your operating system show the socket (the same
> > socket) as still being open after the subscriber goes offline? (You could
> > use netstat to determine this, if you're on Linux.)
> >
> > Is this behavior easily and quickly reproducible with a minimum of code?
> Is
> > it possible to package up your test scenario (broker configs, producer
> > code, consumer code - anything beyond what you've shown here) so someone
> > else could quickly reproduce the behavior on their own machine, or does
> > this require so much infrastructure and/or time that it's not possible
> for
> > someone else to reproduce?
> >
> > Tim
> >
> > On Wed, Jul 12, 2017 at 1:02 AM, tejas13 <[hidden email]> wrote:
> >
> > > Yes JMX Still shown connection is open. I am not getting any exception
> > for
> > > same. Previously I was receiving exception for same, So that time
> > > connection automatically get reestablished.
> > >
> > > Thanks & Regards,
> > > Tejas Ramchandra Sawant
> > > Tata Consultancy Services Ltd.
> > > QBPL, Phase-2, Hinjewadi
> > > Pune, Maharashtra.
> > > cell : +91-8055946458
> > > Mailto: [hidden email]
> > > Website:
http://www.tcs.com
> > >
> > > ____________________________________________
> > > Experience certainty.        IT Services
> > >                        Business Solutions
> > >                        Consulting
> > > ____________________________________________
> > >
> > >
> > >
> > > From:   "Tim Bain [via ActiveMQ]" <[hidden email]>
> > > To:     tejas13 <[hidden email]>
> > > Date:   07/12/2017 12:34 PM
> > > Subject:        Re: Active Durable Subscriber status automatically
> > > changing to offline Durable Subscriber [5.14.1 Most Stable Version]
> > >
> > >
> > >
> > > When your subscriber shows as being offline, does JMX still show that
> the
> > > connection is open? Or are you indeed closing the connection?
> > >
> > > Tim
> > >
> > > On Jul 12, 2017 12:39 AM, "tejas13" <[hidden email]> wrote:
> > >
> > > >
> > > > Hi All,
> > > >
> > > > Thank in Advance.
> > > >
> > > > Previously we were using version 5.12.0. That time my code was
> working
> > > > fine.
> > > > Subscriber never get offline automatically.
> > > >
> > > > Recently we upgraded to version 5.14.5 as most stable version and new
> > > > features
> > > >
> > > > I found that my Active Durable Subscriber status is changing
> > > automatically
> > > > to offline Durable Subscriber.
> > > >
> > > > I am using below code for connection.
> > > >
> > > > public class ReceiverFor_ECRE_TO_SEQ_Topic {
> > > >         private static final Logger logger =
> > > > Logger.getLogger(ReceiverFor_ECRE_TO_SEQ_Topic.class);
> > > >
> > > >         private TopicSession qsen = null;
> > > >         private String JNDI_PROVIDER_URL = null;
> > > >         private String topicName = null;
> > > >         private String jmsUid = null;
> > > >         private String jmsPwd = null;
> > > >         private Topic topic = null;
> > > >         private ConnectionFactory connFactory;
> > > >         private TopicConnection queueConn;
> > > >
> > > >         public ReceiverFor_ECRE_TO_SEQ_Topic(String topicName,
> String
> > > > JNDI_PROVIDER_URL, String jmsUid, String jmsPwd) {
> > > >                 this.topicName = topicName;
> > > >                 this.JNDI_PROVIDER_URL = JNDI_PROVIDER_URL;
> > > >                 this.jmsUid = jmsUid;
> > > >                 this.jmsPwd = jmsPwd;
> > > >         }
> > > >
> > > >         public void listenTopic() {
> > > >                 try {
> > > >                         Properties env = new Properties();
> > > >                         env.put(Context.INITIAL_CONTEXT_FACTORY,
> > > > Constants.INITIAL_CONTEXT_FACTORY);
> > > >                         env.put(Context.PROVIDER_URL,
> > > > System.getProperty(Context.PROVIDER_URL,
> > > > JNDI_PROVIDER_URL));
> > > >                         env.put(Context.SECURITY_PRINCIPAL, jmsUid);
> > > >                         env.put(Context.SECURITY_CREDENTIALS,
> jmsPwd);
> > > > env.setProperty("prefetchPolicy.durableTopicPrefetch",
> > > > "1000");
> > > >                         InitialContext inictx = new
> > InitialContext(env);
> > >
> > > >
> > > >                         // lookup the queue object
> > > >                         topic = (Topic) inictx.lookup(topicName);
> > > >                         // lookup the topic connection factory
> > > >                         connFactory = (ConnectionFactory)
> > > > inictx.lookup(Constants.CONN_FACTORY);
> > > >
> > > >                         // System.out.println("1");
> > > >                         if (setupJMS()) {
> > > >
> > > >                                 isJMSConnected = true;
> > > >                                 /*
> > > >                                  * while(true) { }
> > > >                                  */
> > > >                         } else {
> > > >
> > > >                                 listenTopic();
> > > >
> > > >                         }
> > > >                 } catch (NamingException ex) {
> > > >                         // ex.printStackTrace();
> > > >                         logger.error("Unable to connect Server for
> ECRE
> > > > Topic");
> > > >
> > > >                         try {
> > > >                                 Thread.sleep(5000);
> > > >                                 listenTopic();
> > > >                         } catch (InterruptedException ex1) {
> > > >                                 // ex.printStackTrace();
> > > >                                 logger.error("Unable to connect
> Server
> > > > for ECRE Topic");
> > > >                         }
> > > >                 }
> > > >         }
> > > >
> > > >         public boolean setupJMS()
> > > >         {
> > > >                 try {
> > > >
> > > >                         // create a queue connection
> > > >                         String consumerName =
> > > > ResourceBundleHelper.applicationData.get(
> ApplicationConstants.ECRE_TO_
> > > > SEQ_TOPIC_CONSUMER_Id);
> > > >
> > > >                         queueConn = (TopicConnection)
> > > > connFactory.createConnection();
> > > >                         queueConn.setClientID(consumerName);
> > > >
> > > >                         // create a queue session
> > > >                         // if (null == this.qsen)
> > > >                         {
> > > >                                 this.qsen =
> > > queueConn.createTopicSession(
> > > > false,
> > > > Session.CLIENT_ACKNOWLEDGE);
> > > >                         }
> > > >                         this.queueConn.setExceptionListener(new
> > > > ConnectionExceptionListner());
> > > >                         MessageListenerFor_ECRE_TO_SEQ_Topic temp =
> > new
> > > > MessageListenerFor_ECRE_TO_SEQ_Topic();
> > > >                         // create a queue subscriber
> > > >
> > > >                         // MessageConsumer queueReceiver =
> > > > qsen.createConsumer(topic);
> > > >                         MessageConsumer queueReceiver =
> > > > qsen.createDurableSubscriber(topic,
> > > >                                         consumerName);
> > > >
> > > >                         queueReceiver.setMessageListener(temp);
> > > >                         queueConn.start();
> > > >                 } catch (Exception e)
> > > >                 {
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > Setup
> > > > JMS Exception -" +
> > > > e.getMessage());
> > > >
> > > >                         //System.gc();
> > > >                         try
> > > >                         {
> > > >                                 Thread.sleep(60000);
> > > >                         }
> > > >                         catch(Exception er)
> > > >                         {
> > > >                                 logger.error("Exception occured in
> > > > Thread.sleep");
> > > >                         }
> > > >                         return false;
> > > >                 }
> > > >                 return true;
> > > >         }
> > > >
> > > >         private volatile boolean isJMSConnected = false;
> > > >
> > > >         private class ConnectionExceptionListner implements
> > > > ExceptionListener {
> > > >                 @Override
> > > >                 public void onException(JMSException exception) {
> > > >                         isJMSConnected = false;
> > > >
> > > >                         while (true) {
> > > >                                 cleanUp();
> > > >                                 isJMSConnected = setupJMS();
> > > >
> > > >                                 if (isJMSConnected)
> > > >                                 {
> > > >                                                 return;
> > > >                                 } else {
> > > >
> > > >                                         try {
> > > >                                                 //System.gc();
> > > >
> > > >
> >  Thread.sleep(2*60*1000);
> > >
> > > >                                         } catch (Exception e) {
> > > >                                                 System.out.println("
> > > > "+e.getMessage());
> > > >                                         }
> > > >                                 }
> > > >                         }
> > > >                 }
> > > >         }
> > > >
> > > >         private void cleanUp() {
> > > >                 try {
> > > >                         this.queueConn.setExceptionListener(null);
> > > >                 } catch (Exception e) {
> > > >                         // System.out.println("Exception in
> cleanUP()"
> > +
> > >
> > > > e.getMessage());
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > > Exception in JMS cleanUP()"
> > > > + e.getMessage());
> > > >
> > > >                 }
> > > >                 try {
> > > >                         this.queueConn.close();
> > > >                 } catch (Exception e) {
> > > >                         // System.out.println("Exception in
> connection
> > > > close()" +
> > > >                         // e.getMessage());
> > > >                         logger.error(" ReceiverFor_ECRE_TO_SEQ_Topic
> > > > Exception in JMS connection
> > > > close()" + e.getMessage());
> > > >
> > > >                 }
> > > >         }
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
http://activemq.2283324.n4.
> > > > nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-
> > > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482.html
> > > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > >
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
http://activemq.2283324.n4.nabble.com/Active-Durable-
> Subscriber-status-
> > > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > > tp4728482p4728484.html
> > >
> > > To unsubscribe from Active Durable Subscriber status automatically
> > > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> > click
> > > here.
> > > NAML
> > > =====-----=====-----=====
> > > Notice: The information contained in this e-mail
> > > message and/or attachments to it may contain
> > > confidential or privileged information. If you are
> > > not the intended recipient, any dissemination, use,
> > > review, distribution, printing or copying of the
> > > information contained in this e-mail message
> > > and/or attachments to it are strictly prohibited. If
> > > you have received this communication in error,
> > > please notify us by reply e-mail or telephone and
> > > immediately and permanently delete the message
> > > and any attachments. Thank you
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
http://activemq.2283324.n4.
> > > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728485.html
> > > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> > >
> >
> >
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> > automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> > tp4728482p4728514.html
> > To unsubscribe from Active Durable Subscriber status automatically
> > changing to offline Durable Subscriber [5.14.1 Most Stable Version],
> click
> > here.
> > NAML
> >
> >
> >
> > --
> > View this message in context:
http://activemq.2283324.n4.
> > nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> > offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728572.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
>
> If you reply to this email, your message will be added to the discussion
> below:
>
http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-
> automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-
> tp4728482p4728574.html
> To unsubscribe from Active Durable Subscriber status automatically
> changing to offline Durable Subscriber [5.14.1 Most Stable Version], click
> here.
> NAML

>
>
>
> --
> View this message in context:
http://activemq.2283324.n4.
> nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-
> offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728575.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.





If you reply to this email, your message will be added to the discussion below:
http://activemq.2283324.n4.nabble.com/Active-Durable-Subscriber-status-automatically-changing-to-offline-Durable-Subscriber-5-14-1-Most-St-tp4728482p4728593.html
To unsubscribe from Active Durable Subscriber status automatically changing to offline Durable Subscriber [5.14.1 Most Stable Version], click here.
NAML
Loading...