You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by bryand <br...@bldixon.net> on 2018/01/24 18:44:23 UTC
JMS Client failover error stops message consumption
I'm using broker-j-7.0.0 and apache-qpid-jms-0-x-6.3.0. For broker-j I have
HA setup with 3 brokers and have been testing failover by simply starting
and stopping the virtual host node on a random broker. Usually failover on
my simple JMS message consumer is successful and message consumption
continues but occasionally I'll receive the following exception on my
consumer and it no longer receives messages:
java.lang.RuntimeException: Dispatcher did not close down within the timeout
of 1000 ms.
My simple java client code is this..
String brokerUrl =
"amqp:///spgqpiddev?failover='roundrobin?cyclecount='2''&brokerlist='tcp://spgappdevmutil:5672?retries='3'&connectdelay='1000';tcp://appprd02:5672?retries='3'&connectdelay='1000';tcp://appprd02:5682?retries='3'&connectdelay='1000''";
ConnectionFactory connectionFactory = new AMQConnectionFactory(brokerUrl);
String user = "appuser";
String pwd = "xxxx";
Connection connection = connectionFactory.createConnection(user, pwd);
connection.start();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
String queueName = "app_testcluster";
Destination destination = AMQDestination.createDestination(queueName,
false);
MessageConsumer messageConsumer = session.createConsumer(destination);
// this MsgListener class simply prints out messages received.
messageConsumer.setMessageListener(new MsgListener());
The full stacktrace is:
count: 500, id: ID:6c8f4df0-c8df-3751-86ee-75cef258de69, ts: 2018-01-24
09:58:49.718, lastTimestamp: 1516805929718, body: null
2018-01-24 13:23:58,820 [10.0.51.42:5672] - ERROR AMQConnectionDelegate_0_10
- error during failover
org.apache.qpid.transport.ConnectionException: connection closed
at org.apache.qpid.transport.Connection.send(Connection.java:414)
at org.apache.qpid.transport.Session.send(Session.java:588)
at org.apache.qpid.transport.Session.invoke(Session.java:804)
at org.apache.qpid.transport.Session.invoke(Session.java:613)
at
org.apache.qpid.transport.SessionInvoker.sessionAttach(SessionInvoker.java:29)
at org.apache.qpid.transport.Session.attach(Session.java:290)
at org.apache.qpid.transport.Session.resume(Session.java:300)
at org.apache.qpid.transport.Connection.resume(Connection.java:524)
at
org.apache.qpid.client.AMQConnectionDelegate_0_10.resubscribeSessions(AMQConnectionDelegate_0_10.java:288)
at
org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1480)
at
org.apache.qpid.client.AMQConnectionDelegate_0_10$2.run(AMQConnectionDelegate_0_10.java:363)
at
org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1959)
at
org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1947)
at
org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1926)
at
org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:340)
at org.apache.qpid.transport.Connection.closed(Connection.java:601)
at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
at
org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
at java.lang.Thread.run(Thread.java:745)
2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- ==== Checking failoverAllowed() ====
2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- Cycle Servers:
Cycle Retries:2
Current Cycle:0
Server Retries:3
Current Retry:0
Current Broker:2
tcp://spgappdevmutil:5672?connectdelay='1000'&retries='3'
tcp://appprd02:5672?connectdelay='1000'&retries='3'
>tcp://appprd02:5682?connectdelay='1000'&retries='3'
2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- ====================================
2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- Trying tcp://appprd02:5682?connectdelay='1000'&retries='3'
2018-01-24 13:23:58,823 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- Delay between connect retries:1000
2018-01-24 13:23:59,826 [10.0.51.42:5672] - ERROR
oggingUncaughtExceptionHandler - Uncaught exception in thread
"IoRcvr-/10.240.15.7:65068-spgappdevmutil/10.0.51.42:5672"
java.lang.RuntimeException: Dispatcher did not close down within the timeout
of 1000 ms.
at org.apache.qpid.client.AMQSession$Dispatcher.close(AMQSession.java:3407)
at
org.apache.qpid.client.AMQSession.markClosedConsumers(AMQSession.java:3047)
at
org.apache.qpid.client.AMQSession.markClosedProducersAndConsumers(AMQSession.java:3077)
at org.apache.qpid.client.AMQSession.markClosed(AMQSession.java:2278)
at
org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:392)
at org.apache.qpid.transport.Connection.closed(Connection.java:601)
at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
at
org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
at java.lang.Thread.run(Thread.java:745)
Exception in thread
"IoRcvr-/10.240.15.7:65068-spgappdevmutil/10.0.51.42:5672"
java.lang.RuntimeException: Dispatcher did not close down within the timeout
of 1000 ms.
at org.apache.qpid.client.AMQSession$Dispatcher.close(AMQSession.java:3407)
at
org.apache.qpid.client.AMQSession.markClosedConsumers(AMQSession.java:3047)
at
org.apache.qpid.client.AMQSession.markClosedProducersAndConsumers(AMQSession.java:3077)
at org.apache.qpid.client.AMQSession.markClosed(AMQSession.java:2278)
at
org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:392)
at org.apache.qpid.transport.Connection.closed(Connection.java:601)
at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
at
org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
at java.lang.Thread.run(Thread.java:745)
2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO AMQConnection
- Cannot connect to broker
(tcp://appprd02:5682?connectdelay='1000'&retries='3'): Virtual host
'spgqpiddev' is not active:Unable to connect to broker at
tcp://appprd02:5682?connectdelay='1000'&retries='3'
2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- ==== Checking failoverAllowed() ====
2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
- Cycle Servers:
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by bryand <br...@bldixon.net>.
Keith, I increased the timeout to 3 seconds and then 10 seconds and still
received the error and message consumption would not continue - the log file
from the test I did with 10 seconds is: qpid-dispatch-timeout.log
<http://qpid.2158936.n2.nabble.com/file/t396334/qpid-dispatch-timeout.log>
I then increased the timeout to 60 seconds and didn't receive the same
dispatcher exception but after the client reconnected after a second
failover it was no longer consuming messages (the same result unfortunately
- the last exception logged in the attached file was
org.apache.qpid.transport.ConnectionException: Connection closed by external
action). The debug logging for that test is here: qpid-connect-timeout.log
<http://qpid.2158936.n2.nabble.com/file/t396334/qpid-connect-timeout.log>
For all tests here is what I did to force fail over in the HA cluster:
1. initial master was node 1. After consuming some messages, I stopped the
virtual host on node 1 (via the web mgt console). I restarted node 1
virtual host within 10 seconds of stopping it.
2. node 3 became the new master and the jms client continued consuming
messages once it successfully failed over to connect to this new master.
3. I then stopped the virtual host node 3 (via the web mgt console). I
restarted node 3 virtual host within 10 seconds of stopping it.
4. node 1 became the new master again. I can see where the jms client
successfully reconnected to it but messages were no longer being consumed.
Also I am using JRE 1.7. - that's why I'm not using the newer Qpid JMS
0.28.0 client. We have some products that are unfortunately still at 1.7 so
that's what I have to use for the time being for these tests.
Thanks for your help.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by Keith W <ke...@gmail.com>.
Bryan
I haven't seen failover exhibit this problem before. The
reconnection logic awaits the dispatcher (a session scoped thread
which invokes your message listen) to finish delivery of the last
message to your application before completing the reconnection. The
dispatcher close allows a period of 1000ms for the dispatcher to
complete its work before timing out. You could try increasing the
timeout (system property -DDISPATCHER_SHUTDOWN_TIMEOUT_MS=<value in
milliseconds>). However, as you say you message listener does not
more than log a message I suspect there might be something else going
on. If increasing the timeout doesn't help, share a complete log
captured at DEBUG level and I'll try and help further.
HTH
Keith.
On 24 January 2018 at 18:44, bryand <br...@bldixon.net> wrote:
> I'm using broker-j-7.0.0 and apache-qpid-jms-0-x-6.3.0. For broker-j I have
> HA setup with 3 brokers and have been testing failover by simply starting
> and stopping the virtual host node on a random broker. Usually failover on
> my simple JMS message consumer is successful and message consumption
> continues but occasionally I'll receive the following exception on my
> consumer and it no longer receives messages:
> java.lang.RuntimeException: Dispatcher did not close down within the timeout
> of 1000 ms.
>
> My simple java client code is this..
>
> String brokerUrl =
> "amqp:///spgqpiddev?failover='roundrobin?cyclecount='2''&brokerlist='tcp://spgappdevmutil:5672?retries='3'&connectdelay='1000';tcp://appprd02:5672?retries='3'&connectdelay='1000';tcp://appprd02:5682?retries='3'&connectdelay='1000''";
>
> ConnectionFactory connectionFactory = new AMQConnectionFactory(brokerUrl);
>
> String user = "appuser";
> String pwd = "xxxx";
>
> Connection connection = connectionFactory.createConnection(user, pwd);
>
> connection.start();
>
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> String queueName = "app_testcluster";
>
> Destination destination = AMQDestination.createDestination(queueName,
> false);
>
> MessageConsumer messageConsumer = session.createConsumer(destination);
> // this MsgListener class simply prints out messages received.
> messageConsumer.setMessageListener(new MsgListener());
>
> The full stacktrace is:
> count: 500, id: ID:6c8f4df0-c8df-3751-86ee-75cef258de69, ts: 2018-01-24
> 09:58:49.718, lastTimestamp: 1516805929718, body: null
> 2018-01-24 13:23:58,820 [10.0.51.42:5672] - ERROR AMQConnectionDelegate_0_10
> - error during failover
> org.apache.qpid.transport.ConnectionException: connection closed
> at org.apache.qpid.transport.Connection.send(Connection.java:414)
> at org.apache.qpid.transport.Session.send(Session.java:588)
> at org.apache.qpid.transport.Session.invoke(Session.java:804)
> at org.apache.qpid.transport.Session.invoke(Session.java:613)
> at
> org.apache.qpid.transport.SessionInvoker.sessionAttach(SessionInvoker.java:29)
> at org.apache.qpid.transport.Session.attach(Session.java:290)
> at org.apache.qpid.transport.Session.resume(Session.java:300)
> at org.apache.qpid.transport.Connection.resume(Connection.java:524)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.resubscribeSessions(AMQConnectionDelegate_0_10.java:288)
> at
> org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1480)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10$2.run(AMQConnectionDelegate_0_10.java:363)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1959)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1947)
> at
> org.apache.qpid.client.AMQConnection.doWithAllLocks(AMQConnection.java:1926)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:340)
> at org.apache.qpid.transport.Connection.closed(Connection.java:601)
> at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
> at
> org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
> at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
> at java.lang.Thread.run(Thread.java:745)
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - ==== Checking failoverAllowed() ====
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - Cycle Servers:
> Cycle Retries:2
> Current Cycle:0
> Server Retries:3
> Current Retry:0
> Current Broker:2
> tcp://spgappdevmutil:5672?connectdelay='1000'&retries='3'
> tcp://appprd02:5672?connectdelay='1000'&retries='3'
>>tcp://appprd02:5682?connectdelay='1000'&retries='3'
>
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - ====================================
> 2018-01-24 13:23:58,822 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - Trying tcp://appprd02:5682?connectdelay='1000'&retries='3'
> 2018-01-24 13:23:58,823 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - Delay between connect retries:1000
> 2018-01-24 13:23:59,826 [10.0.51.42:5672] - ERROR
> oggingUncaughtExceptionHandler - Uncaught exception in thread
> "IoRcvr-/10.240.15.7:65068-spgappdevmutil/10.0.51.42:5672"
> java.lang.RuntimeException: Dispatcher did not close down within the timeout
> of 1000 ms.
> at org.apache.qpid.client.AMQSession$Dispatcher.close(AMQSession.java:3407)
> at
> org.apache.qpid.client.AMQSession.markClosedConsumers(AMQSession.java:3047)
> at
> org.apache.qpid.client.AMQSession.markClosedProducersAndConsumers(AMQSession.java:3077)
> at org.apache.qpid.client.AMQSession.markClosed(AMQSession.java:2278)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:392)
> at org.apache.qpid.transport.Connection.closed(Connection.java:601)
> at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
> at
> org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
> at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
> at java.lang.Thread.run(Thread.java:745)
> Exception in thread
> "IoRcvr-/10.240.15.7:65068-spgappdevmutil/10.0.51.42:5672"
> java.lang.RuntimeException: Dispatcher did not close down within the timeout
> of 1000 ms.
> at org.apache.qpid.client.AMQSession$Dispatcher.close(AMQSession.java:3407)
> at
> org.apache.qpid.client.AMQSession.markClosedConsumers(AMQSession.java:3047)
> at
> org.apache.qpid.client.AMQSession.markClosedProducersAndConsumers(AMQSession.java:3077)
> at org.apache.qpid.client.AMQSession.markClosed(AMQSession.java:2278)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:392)
> at org.apache.qpid.transport.Connection.closed(Connection.java:601)
> at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:113)
> at
> org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:219)
> at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:225)
> at java.lang.Thread.run(Thread.java:745)
> 2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO AMQConnection
> - Cannot connect to broker
> (tcp://appprd02:5682?connectdelay='1000'&retries='3'): Virtual host
> 'spgqpiddev' is not active:Unable to connect to broker at
> tcp://appprd02:5682?connectdelay='1000'&retries='3'
> 2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - ==== Checking failoverAllowed() ====
> 2018-01-24 13:24:00,198 [10.1.1.119:5682] - INFO FailoverRoundRobinServers
> - Cycle Servers:
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by bryand <br...@bldixon.net>.
I changed my testing to wait 5 minutes in between stopping a node and when I
did that message consumption always resumed successfully when the client
failed over to the new master. I realized that the odds of a fail over
occurring twice in just a couple minutes was pretty slim and not the normal
failure scenario.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by Keith W <ke...@gmail.com>.
Bryan
> However, I am still having issues when utilizing session transactions. I stated earlier in this thread that session transactions were working
> correctly for me. That really wasn't accurate. The issue I keep running into is when I try a session commit (either after receiving or sending a
> message) and a failover is in progress the session.commit() raises a JMSException and I don't believe it should.
No, this is not correct. When using failover and transactions
together, you need to be prepared to handle
TransactionRolledBackException [1]. If a failover occurs during the
scope of a JMS Transaction, any work performed by that transaction is
probably lost. The application is made aware of this loss by way of
the TransactionRolledBackException from the Session#commit() call.
Applications utilising failover must be prepared to catch this
exception and respond by repeating the work. Remember, the system as a
whole is giving you an at-least once guarantee. There are failure
scenarios where duplicates can arise. For instance if the successful
response to the tx.commit is lost during the communication breakdown.
I think this will probably explain why your application was
terminating after failover when you expected it wouldn't.
https://docs.oracle.com/javaee/6/api/javax/jms/TransactionRolledBackException.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by bryand <br...@bldixon.net>.
I have example code for the issue I am running into with session.commit()
during message consumption. Here is my test code
TestTxnConsumeExample.java
<http://qpid.2158936.n2.nabble.com/file/t396334/TestTxnConsumeExample.java>
and the debug output qpid-session-cmt-consume-error.log
<http://qpid.2158936.n2.nabble.com/file/t396334/qpid-session-cmt-consume-error.log>
. What happens is message consumption starts, I cause failover to happen on
the server and a JMSException occurs during the session.commit() call when
failover is in progress:
2018-01-30 13:43:51,249 [10.0.51.42:5672] - INFO FailoverRoundRobinServers
- Delay between connect retries:1000
Failed: javax.jms.JMSException: Session exception occurred while trying to
commit: Session sync was interrupted by failover.
javax.jms.JMSException: Session exception occurred while trying to commit:
Session sync was interrupted by failover.
at org.apache.qpid.client.AMQSession.toJMSException(AMQSession.java:3757)
at org.apache.qpid.client.AMQSession.commit(AMQSession.java:927)
After failover completes on the client side it no longer can receive any
messages.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by bryand <br...@bldixon.net>.
Keith, I think part of the issue I was having is that I wasn't defining
enough retry attempts in my connection url. I've noticed the server side
failover usually takes up to 45 seconds and what I had set as options in the
connection url didn't cover that.
However, I am still having issues when utilizing session transactions. I
stated earlier in this thread that session transactions were working
correctly for me. That really wasn't accurate. The issue I keep running
into is when I try a session commit (either after receiving or sending a
message) and a failover is in progress the session.commit() raises a
JMSException and I don't believe it should. And what is really strange
about the session.commit() calls is that an exception is only raised when
the code does a try/catch around that session.commit() call. If I don't do
a try/catch around that method call failover is successful and life is
great. I know this makes no sense but I've been able to reproduce it
several times and have log files and my source code attached so you can
hopefully reproduce it.
My test code is here:
TestTxnExample.java
<http://qpid.2158936.n2.nabble.com/file/t396334/TestTxnExample.java> . It
has the try/catch around the session.commit() call and results in this
attached failure situation where the commit call throws an exception during
failover and the code stops processing. qpid-session-cmt-error.log
<http://qpid.2158936.n2.nabble.com/file/t396334/qpid-session-cmt-error.log>
. I've actually added a sleep of 1 minute to the code when the JMSException
is thrown to try and give the qpid client code time to finish failover
processing and then I continue in the loop to send the next message. When I
do that the previous message that the commit was called for was not
recovered by the qpid client and it is not persisted. Also, I get a
different JMSExcepion that states a rollback needs to be done (or was done -
can't remember).
This log file is from a test I did of the same example code but I didn't
wrap the session.commit() call in a try/catch
qpid-session-cmt-success.log
<http://qpid.2158936.n2.nabble.com/file/t396334/qpid-session-cmt-success.log>
. You can see where failover was successful on the client and I validated
all messages were sent and persisted correctly in the broker.
I noticed that if I leave the try/catch around the session.commit() call but
add a sleep of 200 milliseconds after committing each message in the loop
failover is always successful and a JMSException is never raised when doing
a session.commit() call. It almost seems like a threading/race condition
issue but that's just a complete guess.
Bryan
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by Keith W <ke...@gmail.com>.
Bryan
Thanks for the attachment. I hope to have time to look in detail
later this week. Hopefully there will be a workaround. I mostly see
the failover feature used with transactional JMS applications so this
may explain why the problem you report is unfamiliar to me.
Keith.
On 25 January 2018 at 19:29, bryand <br...@bldixon.net> wrote:
> I have been doing more testing of different scenarios regarding transacted
> sessions and different acknowledgement nodes and here is what I've found
> regarding this topic/behavior:
>
> My initial tests (and what I provided logs for) didn't use transactions and
> used auto acknowledge:
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>
> I also tested with client acknowledgement:
> Session session = connection.createSession(false,
> Session.CLIENT_ACKNOWLEDGE);
> and had the same behavior occur - message consumption stopped after the
> second failover.
>
> I then tested with using transactions (which is our normal use case but not
> 100% of the time):
> Session session = connection.createSession(transacted,
> Session.SESSION_TRANSACTED);
> and this test was successful. I failed over multiple times (at least 3) and
> each time message consumption continued. Messages that could not be
> committed because a failover was in progress were redelivered correctly once
> the client connected to the new master node.
>
>
>
>
> --
> Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: JMS Client failover error stops message consumption
Posted by bryand <br...@bldixon.net>.
I have been doing more testing of different scenarios regarding transacted
sessions and different acknowledgement nodes and here is what I've found
regarding this topic/behavior:
My initial tests (and what I provided logs for) didn't use transactions and
used auto acknowledge:
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
I also tested with client acknowledgement:
Session session = connection.createSession(false,
Session.CLIENT_ACKNOWLEDGE);
and had the same behavior occur - message consumption stopped after the
second failover.
I then tested with using transactions (which is our normal use case but not
100% of the time):
Session session = connection.createSession(transacted,
Session.SESSION_TRANSACTED);
and this test was successful. I failed over multiple times (at least 3) and
each time message consumption continued. Messages that could not be
committed because a failover was in progress were redelivered correctly once
the client connected to the new master node.
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org