You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by tejas13 <te...@tcs.com> on 2017/07/12 06:10:08 UTC
Active Durable Subscriber status automatically changing to offline
Durable Subscriber [5.14.1 Most Stable Version]
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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by tejas13 <te...@tcs.com>.
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.sawant3@tcs.com
Website:http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
From: "Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
To: tejas13 <te...@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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by Tim Bain <tb...@alumni.duke.edu>.
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" <te...@tcs.com> 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: tejas.sawant3@tcs.com
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
> wrote: -----
> To: tejas13 <te...@tcs.com>
> From: "Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
> 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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by tejas13 <te...@tcs.com>.
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: tejas.sawant3@tcs.com
Website:http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
-----"Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com> wrote: -----
To: tejas13 <te...@tcs.com>
From: "Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <te...@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.sawant3@tcs.com
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
>
>
> -----"Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
> wrote: -----
> To: tejas13 <te...@tcs.com>
> From: "Tim Bain [via ActiveMQ]" <ml...@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.
>
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by tejas13 <te...@tcs.com>.
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.sawant3@tcs.com
Website:http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
-----"Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com> wrote: -----
To: tejas13 <te...@tcs.com>
From: "Tim Bain [via ActiveMQ]" <ml...@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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by Tim Bain <tb...@alumni.duke.edu>.
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 <te...@tcs.com> 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: tejas.sawant3@tcs.com
> Website:http://www.tcs.com
>
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
>
>
>
> From: "Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
> To: tejas13 <te...@tcs.com>
> 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.
>
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by tejas13 <te...@tcs.com>.
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: tejas.sawant3@tcs.com
Website:http://www.tcs.com
____________________________________________
Experience certainty. IT Services
Business Solutions
Consulting
____________________________________________
From: "Tim Bain [via ActiveMQ]" <ml...@n4.nabble.com>
To: tejas13 <te...@tcs.com>
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.
Re: Active Durable Subscriber status automatically changing to
offline Durable Subscriber [5.14.1 Most Stable Version]
Posted by Tim Bain <tb...@alumni.duke.edu>.
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" <te...@tcs.com> 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.
>