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 <tejas.sawa...@tcs.com> 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: tejas.sawa...@tcs.com > Website:http://www.tcs.com > > ____________________________________________ > Experience certainty. IT Services > Business Solutions > Consulting > ____________________________________________ > > > -----"Tim Bain [via ActiveMQ]" <ml+s2283324n4728514...@n4.nabble.com> > wrote: ----- > To: tejas13 <tejas.sawa...@tcs.com> > From: "Tim Bain [via ActiveMQ]" <ml+s2283324n4728514...@n4.nabble.com> > 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. >
