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: tejas.sawa...@tcs.com Website:http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: "Tim Bain [via ActiveMQ]" <ml+s2283324n4728593...@n4.nabble.com> To: tejas13 <tejas.sawa...@tcs.com> 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&wireFormat.maxFrameSize= > 104857600&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 -- 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-tp4728482p4728596.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
