[jira] [Commented] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575944#comment-16575944 ] Johan Stenberg commented on QPIDJMS-407: [~gemmellr] would it by any chance be possible for you to already cut a release? We are unfortunately facing this issue in production and would like to upgrade the qpid jms client to an official release that containing this fix. Thanks. > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Assignee: Timothy Bish >Priority: Critical > Fix For: 0.36.0 > > Attachments: QPIDJMS-407.zip > > > When a JMS connection with more than one producer session looses the > underlying TCP connection to the broker auto reconnect (failover) is not > working properly. After the reconnect attempt no new messages will be sent. > When only one producer session is used, reconnect apparently works as > expected. > I attached a maven project with a test case where the TCP connection is > dropped by the broker to provoke the reconnect attempt. In most cases when I > run the test class the *testAutoReconnectWith2ProducerSessions()* stops > sending messages after the first reconnect attempt. Maybe there occurs some > qpid internal race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573777#comment-16573777 ] Johan Stenberg commented on QPIDJMS-407: Thanks for the fast fix! > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Assignee: Timothy Bish >Priority: Critical > Fix For: 0.36.0 > > Attachments: QPIDJMS-407.zip > > > When a JMS connection with more than one producer session looses the > underlying TCP connection to the broker auto reconnect (failover) is not > working properly. After the reconnect attempt no new messages will be sent. > When only one producer session is used, reconnect apparently works as > expected. > I attached a maven project with a test case where the TCP connection is > dropped by the broker to provoke the reconnect attempt. In most cases when I > run the test class the *testAutoReconnectWith2ProducerSessions()* stops > sending messages after the first reconnect attempt. Maybe there occurs some > qpid internal race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568869#comment-16568869 ] Johan Stenberg commented on QPIDJMS-407: Yes, same issue. > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QPIDJMS-407.zip > > > When a JMS connection with more than one producer session looses the > underlying TCP connection to the broker auto reconnect (failover) is not > working properly. After the reconnect attempt no new messages will be sent. > When only one producer session is used, reconnect apparently works as > expected. > I attached a maven project with a test case where the TCP connection is > dropped by the broker to provoke the reconnect attempt. In most cases when I > run the test class the *testAutoReconnectWith2ProducerSessions()* stops > sending messages after the first reconnect attempt. Maybe there occurs some > qpid internal race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-407: --- Description: When a JMS connection with more than one producer session looses the underlying TCP connection to the broker auto reconnect (failover) is not working properly. After the reconnect attempt no new messages will be sent. When only one producer session is used, reconnect apparently works as expected. I attached a maven project with a test case where the TCP connection is dropped by the broker to provoke the reconnect attempt. In most cases when I run the test class the *testAutoReconnectWith2ProducerSessions()* stops sending messages after the first reconnect attempt. Maybe there occurs some qpid internal race condition. was: When JMS connection with more than one producer session looses the underlying TCP connection to the broker auto reconnect (failover) is not working. When only one producer session is used, reconnect apparently works as expected. I attached a maven project with a test case where the TCP connection is dropped by the broker to provoke the reconnect attempt. In most cases when I run the test class the *testAutoReconnectWith2ProducerSessions()* stops sending messages after the first reconnect attempt. Maybe there occurs some qpid internal race condition. > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QPIDJMS-407.zip > > > When a JMS connection with more than one producer session looses the > underlying TCP connection to the broker auto reconnect (failover) is not > working properly. After the reconnect attempt no new messages will be sent. > When only one producer session is used, reconnect apparently works as > expected. > I attached a maven project with a test case where the TCP connection is > dropped by the broker to provoke the reconnect attempt. In most cases when I > run the test class the *testAutoReconnectWith2ProducerSessions()* stops > sending messages after the first reconnect attempt. Maybe there occurs some > qpid internal race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-407: --- Description: When JMS connection with more than one producer session looses the underlying TCP connection to the broker auto reconnect (failover) is not working. When only one producer session is used, reconnect apparently works as expected. I attached a maven project with a test case where the TCP connection is dropped by the broker to provoke the reconnect attempt. In most cases when I run the test class the *testAutoReconnectWith2ProducerSessions()* stops sending messages after the first reconnect attempt. Maybe there occurs some qpid internal race condition. was: When JMS connection with more than one producer session looses the underlying TCP connection to the broker auto reconnect (failover) is not working. When only one producer session is used, reconnect apparently works as expected. > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QPIDJMS-407.zip > > > When JMS connection with more than one producer session looses the underlying > TCP connection to the broker auto reconnect (failover) is not working. > When only one producer session is used, reconnect apparently works as > expected. > I attached a maven project with a test case where the TCP connection is > dropped by the broker to provoke the reconnect attempt. In most cases when I > run the test class the *testAutoReconnectWith2ProducerSessions()* stops > sending messages after the first reconnect attempt. Maybe there occurs some > qpid internal race condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
[ https://issues.apache.org/jira/browse/QPIDJMS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-407: --- Attachment: QPIDJMS-407.zip > Reconnect not working reliable for connections with more than 1 producer JMS > session > > > Key: QPIDJMS-407 > URL: https://issues.apache.org/jira/browse/QPIDJMS-407 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.35.0 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QPIDJMS-407.zip > > > When JMS connection with more than one producer session looses the underlying > TCP connection to the broker auto reconnect (failover) is not working. > When only one producer session is used, reconnect apparently works as > expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-407) Reconnect not working reliable for connections with more than 1 producer JMS session
Johan Stenberg created QPIDJMS-407: -- Summary: Reconnect not working reliable for connections with more than 1 producer JMS session Key: QPIDJMS-407 URL: https://issues.apache.org/jira/browse/QPIDJMS-407 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.35.0 Reporter: Johan Stenberg When JMS connection with more than one producer session looses the underlying TCP connection to the broker auto reconnect (failover) is not working. When only one producer session is used, reconnect apparently works as expected. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16549009#comment-16549009 ] Johan Stenberg commented on QPIDJMS-402: Addressed with https://github.com/apache/qpid-jms/commit/264a9a9b6c5d8d8c11a995b7b02289b2938d77ba > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Fix For: 0.35.0 > > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-391) Add support for SSL provider netty-tcnative-boringssl-static
[ https://issues.apache.org/jira/browse/QPIDJMS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-391: --- Labels: performance (was: ) Description: It would be great to have an option to use netty-tcnative-boringssl-static instead of the java based SSL provider. In the ActiveMQ Artemis this was implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 In Netty 4.1.26 a new OpenSslX509KeyManagerFactory for easier configuration was introduced. https://github.com/netty/netty/pull/8084 was:It would be great to have an option to use netty-tcnative-boringssl-static instead of the java based SSL provider. In the ActiveMQ Artemis this was implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 > Add support for SSL provider netty-tcnative-boringssl-static > > > Key: QPIDJMS-391 > URL: https://issues.apache.org/jira/browse/QPIDJMS-391 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Johan Stenberg >Priority: Minor > Labels: performance > > It would be great to have an option to use netty-tcnative-boringssl-static > instead of the java based SSL provider. In the ActiveMQ Artemis this was > implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 > In Netty 4.1.26 a new OpenSslX509KeyManagerFactory for easier configuration > was introduced. https://github.com/netty/netty/pull/8084 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543808#comment-16543808 ] Johan Stenberg commented on QPIDJMS-402: and this https://github.com/LMAX-Exchange/disruptor/issues/157 > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543804#comment-16543804 ] Johan Stenberg commented on QPIDJMS-402: I just came across this, maybe it helps http://vanillajava.blogspot.com/2012/04/yield-sleep0-wait01-and-parknanos1.html > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543365#comment-16543365 ] Johan Stenberg commented on QPIDJMS-402: I'm relieved you can reproduce it too :) I also saw a (however not so dramatic) performance degradation on CloudFoundry managed Java containers running on AWS EC2 instances. > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[
https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543334#comment-16543334
]
Johan Stenberg commented on QPIDJMS-402:
It looks like the new implementation tries to be too clever. The by far best
results I by stripping down the sync method to this:
{code:java}
public void sync() throws IOException {
try {
int idleCount = 0;
while (true) {
if (isComplete()) {
failOnError();
return;
}
if (idleCount < SPIN_COUNT) {
idleCount++;
} else if (idleCount < YIELD_COUNT) {
Thread.yield();
idleCount++;
} else {
synchronized (this) {
if (isComplete()) {
failOnError();
return;
}
waiting++;
try {
wait();
} finally {
waiting--;
}
}
}
}
} catch (final InterruptedException e) {
Thread.interrupted();
throw IOExceptionSupport.create(e);
}
}
{code}
If idleCount is > YIELD_COUNT it seems much more efficient to directly go into
wait instead of doing the parkNanos magic first. Also I strongly believe the
"if currentThread.isInterrupted()" check is unnecessary. Removing it gives me
another good 8-10% higher throughput.
With this code change I get 45.000 msg/s with v0.34 compared to 32.958 msg/s
with v0.33.0. Without that code change I get between 100 and 1000 msg/s with
0.34.0.
> Massive performance degradation in 0.34.0
> -
>
> Key: QPIDJMS-402
> URL: https://issues.apache.org/jira/browse/QPIDJMS-402
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.34.0
> Environment: Windows 7x64 + Oracle JDK 8u161x64
> Windows 7x64 + Open JDK 8u171x64
> CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64
>Reporter: Johan Stenberg
>Priority: Critical
> Attachments: QpidJms402_PerfTest.java,
> image-2018-07-13-16-39-19-707.png, qpidjms402.zip
>
>
> This is a followup issue for
> [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html]
> I am attaching a simple test case that shows the issue. When I use qpid jms
> 0.33 I get 2000msg/s send + receive on my local machine. When I switch to
> 0.34 the message rate drops to 20msg/s.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-402) Massive performance degradation in 0.34.0
[
https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543334#comment-16543334
]
Johan Stenberg edited comment on QPIDJMS-402 at 7/13/18 3:20 PM:
-
It looks like the new implementation tries to be too clever. I get the by far
best results by stripping down the sync method to this:
{code:java}
public void sync() throws IOException {
try {
int idleCount = 0;
while (true) {
if (isComplete()) {
failOnError();
return;
}
if (idleCount < SPIN_COUNT) {
idleCount++;
} else if (idleCount < YIELD_COUNT) {
Thread.yield();
idleCount++;
} else {
synchronized (this) {
if (isComplete()) {
failOnError();
return;
}
waiting++;
try {
wait();
} finally {
waiting--;
}
}
}
}
} catch (final InterruptedException e) {
Thread.interrupted();
throw IOExceptionSupport.create(e);
}
}
{code}
If idleCount is > YIELD_COUNT it seems much more efficient to directly go into
wait instead of doing the parkNanos magic first. Also I strongly believe the
"if currentThread.isInterrupted()" check is unnecessary. Removing it gives me
another good 8-10% higher throughput.
With this code change I get 45.000 msg/s with v0.34 compared to 32.958 msg/s
with v0.33.0. Without that code change I get between 100 and 1000 msg/s with
0.34.0.
was (Author: johan1):
It looks like the new implementation tries to be too clever. The by far best
results I by stripping down the sync method to this:
{code:java}
public void sync() throws IOException {
try {
int idleCount = 0;
while (true) {
if (isComplete()) {
failOnError();
return;
}
if (idleCount < SPIN_COUNT) {
idleCount++;
} else if (idleCount < YIELD_COUNT) {
Thread.yield();
idleCount++;
} else {
synchronized (this) {
if (isComplete()) {
failOnError();
return;
}
waiting++;
try {
wait();
} finally {
waiting--;
}
}
}
}
} catch (final InterruptedException e) {
Thread.interrupted();
throw IOExceptionSupport.create(e);
}
}
{code}
If idleCount is > YIELD_COUNT it seems much more efficient to directly go into
wait instead of doing the parkNanos magic first. Also I strongly believe the
"if currentThread.isInterrupted()" check is unnecessary. Removing it gives me
another good 8-10% higher throughput.
With this code change I get 45.000 msg/s with v0.34 compared to 32.958 msg/s
with v0.33.0. Without that code change I get between 100 and 1000 msg/s with
0.34.0.
> Massive performance degradation in 0.34.0
> -
>
> Key: QPIDJMS-402
> URL: https://issues.apache.org/jira/browse/QPIDJMS-402
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.34.0
> Environment: Windows 7x64 + Oracle JDK 8u161x64
> Windows 7x64 + Open JDK 8u171x64
> CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64
>Reporter: Johan Stenberg
>Priority: Critical
> Attachments: QpidJms402_PerfTest.java,
> image-2018-07-13-16-39-19-707.png, qpidjms402.zip
>
>
> This is a followup issue for
> [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html]
> I am attaching a simple test case that shows the issue. When I use qpid jms
> 0.33 I get 2000msg/s send + receive on my local machine. When I switch to
> 0.34 the message rate drops to 20msg/s.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543320#comment-16543320 ] Johan Stenberg commented on QPIDJMS-402: If I am commenting out these lines [https://github.com/apache/qpid-jms/blob/f29284c6ccf74c9186cea35302c8896cc8089ac5/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/ProviderFuture.java#L215] and [https://github.com/apache/qpid-jms/blob/f29284c6ccf74c9186cea35302c8896cc8089ac5/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/ProviderFuture.java#L218] performance is back to normal. > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543285#comment-16543285 ] Johan Stenberg commented on QPIDJMS-402: On some test runs I also only get 70msg/s. I attached the VisualVM profiler and can see that on these extremly slow runs the ProviderFuture is spending most if its time doing LockSupport.parkNanos(). !image-2018-07-13-16-39-19-707.png! > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: image-2018-07-13-16-39-19-707.png > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16543013#comment-16543013 ] Johan Stenberg commented on QPIDJMS-402: If I am using v0.33 and replace the org.apache.qpid.jms.provider.ProviderFuture class with the one from 0.34. Then I also see the performance degradation. > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[
https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542950#comment-16542950
]
Johan Stenberg commented on QPIDJMS-402:
Creating a new producer in each iteration was not on purpose but a mistake. I
changed the code and removed the semaphores. Running the test case I now get
these results:
v0.33.0:
Sent: 33844 msg/s Received: 35829 msg/s
Sent: 34337 msg/s Received: 35908 msg/s
Sent: 33868 msg/s Received: 32684 msg/s
Sent: 33907 msg/s Received: 35201 msg/s
v0.34.0:
Sent: 1097 msg/s Received: 973 msg/s
Sent: 1905 msg/s Received: 1582 msg/s
Sent: 3066 msg/s Received: 1638 msg/s
Sent: 2663 msg/s Received: 1666 msg/s
Still the new version is 10-30 times slower.
I now used openjdk 1.8.0u171 64bit on Windows 7 64bit (8core,16GB RAM).
I attached a maven project to reproduce the issue. You can now switch qpid jms
version via the qpid-jms.version system property:
{noformat}
mvn test -Dqpid-jms.version=0.33.0
mvn test -Dqpid-jms.version=0.34.0
{noformat}
> Massive performance degradation in 0.34.0
> -
>
> Key: QPIDJMS-402
> URL: https://issues.apache.org/jira/browse/QPIDJMS-402
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.34.0
> Environment: Windows 7x64 + Oracle JDK 8u161x64
> Windows 7x64 + Open JDK 8u171x64
> CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64
>Reporter: Johan Stenberg
>Priority: Critical
> Attachments: QpidJms402_PerfTest.java, qpidjms402.zip
>
>
> This is a followup issue for
> [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html]
> I am attaching a simple test case that shows the issue. When I use qpid jms
> 0.33 I get 2000msg/s send + receive on my local machine. When I switch to
> 0.34 the message rate drops to 20msg/s.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: qpidjms402.zip > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: (was: QpidJms402_Perf2Test.java) > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: QpidJms402_Perf2Test.java > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_Perf2Test.java, QpidJms402_PerfTest.java > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: (was: QpidJms402_PerfTest.java) > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: QpidJms402_PerfTest.java > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-402: --- Attachment: QpidJms402_PerfTest.java > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-402) Massive performance degradation in 0.34.0
Johan Stenberg created QPIDJMS-402: -- Summary: Massive performance degradation in 0.34.0 Key: QPIDJMS-402 URL: https://issues.apache.org/jira/browse/QPIDJMS-402 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.34.0 Environment: Windows 7x64 + Oracle JDK 8u161x64 Windows 7x64 + Open JDK 8u171x64 CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 Reporter: Johan Stenberg This is a followup issue for [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] I am attaching a simple test case that shows the issue. When I use qpid jms 0.33 I get 2000msg/s send + receive on my local machine. When I switch to 0.34 the message rate drops to 20msg/s. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-391) Add support for SSL provider netty-tcnative-boringssl-static
Johan Stenberg created QPIDJMS-391: -- Summary: Add support for SSL provider netty-tcnative-boringssl-static Key: QPIDJMS-391 URL: https://issues.apache.org/jira/browse/QPIDJMS-391 Project: Qpid JMS Issue Type: New Feature Components: qpid-jms-client Reporter: Johan Stenberg It would be great to have an option to use netty-tcnative-boringssl-static instead of the java based SSL provider. In the ActiveMQ Artemis this was implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: QpidJms388_RuntimeExectionInOnMessageTest.java > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: (was: QpidJms388_RuntimeExectionInOnMessageTest.java) > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
[ https://issues.apache.org/jira/browse/QPIDJMS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johan Stenberg updated QPIDJMS-388: --- Attachment: QpidJms388_RuntimeExectionInOnMessageTest.java > Unhandled RuntimeException in MessageListener#onMessage does not increment > AMQP delivery count in AUTO_ACK > -- > > Key: QPIDJMS-388 > URL: https://issues.apache.org/jira/browse/QPIDJMS-388 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: QpidJms388_RuntimeExectionInOnMessageTest.java > > > The JMS spec states: "The result of a listener throwing a RuntimeException > depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or > DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The > 'JMSRedelivered' message header field will be set, and the > 'JMSXDeliveryCount' message property incremented, for a message redelivered > under these circumstances." > Currently qpid-jms however is not incrementing the deliveryCount or setting > the redelivered message header to true when a listener throws a > runtimeexception while in AUTO_ACK. > This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and > endless redelivery attempts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-388) Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK
Johan Stenberg created QPIDJMS-388: -- Summary: Unhandled RuntimeException in MessageListener#onMessage does not increment AMQP delivery count in AUTO_ACK Key: QPIDJMS-388 URL: https://issues.apache.org/jira/browse/QPIDJMS-388 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Johan Stenberg The JMS spec states: "The result of a listener throwing a RuntimeException depends on the session's acknowledgment mode. AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: the message will be immediately redelivered. ... The 'JMSRedelivered' message header field will be set, and the 'JMSXDeliveryCount' message property incremented, for a message redelivered under these circumstances." Currently qpid-jms however is not incrementing the deliveryCount or setting the redelivered message header to true when a listener throws a runtimeexception while in AUTO_ACK. This results in "jms.redeliveryPolicy.maxRedeliveries" being ignored and endless redelivery attempts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
