[jira] [Created] (QPIDJMS-396) Performance improvements for inter-thread event signalling
Timothy Bish created QPIDJMS-396: Summary: Performance improvements for inter-thread event signalling Key: QPIDJMS-396 URL: https://issues.apache.org/jira/browse/QPIDJMS-396 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.33.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.34.0 Improve the ability to detect and respond to event completions of requests being handled by different threads within the client without incurring the overhead of signals and wait completions. -- 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-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517277#comment-16517277
]
Timothy Bish commented on QPIDJMS-395:
--
Would you not be testing for
[JMSSecurityException|https://docs.oracle.com/javaee/7/api/javax/jms/JMSSecurityException.html]
in that case?
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:854)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The PN_TRACE_FRM log for this is
> {noformat}
> [...]
> [1476077082:1] -> Transfer{handle=0, deliveryId=221, deliveryTag=\x00,
> messageFormat=0, settled=null, more=false,
[jira] [Commented] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517273#comment-16517273
]
Timothy Bish commented on QPIDJMS-395:
--
Having a JMS client specific exception would mean that those using it are now
tied to that client implementation. The other question I'd ask would be, what
exception that is thrown from send would indicate that a resend wasn't needed?
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:854)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The PN_TRACE_FRM log for this is
> {noformat}
> [...]
> [1476077082:1] ->
[jira] [Resolved] (QPIDJMS-394) Completion Listener singaled in error when send blocked waiting for failover
[ https://issues.apache.org/jira/browse/QPIDJMS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-394. -- Resolution: Fixed > Completion Listener singaled in error when send blocked waiting for failover > > > Key: QPIDJMS-394 > URL: https://issues.apache.org/jira/browse/QPIDJMS-394 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > If a send is issued using a completion listener and it blocks waiting for > credit or just happens to land in the Failover provider at the right moment > during connection loss the send will be held in the failover provider and > reissued on reconnect. During reconnection processing inflight async > completion sends are failed as their state is not recoverable and this can > lead to a signal of failed send to the blocked completion send attempt in > error. -- 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-394) Completion Listener singaled in error when send blocked waiting for failover
Timothy Bish created QPIDJMS-394: Summary: Completion Listener singaled in error when send blocked waiting for failover Key: QPIDJMS-394 URL: https://issues.apache.org/jira/browse/QPIDJMS-394 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.33.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.34.0 If a send is issued using a completion listener and it blocks waiting for credit or just happens to land in the Failover provider at the right moment during connection loss the send will be held in the failover provider and reissued on reconnect. During reconnection processing inflight async completion sends are failed as their state is not recoverable and this can lead to a signal of failed send to the blocked completion send attempt in error. -- 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] [Resolved] (QPIDJMS-393) Async Completion sends not signaled when sent while TX is in doubt
[ https://issues.apache.org/jira/browse/QPIDJMS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-393. -- Resolution: Fixed > Async Completion sends not signaled when sent while TX is in doubt > -- > > Key: QPIDJMS-393 > URL: https://issues.apache.org/jira/browse/QPIDJMS-393 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.33.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.34.0 > > > After a failover occurs while an active TX is in play the TX will be placed > in an in-doubt state and all sends that are made prior to a commit or > rollback will be effectively turned into a no-op. If however an async > completion send is done the code does not signal the onCompletion event of > the given CompletionListener. -- 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-393) Async Completion sends not signaled when sent while TX is in doubt
Timothy Bish created QPIDJMS-393: Summary: Async Completion sends not signaled when sent while TX is in doubt Key: QPIDJMS-393 URL: https://issues.apache.org/jira/browse/QPIDJMS-393 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.33.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.34.0 After a failover occurs while an active TX is in play the TX will be placed in an in-doubt state and all sends that are made prior to a commit or rollback will be effectively turned into a no-op. If however an async completion send is done the code does not signal the onCompletion event of the given CompletionListener. -- 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 ] Timothy Bish updated QPIDJMS-391: - Priority: Minor (was: Major) > 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 > > 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] [Created] (QPIDJMS-390) Use Atomic Field Updater for case where we create many AtomicBoolean instances
Timothy Bish created QPIDJMS-390: Summary: Use Atomic Field Updater for case where we create many AtomicBoolean instances Key: QPIDJMS-390 URL: https://issues.apache.org/jira/browse/QPIDJMS-390 Project: Qpid JMS Issue Type: Improvement Affects Versions: 0.32.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.33.0 Use an Atomic field updater for the future we use for most provider operations as opposed to creating an AtomicBoolean for each instance of the the future class. -- 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] [Resolved] (QPIDJMS-389) JMS 2.0 Async CompletionListener can be notified in error
[ https://issues.apache.org/jira/browse/QPIDJMS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-389. -- Resolution: Fixed > JMS 2.0 Async CompletionListener can be notified in error > - > > Key: QPIDJMS-389 > URL: https://issues.apache.org/jira/browse/QPIDJMS-389 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.33.0 > > > If two producers are created for a single session and one producer is used to > send a message using an CompletionListener and the other producer happens to > be remotely closed the sent message CompletionListener will be notified of > completion in error if it hadn't already completed. -- 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-389) JMS 2.0 Async CompletionListener can be notified in error
Timothy Bish created QPIDJMS-389: Summary: JMS 2.0 Async CompletionListener can be notified in error Key: QPIDJMS-389 URL: https://issues.apache.org/jira/browse/QPIDJMS-389 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.33.0 If two producers are created for a single session and one producer is used to send a message using an CompletionListener and the other producer happens to be remotely closed the sent message CompletionListener will be notified of completion in error if it hadn't already completed. -- 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] [Assigned] (QPIDJMS-386) failover provider prevents handling of remote resource closure from completing correctly
[ https://issues.apache.org/jira/browse/QPIDJMS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned QPIDJMS-386: Assignee: Timothy Bish (was: Robbie Gemmell) > failover provider prevents handling of remote resource closure from > completing correctly > > > Key: QPIDJMS-386 > URL: https://issues.apache.org/jira/browse/QPIDJMS-386 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.32.0 > Environment: >Reporter: Robbie Gemmell >Assignee: Timothy Bish >Priority: Major > Fix For: 0.33.0 > > > QPIDJMS-376 added functionality to fire the connection ExceptionListener if a > MessageConsumer with a MessageListener is remotely closed, since the lack of > future message deliveries would mean the application has no further > interaction with the consumer to observe the issue. It has since been > identified that this doesn't occur when using the built in failover provider, > which is preventing the process of handling the remote consumer resource > closure from completing fully. -- 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 ] Timothy Bish updated QPIDJMS-388: - Priority: Minor (was: Major) > 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: Minor > 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] [Resolved] (QPIDJMS-387) Update Netty to 4-1-25-Final and ActiveMQ 5.15.4
[ https://issues.apache.org/jira/browse/QPIDJMS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-387. -- Resolution: Fixed > Update Netty to 4-1-25-Final and ActiveMQ 5.15.4 > - > > Key: QPIDJMS-387 > URL: https://issues.apache.org/jira/browse/QPIDJMS-387 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.32.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.33.0 > > > Update Netty to latest release 4.1.25.Final and update ActiveMQ 5.15.4 > release in the test suite. -- 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-387) Update Netty to 4-1-25-Final and ActiveMQ 5.15.4
Timothy Bish created QPIDJMS-387: Summary: Update Netty to 4-1-25-Final and ActiveMQ 5.15.4 Key: QPIDJMS-387 URL: https://issues.apache.org/jira/browse/QPIDJMS-387 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.32.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.33.0 Update Netty to latest release 4.1.25.Final and update ActiveMQ 5.15.4 release in the test suite. -- 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] [Resolved] (QPIDJMS-378) Update Netty to latest 4.1.24.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-378. -- Resolution: Fixed > Update Netty to latest 4.1.24.Final > --- > > Key: QPIDJMS-378 > URL: https://issues.apache.org/jira/browse/QPIDJMS-378 > Project: Qpid JMS > Issue Type: Task >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.32.0 > > > Update netty to latest release -- 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] [Resolved] (QPIDJMS-380) Implement ConnectionConsumer to enable use in resource adapters
[ https://issues.apache.org/jira/browse/QPIDJMS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-380. -- Resolution: Fixed > Implement ConnectionConsumer to enable use in resource adapters > --- > > Key: QPIDJMS-380 > URL: https://issues.apache.org/jira/browse/QPIDJMS-380 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.31.0 >Reporter: Justin Ross >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > -- 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] [Resolved] (QPIDJMS-384) Add support for user user defined extensions to override client configuration
[ https://issues.apache.org/jira/browse/QPIDJMS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-384. -- Resolution: Fixed > Add support for user user defined extensions to override client configuration > - > > Key: QPIDJMS-384 > URL: https://issues.apache.org/jira/browse/QPIDJMS-384 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > > Implement a means of injecting user defined configuration overrides that > allow the client to query user code to obtain various configuration values > such as HTTP headers for WebSocket authentication of per connection login > credentials in failover scenarios. -- 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-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452710#comment-16452710
]
Timothy Bish commented on QPIDJMS-373:
--
You can now add callbacks that will be executed on each connection via
QPIDJMS-384 which allows for this sort of thing. The HTTP Headers used on WS
handshaking can be updated now and an example is added in this [test
case.|https://github.com/apache/qpid-jms/blob/master/qpid-jms-client/src/test/java/org/apache/qpid/jms/transports/netty/NettyTcpToMockServerTest.java#L303]
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") (-and
> setting of "Authorization" Header- moved into
> [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during
> WebSocket connection handshake.
> -Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).- (see above)
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
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] [Resolved] (QPIDJMS-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.
[
https://issues.apache.org/jira/browse/QPIDJMS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-375.
--
Resolution: Fixed
Assignee: Timothy Bish
Fix Version/s: 0.32.0
QPIDJMS-384 Adds features that allow for this by using URI configuration or by
injecting a callback function that provides the HTTP headers to the WS
Transport.
The URI can be configured via options such as
"transport.ws.httpHeader.Authorization=FOO"
> Enable setting of an "Authorization" Header during WebSocket connection
> handshake.
> --
>
> Key: QPIDJMS-375
> URL: https://issues.apache.org/jira/browse/QPIDJMS-375
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> Add support for setting of an "Authorization" Header during WebSocket
> connection handshake.
> This "Authorization" Header will be passed via the "transport" parameters
> (TransportOptions).
> Proposed transport is {{transport.ws.authorizationHeader}}.
> According "[Pull Request|https://github.com/apache/qpid-jms/pull/18];
--
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-384) Add support for user user defined extensions to override client configuration
Timothy Bish created QPIDJMS-384: Summary: Add support for user user defined extensions to override client configuration Key: QPIDJMS-384 URL: https://issues.apache.org/jira/browse/QPIDJMS-384 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.31.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.32.0 Implement a means of injecting user defined configuration overrides that allow the client to query user code to obtain various configuration values such as HTTP headers for WebSocket authentication of per connection login credentials in failover scenarios. -- 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] [Resolved] (QPIDJMS-383) Utilize new proton-j APIs to eleminate coping delivery buffers
[ https://issues.apache.org/jira/browse/QPIDJMS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-383. -- Resolution: Fixed > Utilize new proton-j APIs to eleminate coping delivery buffers > -- > > Key: QPIDJMS-383 > URL: https://issues.apache.org/jira/browse/QPIDJMS-383 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > > Using newer send and receive APIs in proton-j 0.27.0 we can eliminate a copy > of the delivery bytes on both the send and receive side of delivery > processing. > -- 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-383) Utilize new proton-j APIs to eleminate coping delivery buffers
Timothy Bish created QPIDJMS-383: Summary: Utilize new proton-j APIs to eleminate coping delivery buffers Key: QPIDJMS-383 URL: https://issues.apache.org/jira/browse/QPIDJMS-383 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.31.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.32.0 Using newer send and receive APIs in proton-j 0.27.0 we can eliminate a copy of the delivery bytes on both the send and receive side of delivery processing. -- 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-380) Implement ConnectionConsumer to enable use in resource adapters
[ https://issues.apache.org/jira/browse/QPIDJMS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-380: - Fix Version/s: 0.32.0 > Implement ConnectionConsumer to enable use in resource adapters > --- > > Key: QPIDJMS-380 > URL: https://issues.apache.org/jira/browse/QPIDJMS-380 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.31.0 >Reporter: Justin Ross >Priority: Major > Fix For: 0.32.0 > > -- 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-380) Implement ConnectionConsumer to enable use in resource adapters
[ https://issues.apache.org/jira/browse/QPIDJMS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-380: - Affects Version/s: 0.31.0 > Implement ConnectionConsumer to enable use in resource adapters > --- > > Key: QPIDJMS-380 > URL: https://issues.apache.org/jira/browse/QPIDJMS-380 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.31.0 >Reporter: Justin Ross >Priority: Major > Fix For: 0.32.0 > > -- 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] [Assigned] (QPIDJMS-380) Implement ConnectionConsumer to enable use in resource adapters
[ https://issues.apache.org/jira/browse/QPIDJMS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned QPIDJMS-380: Assignee: Timothy Bish > Implement ConnectionConsumer to enable use in resource adapters > --- > > Key: QPIDJMS-380 > URL: https://issues.apache.org/jira/browse/QPIDJMS-380 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.31.0 >Reporter: Justin Ross >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > -- 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] [Resolved] (QPIDJMS-379) Reduce garbage create on input from transport
[ https://issues.apache.org/jira/browse/QPIDJMS-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-379. -- Resolution: Fixed > Reduce garbage create on input from transport > - > > Key: QPIDJMS-379 > URL: https://issues.apache.org/jira/browse/QPIDJMS-379 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > > The input processor can be simplified to reduce temporary objects create on > incoming bytes processing. -- 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-379) Reduce garbage create on input from transport
Timothy Bish created QPIDJMS-379: Summary: Reduce garbage create on input from transport Key: QPIDJMS-379 URL: https://issues.apache.org/jira/browse/QPIDJMS-379 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.31.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.32.0 The input processor can be simplified to reduce temporary objects create on incoming bytes processing. -- 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-378) Update Netty to latest 4.1.23.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-378: - Affects Version/s: 0.31.0 > Update Netty to latest 4.1.23.Final > --- > > Key: QPIDJMS-378 > URL: https://issues.apache.org/jira/browse/QPIDJMS-378 > Project: Qpid JMS > Issue Type: Task >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.32.0 > > > Update netty to latest release -- 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] [Resolved] (QPIDJMS-378) Update Netty to latest 4.1.23.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-378. -- Resolution: Fixed Assignee: Timothy Bish Fix Version/s: 0.32.0 > Update Netty to latest 4.1.23.Final > --- > > Key: QPIDJMS-378 > URL: https://issues.apache.org/jira/browse/QPIDJMS-378 > Project: Qpid JMS > Issue Type: Task >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.32.0 > > > Update netty to latest release -- 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-378) Update Netty to latest 4.1.23.Final
Timothy Bish created QPIDJMS-378: Summary: Update Netty to latest 4.1.23.Final Key: QPIDJMS-378 URL: https://issues.apache.org/jira/browse/QPIDJMS-378 Project: Qpid JMS Issue Type: Task Reporter: Timothy Bish Update netty to latest release -- 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] [Resolved] (QPIDJMS-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)
[ https://issues.apache.org/jira/browse/QPIDJMS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-377. -- Resolution: Fixed > Update testing dependencies (ActiveMQ, MiniKDC and Mockito) > --- > > Key: QPIDJMS-377 > URL: https://issues.apache.org/jira/browse/QPIDJMS-377 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.32.0 > > > Update test dependencies to latest versions -- 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-377) Update testing dependencies (ActiveMQ, MiniKDC and Mockito)
Timothy Bish created QPIDJMS-377: Summary: Update testing dependencies (ActiveMQ, MiniKDC and Mockito) Key: QPIDJMS-377 URL: https://issues.apache.org/jira/browse/QPIDJMS-377 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.31.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.32.0 Update test dependencies to latest versions -- 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] [Closed] (PROTON-1410) Move MessageImpl::TLS to an utility class
[ https://issues.apache.org/jira/browse/PROTON-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed PROTON-1410. Resolution: Won't Fix > Move MessageImpl::TLS to an utility class > - > > Key: PROTON-1410 > URL: https://issues.apache.org/jira/browse/PROTON-1410 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: clebert suconic >Priority: Major > > I have a need to create a special Message on Artemis, that will only parse > the Header and send everything else as a byte array. > Instead of duplicating the TLS logic, I would like to move this to its own > class so it could be reused. -- 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] [Resolved] (PROTON-1672) Large deliveries comprising many transfers are handled inefficiently
[
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved PROTON-1672.
--
Resolution: Fixed
> Large deliveries comprising many transfers are handled inefficiently
>
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0)
> shows that receipt of large messages is very slow in comparison with the send
> of the same message. For instance, sending 300MiB bytes message takes 5
> seconds on my laptop. The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}}
> re-allocates/array copies the entire delivery buffer for ever transfer that
> comprises it. This leads to a non-linear loss of performance. The stack
> include Proton-J 0.23.0, but is looks like this code is unchanged.
--
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] (PROTON-1672) Large deliveries comprising many transfers are handled inefficiently
[
https://issues.apache.org/jira/browse/PROTON-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated PROTON-1672:
-
Fix Version/s: proton-j-0.27.0
> Large deliveries comprising many transfers are handled inefficiently
>
>
> Key: PROTON-1672
> URL: https://issues.apache.org/jira/browse/PROTON-1672
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-j
>Affects Versions: proton-j-0.23.0
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: proton-j-0.27.0
>
> Attachments: JProfiler_PROTON-1672.tiff
>
>
> Running performance tests using Qpid Broker J and Qpid JMS Client (0.26.0)
> shows that receipt of large messages is very slow in comparison with the send
> of the same message. For instance, sending 300MiB bytes message takes 5
> seconds on my laptop. The receipt takes 97 seconds.
> Instrumenting the client stack shows an obvious hot-spot in Proton-J.
> {{org.apache.qpid.proton.engine.impl.TransportSession#handleTransfer}}
> re-allocates/array copies the entire delivery buffer for ever transfer that
> comprises it. This leads to a non-linear loss of performance. The stack
> include Proton-J 0.23.0, but is looks like this code is unchanged.
--
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-376) notify the ExceptionListner when a consumer with a MessageListener remotely closes
[ https://issues.apache.org/jira/browse/QPIDJMS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-376: - Fix Version/s: 0.32.0 > notify the ExceptionListner when a consumer with a MessageListener remotely > closes > -- > > Key: QPIDJMS-376 > URL: https://issues.apache.org/jira/browse/QPIDJMS-376 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 > Environment: AMQP Server: Enmasse 0.17.1 > Enmasse Address Type: anycast >Reporter: Daniel Maier >Priority: Major > Fix For: 0.32.0 > > Attachments: clientlogs.txt > > > When I create a consumer to an address that just does not exist, I expected > to get some exception or that the client retries the operation. But there > seems not even to be a log message which indicates a failure. > Is this intended behavior or is this a bug? A more general description is: If > AMQP server closes the receiver link, qpid jms client does not notify the > user anyhow or does not re-establish the link. -- 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] [Resolved] (QPIDJMS-374) Double encoded query parameters
[
https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-374.
--
Resolution: Fixed
Assignee: Timothy Bish
Fix Version/s: 0.32.0
> Double encoded query parameters
> ---
>
> Key: QPIDJMS-374
> URL: https://issues.apache.org/jira/browse/QPIDJMS-374
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.31.0
>Reporter: Michael Bolz
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.32.0
>
>
> When query parameters are parsed in
> [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51]
> and
> [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41]
> and than further processed via
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]
> the values gets double encoded.
> See also Javadoc of
> [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]:
> {quote}
> The string values in the Map will be URL Encoded by this method which means
> that if an
> already encoded value is passed it will be double encoded resulting in
> corrupt values
> in the newly created URI.
> {quote}
> For a fix I created a [pull
> request|https://github.com/apache/qpid-jms/pull/17].
--
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] [Resolved] (PROTON-1811) [proton-j] FrameWriter refactoring to reduce code on the hot path and reduce allocations of EmptyFrame
[ https://issues.apache.org/jira/browse/PROTON-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1811. -- Resolution: Fixed > [proton-j] FrameWriter refactoring to reduce code on the hot path and reduce > allocations of EmptyFrame > -- > > Key: PROTON-1811 > URL: https://issues.apache.org/jira/browse/PROTON-1811 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: proton-j-0.27.0 > > > Some small refactoring inside FrameWriter to reduce the code on the hot path > to allow for inlining of the common case. Also removes the need to allocate > EmptyFrame for logging on tick handling. -- 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] (PROTON-1811) [proton-j] FrameWriter refactoring to reduce code on the hot path and reduce allocations of EmptyFrame
Timothy Bish created PROTON-1811: Summary: [proton-j] FrameWriter refactoring to reduce code on the hot path and reduce allocations of EmptyFrame Key: PROTON-1811 URL: https://issues.apache.org/jira/browse/PROTON-1811 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.27.0 Some small refactoring inside FrameWriter to reduce the code on the hot path to allow for inlining of the common case. Also removes the need to allocate EmptyFrame for logging on tick handling. -- 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] [Resolved] (PROTON-1808) [proton-j] FrameWriter allocates additional buffer capacity inefficiently
[ https://issues.apache.org/jira/browse/PROTON-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1808. -- Resolution: Fixed > [proton-j] FrameWriter allocates additional buffer capacity inefficiently > - > > Key: PROTON-1808 > URL: https://issues.apache.org/jira/browse/PROTON-1808 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: proton-j-0.27.0 > > > When writing a Transfer that has a larger payload than previously seen the > FrameWriter may need to grow its internal buffer to accommodate that > transfer. The current strategy is to double the capacity of the current > buffer and copy the old bytes into the new buffer and then check again if > there is room. Depending on the frame size setting and the size of the > transfer this can result in a large amount of garbage being created and a > number of unneeded copies of encoded performative data. -- 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] (PROTON-1808) [proton-j] FrameWriter allocates additional buffer capacity inefficiently
Timothy Bish created PROTON-1808: Summary: [proton-j] FrameWriter allocates additional buffer capacity inefficiently Key: PROTON-1808 URL: https://issues.apache.org/jira/browse/PROTON-1808 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.27.0 When writing a Transfer that has a larger payload than previously seen the FrameWriter may need to grow its internal buffer to accommodate that transfer. The current strategy is to double the capacity of the current buffer and copy the old bytes into the new buffer and then check again if there is room. Depending on the frame size setting and the size of the transfer this can result in a large amount of garbage being created and a number of unneeded copies of encoded performative data. -- 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] [Resolved] (QPIDJMS-369) Failover doesn't apply max reconnect attempts on initial connect when remote is closing on the Open frame
[ https://issues.apache.org/jira/browse/QPIDJMS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-369. -- Resolution: Fixed > Failover doesn't apply max reconnect attempts on initial connect when remote > is closing on the Open frame > - > > Key: QPIDJMS-369 > URL: https://issues.apache.org/jira/browse/QPIDJMS-369 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.30.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.31.0 > > > If the transport has not yet connect to a remote and all hosts are rejecting > on the Open frame the failover transport does not properly apply the max > reconnect or startup max reconnect attempts setting and will attempt to > connect until closed. -- 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-369) Failover doesn't apply max reconnect attempts on initial connect when remote is closing on the Open frame
Timothy Bish created QPIDJMS-369: Summary: Failover doesn't apply max reconnect attempts on initial connect when remote is closing on the Open frame Key: QPIDJMS-369 URL: https://issues.apache.org/jira/browse/QPIDJMS-369 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.30.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.31.0 If the transport has not yet connect to a remote and all hosts are rejecting on the Open frame the failover transport does not properly apply the max reconnect or startup max reconnect attempts setting and will attempt to connect until closed. -- 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] [Resolved] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-366.
--
Resolution: Fixed
The reported issue has been resolved. Please open a new issue to cover the
newly reported problems and provide detailed instructions to reproduce along
with any supporting logs or reproducer tests
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 054e24_qpid366_initalconnattemptfailsgracefully.log,
> 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16407135#comment-16407135
]
Timothy Bish commented on QPIDJMS-366:
--
This should be resolved now if you want to give it another test using the
current master.
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-366:
-
Fix Version/s: 0.31.0
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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] [Assigned] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reassigned QPIDJMS-366:
Assignee: Timothy Bish
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405344#comment-16405344
]
Timothy Bish commented on QPIDJMS-366:
--
I've tried to reproduce it but had no luck. A test or some supporting logs
would be helpful
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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] [Resolved] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-365.
--
Resolution: Fixed
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> ... 11 more
> 2018-03-13 11:04:54,954 [ connect
[jira] [Reopened] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reopened QPIDJMS-365:
--
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> ... 11 more
> 2018-03-13 11:04:54,954 [ connect thread] - DEBUG
[jira] [Updated] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-365:
-
Fix Version/s: 0.31.0
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> ... 11 more
> 2018-03-13 11:04:54,954 [ connect
[jira] [Resolved] (QPIDJMS-368) Connection URL keystore/truststore/user passwords can be reported unmasked as part of client logs
[
https://issues.apache.org/jira/browse/QPIDJMS-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-368.
--
Resolution: Fixed
Assignee: Timothy Bish
Fix Version/s: 0.31.0
> Connection URL keystore/truststore/user passwords can be reported unmasked as
> part of client logs
> -
>
> Key: QPIDJMS-368
> URL: https://issues.apache.org/jira/browse/QPIDJMS-368
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.30.0
>Reporter: Alex Rudyy
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
>
> Connection URL keystore/truststore/user passwords can be reported unmasked as
> part of client logs in the following cases:
> # when no failover is configured, a failed attempt to establish connectivity
> results in issuing the ERROR log as below
> {noformat}
> ERROR [main] o.a.q.j.JmsConnection Failed to connect to remote at:
> amqps://localhost:5672?transport.keyStoreLocation=%2Fpath%2Fkeystore.jks=password=%2Fpath%2Fto%2Ftrsustore.jks=password
> {noformat}
> # when failover is configured, a connectivity attempt can end-up in logs
> like below
> {noformat}
> DEBUG [FailoverProvider: connect thread] o.a.q.j.p.f.FailoverProvider
> Connection attempt:[1] to:
> amqps://localhost:5672?transport.keyStoreLocation=/path/to/truststore.jks=password=/path/to/keystore.jks=password=admin=password
> in-progress
> INFO [FailoverProvider: connect thread] o.a.q.j.p.f.FailoverProvider
> Connection attempt:[1] to:
> amqps://localhost:5672?transport.keyStoreLocation=/path/to/truststore.jks=password=/path/to/keystore.jks=password=admin=password
> failed
> {noformat}
> An attacker can potentially retrieve the credentials from the logs. It would
> be desirable to mask credential details when logging connection URL.
--
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] [Closed] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed QPIDJMS-365.
Resolution: Fixed
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> ... 11 more
> 2018-03-13 11:04:54,954 [ connect thread] - DEBUG FailoverProvider
[jira] [Assigned] (QPIDJMS-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reassigned QPIDJMS-365:
Assignee: Timothy Bish
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> ... 11 more
> 2018-03-13 11:04:54,954 [ connect thread] - DEBUG
[jira] [Closed] (QPIDJMS-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish closed QPIDJMS-353.
Resolution: Won't Fix
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>Priority: Major
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
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] [Issue Comment Deleted] (QPIDJMS-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-353:
-
Comment: was deleted
(was: Please, do. )
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>Priority: Major
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
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-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387103#comment-16387103
]
Timothy Bish commented on QPIDJMS-353:
--
Please, do.
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>Priority: Major
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
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] [Resolved] (QPIDJMS-364) qpid-jms-client - May hide ClassNotFoundException when setting properties via FactoryFinder
[ https://issues.apache.org/jira/browse/QPIDJMS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-364. -- Resolution: Fixed Fix Version/s: 0.30.0 > qpid-jms-client - May hide ClassNotFoundException when setting properties via > FactoryFinder > --- > > Key: QPIDJMS-364 > URL: https://issues.apache.org/jira/browse/QPIDJMS-364 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.29.0 >Reporter: Claus Ibsen >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.30.0 > > Attachments: Screen Shot 2018-02-28 at 09.52.46.png > > > I had a problem in an Apache Camel AMQP example that would not work. It > turned out that it was a classpath issues with a missing JAR. > However the real error I got was hidden as the qpid-jms-client catches a > Throwable and ignores the exception. > See the attached screenshot, and notice the exception about > NoClassDefFoundException -- 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] [Assigned] (QPIDJMS-364) qpid-jms-client - May hide ClassNotFoundException when setting properties via FactoryFinder
[ https://issues.apache.org/jira/browse/QPIDJMS-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned QPIDJMS-364: Assignee: Timothy Bish > qpid-jms-client - May hide ClassNotFoundException when setting properties via > FactoryFinder > --- > > Key: QPIDJMS-364 > URL: https://issues.apache.org/jira/browse/QPIDJMS-364 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.29.0 >Reporter: Claus Ibsen >Assignee: Timothy Bish >Priority: Minor > Attachments: Screen Shot 2018-02-28 at 09.52.46.png > > > I had a problem in an Apache Camel AMQP example that would not work. It > turned out that it was a classpath issues with a missing JAR. > However the real error I got was hidden as the qpid-jms-client catches a > Throwable and ignores the exception. > See the attached screenshot, and notice the exception about > NoClassDefFoundException -- 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] [Resolved] (PROTON-1774) [proton-j] performance improvements in sasl transport wrapper
[ https://issues.apache.org/jira/browse/PROTON-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1774. -- Resolution: Fixed > [proton-j] performance improvements in sasl transport wrapper > - > > Key: PROTON-1774 > URL: https://issues.apache.org/jira/browse/PROTON-1774 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: proton-j-0.27.0 > > > The SaslImpl class adds a TransportWrapper that deals with processing the > iincoming and outgoing sasl exchange work. When complete the wrapper leaves > in place an implementation that must check on each new bit of work through > the transport if it is still in Sasl mode and hand off to the next wrapper > accordingly when not in Sasl. This checking can lead to a small loss in > performance. Instead a wrapper that delegates to a swappable next instance > can be switched once sasl is complete such that no checking is required after > the sasl exchange. > As a side affect of this change the input and output buffers allocated to > handle sasl bytes in the exchange can be moved to the delegate > TransportWrapper that will be dropped after the exchange and that small bit > of memory can be freed by a future GC. -- 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] (PROTON-1774) [proton-j] performance improvements in sasl transport wrapper
Timothy Bish created PROTON-1774: Summary: [proton-j] performance improvements in sasl transport wrapper Key: PROTON-1774 URL: https://issues.apache.org/jira/browse/PROTON-1774 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.27.0 The SaslImpl class adds a TransportWrapper that deals with processing the iincoming and outgoing sasl exchange work. When complete the wrapper leaves in place an implementation that must check on each new bit of work through the transport if it is still in Sasl mode and hand off to the next wrapper accordingly when not in Sasl. This checking can lead to a small loss in performance. Instead a wrapper that delegates to a swappable next instance can be switched once sasl is complete such that no checking is required after the sasl exchange. As a side affect of this change the input and output buffers allocated to handle sasl bytes in the exchange can be moved to the delegate TransportWrapper that will be dropped after the exchange and that small bit of memory can be freed by a future GC. -- 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] [Resolved] (PROTON-1767) [proton-j] Allow the Transport to expose an output buffer that is not read-only
[ https://issues.apache.org/jira/browse/PROTON-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1767. -- Resolution: Fixed Fixed by: https://github.com/apache/qpid-proton-j/commit/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c > [proton-j] Allow the Transport to expose an output buffer that is not > read-only > --- > > Key: PROTON-1767 > URL: https://issues.apache.org/jira/browse/PROTON-1767 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.25.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: proton-j-0.26.0 > > > In some cases the read-only output buffer exposed by TransportImpl by calling > head() or getOutputBuffer() can lead to extra intermediate copies of the > buffer based on the IO framework being used to transmit the bytes (such as > current Netty releases). This is due to the fact that the read-only buffer > reports that it doesn't have a backing array so the frameworks try to work > around this to optimize the transfer of bytes. For uses who are aware of > this and can ensure they never tamper with the buffer contents that aren't > consumed we should let them choose to expose a writable duplicate of the > output buffer. -- 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] (PROTON-1767) [proton-j] Allow the Transport to expose an output buffer that is not read-only
Timothy Bish created PROTON-1767: Summary: [proton-j] Allow the Transport to expose an output buffer that is not read-only Key: PROTON-1767 URL: https://issues.apache.org/jira/browse/PROTON-1767 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.25.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.26.0 In some cases the read-only output buffer exposed by TransportImpl by calling head() or getOutputBuffer() can lead to extra intermediate copies of the buffer based on the IO framework being used to transmit the bytes (such as current Netty releases). This is due to the fact that the read-only buffer reports that it doesn't have a backing array so the frameworks try to work around this to optimize the transfer of bytes. For uses who are aware of this and can ensure they never tamper with the buffer contents that aren't consumed we should let them choose to expose a writable duplicate of the output buffer. -- 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] [Resolved] (PROTON-1756) [Proton-J] Runnable created on every Transfer frame send
[ https://issues.apache.org/jira/browse/PROTON-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1756. -- Resolution: Fixed > [Proton-J] Runnable created on every Transfer frame send > > > Key: PROTON-1756 > URL: https://issues.apache.org/jira/browse/PROTON-1756 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.25.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: proton-j-0.26.0 > > > On each outbound Transfer frame the TransportImpl creates a new Runnable to > handle overflow which sets the more value on the Transfer and rewrites the > frame body. We can use a single instance to handle this and reduce the > amount of garbage create on send. -- 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] (PROTON-1756) [Proton-J] Runnable created on every Transfer frame send
Timothy Bish created PROTON-1756: Summary: [Proton-J] Runnable created on every Transfer frame send Key: PROTON-1756 URL: https://issues.apache.org/jira/browse/PROTON-1756 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.25.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.26.0 On each outbound Transfer frame the TransportImpl creates a new Runnable to handle overflow which sets the more value on the Transfer and rewrites the frame body. We can use a single instance to handle this and reduce the amount of garbage create on send. -- 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-358) Duplicate Messages delivered over AMQPS connectivity using QPID Jars
[ https://issues.apache.org/jira/browse/QPIDJMS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332429#comment-16332429 ] Timothy Bish commented on QPIDJMS-358: -- Given that you've not yet identified what's changed or what might be happening this really isn't the place to be asking for support, this would be better suited for the users mailing list. That said you should start by testing what is going on with logging enabled and also frame tracing on to see what is happening at the wire level. Documentation for the version you are using can be found here which describes how to turn on the tracing: [http://qpid.apache.org/releases/qpid-jms-0.11.1/docs/index.html] Since the client has been working for quite some time and this suddenly started to happen I'd be looking further up the chain to see what's changed as that is more likely to be the culprit. If a bug is found though any fix would be made only in the latest release of the client so you'd be well served to update to the latest and begin testing on that version. > Duplicate Messages delivered over AMQPS connectivity using QPID Jars > > > Key: QPIDJMS-358 > URL: https://issues.apache.org/jira/browse/QPIDJMS-358 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Pooja Arora >Priority: Critical > > Hello Team, > We are using Apache QPID jars for AMQP (JMS V1) to Azure Service Bus from > IBM Integration Bus(IIB V9.0). > We use below jars :- > # qpid-jms-client-0.11.1.jar > # proton-j-0.14.0.jar > # qpid-jms-discovery-0.11.1.jar > # slf4j-api-1.7.21.jar > # geronimo-jms_1.1_spec-1.1.1.jar > Below is our connection URL : > connectionfactory.qpidConnectionFactory = > amqps://:?amqp.idleTimeout=15===true=1 > We connect to predefined subscriptions on an Azure Service Bus Topic. > We have been using these jars for nearly a year now. Recently from past 2 > weeks we are seeing some of the messages are delivered as duplicates with > same JMS Message ID. Sometime same message is delivered 30-40 times within a > second. > Also we use same connection URL to different subscriptions (PROD and UAT) to > same topic from our UAT and PROD servers. So we receive same payload in both > the environments. And we have noticed that these duplicate counts vary from > UAT to PROD. > > So looks like it can be some issue in the connection which is causing the > duplicates. As we have had the upstream teams check complete data flow logic > and we could not find any other place of duplicates. > > Please suggest how we can debug this issue to find its RCA and related fix. -- 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] [Closed] (QPIDJMS-358) Duplicate Messages delivered over AMQPS connectivity using QPID Jars
[ https://issues.apache.org/jira/browse/QPIDJMS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-358. Resolution: Invalid > Duplicate Messages delivered over AMQPS connectivity using QPID Jars > > > Key: QPIDJMS-358 > URL: https://issues.apache.org/jira/browse/QPIDJMS-358 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Pooja Arora >Priority: Critical > > Hello Team, > We are using Apache QPID jars for AMQP (JMS V1) to Azure Service Bus from > IBM Integration Bus(IIB V9.0). > We use below jars :- > # qpid-jms-client-0.11.1.jar > # proton-j-0.14.0.jar > # qpid-jms-discovery-0.11.1.jar > # slf4j-api-1.7.21.jar > # geronimo-jms_1.1_spec-1.1.1.jar > Below is our connection URL : > connectionfactory.qpidConnectionFactory = > amqps://:?amqp.idleTimeout=15===true=1 > We connect to predefined subscriptions on an Azure Service Bus Topic. > We have been using these jars for nearly a year now. Recently from past 2 > weeks we are seeing some of the messages are delivered as duplicates with > same JMS Message ID. Sometime same message is delivered 30-40 times within a > second. > Also we use same connection URL to different subscriptions (PROD and UAT) to > same topic from our UAT and PROD servers. So we receive same payload in both > the environments. And we have noticed that these duplicate counts vary from > UAT to PROD. > > So looks like it can be some issue in the connection which is causing the > duplicates. As we have had the upstream teams check complete data flow logic > and we could not find any other place of duplicates. > > Please suggest how we can debug this issue to find its RCA and related fix. -- 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] [Resolved] (QPIDJMS-355) Use the new Proton-J SaslListener API to simplify the sasl code
[ https://issues.apache.org/jira/browse/QPIDJMS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-355. -- Resolution: Fixed > Use the new Proton-J SaslListener API to simplify the sasl code > --- > > Key: QPIDJMS-355 > URL: https://issues.apache.org/jira/browse/QPIDJMS-355 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.28.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.29.0 > > > Latest proton-j release provide a SASL event callback that can be used to > simplify the current implementation that must check sasl state on each > inbound read. -- 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-356) Add support for a new session mode to make all consumers presettled
Timothy Bish created QPIDJMS-356: Summary: Add support for a new session mode to make all consumers presettled Key: QPIDJMS-356 URL: https://issues.apache.org/jira/browse/QPIDJMS-356 Project: Qpid JMS Issue Type: New Feature Components: qpid-jms-client Affects Versions: 0.28.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.29.0 Adds support for creating session with a presettled, or no-acknowledge mode where all consumers created from the session operate as presettled receivers. The integer session acknowledgement mode values supported are 100 and 257. -- 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-355) Use the new Proton-J SaslListener API to simplify the sasl code
Timothy Bish created QPIDJMS-355: Summary: Use the new Proton-J SaslListener API to simplify the sasl code Key: QPIDJMS-355 URL: https://issues.apache.org/jira/browse/QPIDJMS-355 Project: Qpid JMS Issue Type: Improvement Affects Versions: 0.28.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.29.0 Latest proton-j release provide a SASL event callback that can be used to simplify the current implementation that must check sasl state on each inbound read. -- 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-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322554#comment-16322554
]
Timothy Bish commented on QPIDJMS-353:
--
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22].
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-353) Add pooled connection factory
[
https://issues.apache.org/jira/browse/QPIDJMS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16322554#comment-16322554
]
Timothy Bish edited comment on QPIDJMS-353 at 1/11/18 4:58 PM:
---
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22]. This
project has tests that use the Qpid JMS client library which you can use as a
reference for configuring it.
was (Author: tabish121):
There aren't any plans to implement a Qpid JMS specific pooled connection
factory. There are already a few generic options that should work so there
isn't really a need to invent a new one.
One option is to use the PooledConnectionFactory provided by ActiveMQ which is
a JMS 1.1 based Connection pooling utility. It is tested with Camel already as
it is used to pool the ActiveMQ Connections. You can find the docs
[here|https://activemq.apache.org/maven/apidocs/org/apache/activemq/jms/pool/PooledConnectionFactory.html],
and the maven artifacts are
[here|https://mvnrepository.com/artifact/org.apache.activemq/activemq-pool/5.15.2].
Another option is [this|https://github.com/messaginghub/pooled-jms] JMS 2.0
aware Connection pool which you can use via the maven artifacts
[here|https://search.maven.org/#search%7Cga%7C1%7Ca%3A%22pooled-jms%22].
> Add pooled connection factory
> -
>
> Key: QPIDJMS-353
> URL: https://issues.apache.org/jira/browse/QPIDJMS-353
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Affects Versions: 0.28.0
>Reporter: Nicola Ferraro
>
> A pooled connection factory was present in the amqp 0.x version of the
> library, but is missing in the current one.
> I've done some tests with Apache Camel (camel-amqp) and every message sent to
> a queue results into a new connection.
> A (always increasing) progressive number and a message about Sasl
> authentication is printed for every message. I suspect this is a waste of
> performance.
> Do you plan to add this feature?
> Relevant parts of the stack trace:
> {code}
> 10:13:03.161 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.201 [AmqpProvider :(3):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:94d6f8bf-886f-46b2-8eff-af09f03dd46c:1 connected to remote Broker:
> amqp://localhost:5672
> 10:13:03.240 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:03.255 [AmqpProvider :(4):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:946b64b6-dbc3-4ce7-b178-55de6759c26b:2 connected to remote Broker:
> amqp://localhost:5672
> 10:13:06.143 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> o.a.q.jms.sasl.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 10:13:06.181 [AmqpProvider :(5):[amqp://localhost:5672]] INFO
> org.apache.qpid.jms.JmsConnection - Connection
> ID:89593ca0-a185-4e51-80ef-bb6bf3dfbbbd:3 connected to remote Broker:
> amqp://localhost:5672
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-352) Update Netty to latest 4.1.19.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-352. -- Resolution: Fixed > Update Netty to latest 4.1.19.Final > --- > > Key: QPIDJMS-352 > URL: https://issues.apache.org/jira/browse/QPIDJMS-352 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.28.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.29.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-352) Update Netty to latest 4.1.19.Final
Timothy Bish created QPIDJMS-352: Summary: Update Netty to latest 4.1.19.Final Key: QPIDJMS-352 URL: https://issues.apache.org/jira/browse/QPIDJMS-352 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.28.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.29.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1723) [proton-c] Building with sasl2-bin not installed results in test failure
Timothy Bish created PROTON-1723:
Summary: [proton-c] Building with sasl2-bin not installed results
in test failure
Key: PROTON-1723
URL: https://issues.apache.org/jira/browse/PROTON-1723
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Environment: Linux Mint 18.2
Reporter: Timothy Bish
Priority: Trivial
Building the latest upstream code and running the tests results in a failed
test "ruby-test-container" on my Ubuntu based machine. The INSTALL.md omits
the need to install "sasl2-bin" which leads to the test failure. The install
guide needs an update but also the test might be made to check for that an
maybe offer a better diagnostic or just not run on platforms that are missing
the required dependencies for that test.
{noformat}
timothy@OfficePC ~/temp/0.20.0/qpid-proton-0.19.0/build $ ctest -V -R
ruby-test-container
UpdateCTestConfiguration from
:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Parse Config
file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
UpdateCTestConfiguration from
:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Parse Config
file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
Test project /home/timothy/temp/0.20.0/qpid-proton-0.19.0/build
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 18
Start 18: ruby-test-container
18: Test command: /usr/bin/python
"/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/env.py" "--"
"PATH=/home/timothy/.local/bin:/home/timothy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
"RUBYLIB=:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/lib:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/spec:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
"SASLPASSWD=SASLPASSWD_EXE-NOTFOUND" "RUBYOPT=-W0" "/usr/bin/ruby"
"/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb"
"-v"
18: Test timeout computed to be: 1500
18: sh: 1: SASLPASSWD_EXE-NOTFOUND: not found
18:
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:282:in
`make_user': undefined local variable or method `makepw_cmd' for
# (NameError)
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:261:in
`initialize'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
`new'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
`'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:249:in
`'
18: from
/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:221:in
`'
1/1 Test #18: ruby-test-container ..***Failed0.08 sec
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-351) Update Mockito to latest 2.13.0
[ https://issues.apache.org/jira/browse/QPIDJMS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-351. -- Resolution: Fixed > Update Mockito to latest 2.13.0 > --- > > Key: QPIDJMS-351 > URL: https://issues.apache.org/jira/browse/QPIDJMS-351 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-351) Update Mockito to latest 2.13.0
Timothy Bish created QPIDJMS-351: Summary: Update Mockito to latest 2.13.0 Key: QPIDJMS-351 URL: https://issues.apache.org/jira/browse/QPIDJMS-351 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.27.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Trivial Fix For: 0.28.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-347) Update Netty to latest 4.1.18.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-347. -- Resolution: Fixed > Update Netty to latest 4.1.18.Final > --- > > Key: QPIDJMS-347 > URL: https://issues.apache.org/jira/browse/QPIDJMS-347 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > > Update to Netty 4.1.18.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-347) Update Netty to latest 4.1.18.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-347: - Description: Update to Netty 4.1.18.Final to pick up latest fixes (was: Update to Netty 4.1.17.Final to pick up latest fixes) > Update Netty to latest 4.1.18.Final > --- > > Key: QPIDJMS-347 > URL: https://issues.apache.org/jira/browse/QPIDJMS-347 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > > Update to Netty 4.1.18.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPIDJMS-347) Update Netty to latest 4.1.17.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reopened QPIDJMS-347: -- Updating to 4.1.18.Final prior to next release. > Update Netty to latest 4.1.17.Final > --- > > Key: QPIDJMS-347 > URL: https://issues.apache.org/jira/browse/QPIDJMS-347 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > > Update to Netty 4.1.17.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-347) Update Netty to latest 4.1.18.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-347: - Summary: Update Netty to latest 4.1.18.Final (was: Update Netty to latest 4.1.17.Final) > Update Netty to latest 4.1.18.Final > --- > > Key: QPIDJMS-347 > URL: https://issues.apache.org/jira/browse/QPIDJMS-347 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > > Update to Netty 4.1.17.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1708) [proton-j] Improve performance of proton-j codec
Timothy Bish created PROTON-1708: Summary: [proton-j] Improve performance of proton-j codec Key: PROTON-1708 URL: https://issues.apache.org/jira/browse/PROTON-1708 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.23.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.24.0 Several areas in the proton-j codec can be improved to provide overall improvements in both the encode and decode of AMQP types as well as reduce GC overhead with reduction in allocations of intermediate and helper objects. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-348) Be able to configure delay between retries in JmsRedeliveryPolicy
[ https://issues.apache.org/jira/browse/QPIDJMS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-348. Resolution: Not A Problem > Be able to configure delay between retries in JmsRedeliveryPolicy > - > > Key: QPIDJMS-348 > URL: https://issues.apache.org/jira/browse/QPIDJMS-348 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Riv > > I am wondering if it would possible to get a redelivery delay between > redelivery attempts. Similar to initialRedeliveryDelay in the redelivery > policy in the ActiveMQ client: > http://activemq.apache.org/message-redelivery-and-dlq-handling.html. > I've found that in practice the redeliveries all happen immediately before > the system may be ready to handle it properly (a few seconds later). > Thanks :) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-348) Be able to configure delay between retries in JmsRedeliveryPolicy
[ https://issues.apache.org/jira/browse/QPIDJMS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16261317#comment-16261317 ] Timothy Bish commented on QPIDJMS-348: -- Redelivery for the AMQP JMS client is actually done on the broker side, the client does not control how fast the broker will redispatch those messages, in the case of ActiveMQ I think you would be able to control the rate via the broker redelivery plugin. > Be able to configure delay between retries in JmsRedeliveryPolicy > - > > Key: QPIDJMS-348 > URL: https://issues.apache.org/jira/browse/QPIDJMS-348 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Riv > > I am wondering if it would possible to get a redelivery delay between > redelivery attempts. Similar to initialRedeliveryDelay in the redelivery > policy in the ActiveMQ client: > http://activemq.apache.org/message-redelivery-and-dlq-handling.html. > I've found that in practice the redeliveries all happen immediately before > the system may be ready to handle it properly (a few seconds later). > Thanks :) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-347) Update Netty to latest 4.1.17.Final
[ https://issues.apache.org/jira/browse/QPIDJMS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-347. -- Resolution: Fixed > Update Netty to latest 4.1.17.Final > --- > > Key: QPIDJMS-347 > URL: https://issues.apache.org/jira/browse/QPIDJMS-347 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.27.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.28.0 > > > Update to Netty 4.1.17.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-347) Update Netty to latest 4.1.17.Final
Timothy Bish created QPIDJMS-347: Summary: Update Netty to latest 4.1.17.Final Key: QPIDJMS-347 URL: https://issues.apache.org/jira/browse/QPIDJMS-347 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.27.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Trivial Fix For: 0.28.0 Update to Netty 4.1.17.Final to pick up latest fixes -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-344) FailoverWithAmqpOpenProvidedServerListIntegrationTest sporadic test failures in CI
[ https://issues.apache.org/jira/browse/QPIDJMS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-344. -- Resolution: Fixed > FailoverWithAmqpOpenProvidedServerListIntegrationTest sporadic test failures > in CI > -- > > Key: QPIDJMS-344 > URL: https://issues.apache.org/jira/browse/QPIDJMS-344 > Project: Qpid JMS > Issue Type: Improvement >Affects Versions: 0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.27.0 > > > During CI testing the failover integration tests that are checking that > updated failover URIs provided from remote peers are handled correctly have > been sporadically failing. This is due to the way the updates are handled > from the remote leading to an event that can fire in an unexpected ordering > relative to the connection established / connection recovered events. > Because of the mixed ordering of events the integration tests can check the > updated URIs at the wrong time and not see the URI updates they are > expecting. > Refactoring the handling of the updated failover URs should be done to make > the ordering of how these are all handled consistent. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-344) FailoverWithAmqpOpenProvidedServerListIntegrationTest sporadic test failures in CI
Timothy Bish created QPIDJMS-344: Summary: FailoverWithAmqpOpenProvidedServerListIntegrationTest sporadic test failures in CI Key: QPIDJMS-344 URL: https://issues.apache.org/jira/browse/QPIDJMS-344 Project: Qpid JMS Issue Type: Improvement Affects Versions: 0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.27.0 During CI testing the failover integration tests that are checking that updated failover URIs provided from remote peers are handled correctly have been sporadically failing. This is due to the way the updates are handled from the remote leading to an event that can fire in an unexpected ordering relative to the connection established / connection recovered events. Because of the mixed ordering of events the integration tests can check the updated URIs at the wrong time and not see the URI updates they are expecting. Refactoring the handling of the updated failover URs should be done to make the ordering of how these are all handled consistent. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-343) Update testing dependencies (ActiveMQ and Mockito)
[ https://issues.apache.org/jira/browse/QPIDJMS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-343. -- Resolution: Fixed > Update testing dependencies (ActiveMQ and Mockito) > -- > > Key: QPIDJMS-343 > URL: https://issues.apache.org/jira/browse/QPIDJMS-343 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.27.0 > > > Update the ActiveMQ and Mockito testing dependencies to latest releases > (5.15.2 and 2.11.0) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-343) Update testing dependencies (ActiveMQ and Mockito)
Timothy Bish created QPIDJMS-343: Summary: Update testing dependencies (ActiveMQ and Mockito) Key: QPIDJMS-343 URL: https://issues.apache.org/jira/browse/QPIDJMS-343 Project: Qpid JMS Issue Type: Task Components: qpid-jms-client Affects Versions: 0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.27.0 Update the ActiveMQ and Mockito testing dependencies to latest releases (5.15.2 and 2.11.0) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-342) Missed connect error on start can lead to hung failover reconnect cycle
[ https://issues.apache.org/jira/browse/QPIDJMS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-342. -- Resolution: Fixed > Missed connect error on start can lead to hung failover reconnect cycle > --- > > Key: QPIDJMS-342 > URL: https://issues.apache.org/jira/browse/QPIDJMS-342 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.27.0 > > > In some cases where the jms.connectTimeout is tripped during socket level > connection and the failover transport bits are in use the client an fall into > a reconnect loop or stall waiting for an error callback that won't be > triggered. > One workaround exists which is to configure the transport level socket > connect timeout to be lower than the jms.connectionTimeout value -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-342) Missed connect error on start can lead to hung failover reconnect cycle
Timothy Bish created QPIDJMS-342: Summary: Missed connect error on start can lead to hung failover reconnect cycle Key: QPIDJMS-342 URL: https://issues.apache.org/jira/browse/QPIDJMS-342 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.27.0 In some cases where the jms.connectTimeout is tripped during socket level connection and the failover transport bits are in use the client an fall into a reconnect loop or stall waiting for an error callback that won't be triggered. One workaround exists which is to configure the transport level socket connect timeout to be lower than the jms.connectionTimeout value -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-336) Refine failover reconnect behavior
[ https://issues.apache.org/jira/browse/QPIDJMS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-336. -- Resolution: Fixed > Refine failover reconnect behavior > -- > > Key: QPIDJMS-336 > URL: https://issues.apache.org/jira/browse/QPIDJMS-336 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.26.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.27.0 > > > The current failover behavior attempt to connect to one URI from the possible > list of failover URIs when attempting to reestablish the connect before it > applies the configured reconnect delay. Instead it should attempt the full > batch before performing delay and backoff handling. > Also the reconnect attempts are counted per URI instead of once for each > cycle though the batch of available URIs meaning that if the value is to low > it might not be able to try all of the configured URIs before reaching the > max attempts. Track the attempts for the complete batch instead to allow all > to be tried at least once before giving up. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-340) Build fails with group id is too big error
[
https://issues.apache.org/jira/browse/QPIDJMS-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-340:
-
Fix Version/s: 0.27.0
> Build fails with group id is too big error
> --
>
> Key: QPIDJMS-340
> URL: https://issues.apache.org/jira/browse/QPIDJMS-340
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.26.0
>Reporter: Christopher L. Shannon
>Priority: Minor
> Fix For: 0.27.0
>
>
> In my environment when I'm trying to build from source the maven-assembly
> plugin fails because my group id is apparently too big. The solution for
> this is to configure the maven-assembly-plugin with
> {{posix}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-339) Allow setting keystore and truststore type from system properties
[ https://issues.apache.org/jira/browse/QPIDJMS-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-339. -- Resolution: Fixed > Allow setting keystore and truststore type from system properties > - > > Key: QPIDJMS-339 > URL: https://issues.apache.org/jira/browse/QPIDJMS-339 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.27.0 > > > Read store type for key store and trust store from the java properties > *javax.net.ssl.keyStoreType* and *javax.net.ssl.trustStoreType* defaulting to > *JKS* -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-339) Allow setting keystore and truststore type from system properties
Timothy Bish created QPIDJMS-339: Summary: Allow setting keystore and truststore type from system properties Key: QPIDJMS-339 URL: https://issues.apache.org/jira/browse/QPIDJMS-339 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Reporter: Timothy Bish Assignee: Timothy Bish Priority: Trivial Fix For: 0.27.0 Read store type for key store and trust store from the java properties *javax.net.ssl.keyStoreType* and *javax.net.ssl.trustStoreType* defaulting to *JKS* -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-338) SSL configuration should support setting keyStoreType and trustStoreType independently
[
https://issues.apache.org/jira/browse/QPIDJMS-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved QPIDJMS-338.
--
Resolution: Fixed
Assignee: Timothy Bish
Fix Version/s: 0.27.0
> SSL configuration should support setting keyStoreType and trustStoreType
> independently
> --
>
> Key: QPIDJMS-338
> URL: https://issues.apache.org/jira/browse/QPIDJMS-338
> Project: Qpid JMS
> Issue Type: Improvement
> Components: qpid-jms-client
>Reporter: Christopher L. Shannon
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 0.27.0
>
>
> Currently there is only one configuration option to set the keystore type
> when configuration SSL and that option is {{transport.storeType}}. However
> sometimes it is useful to be able to set both the keyStoreType and
> trustStoreType to different formats. An example might be if the keyStore
> format is pkcs11 (a hardware token) and the trust store is still jks or pkcs12
> I'm proposing adding two new configuration options called
> {{transport.keyStoreType}} and {{transport.trustStoreType}} that can be set.
> The existing option will still be there and if used will just set the both
> types to the same thing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-336) Refine failover reconnect behavior
Timothy Bish created QPIDJMS-336: Summary: Refine failover reconnect behavior Key: QPIDJMS-336 URL: https://issues.apache.org/jira/browse/QPIDJMS-336 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.26.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.27.0 The current failover behavior attempt to connect to one URI from the possible list of failover URIs when attempting to reestablish the connect before it applies the configured reconnect delay. Instead it should attempt the full batch before performing delay and backoff handling. Also the reconnect attempts are counted per URI instead of once for each cycle though the batch of available URIs meaning that if the value is to low it might not be able to try all of the configured URIs before reaching the max attempts. Track the attempts for the complete batch instead to allow all to be tried at least once before giving up. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-261) Not possible to connect to IBM's IIB AMQP broker
[
https://issues.apache.org/jira/browse/QPIDJMS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16185268#comment-16185268
]
Timothy Bish commented on QPIDJMS-261:
--
The issue you are describing sounds as though it is QPIDJMS-282 which was fixed
in v0.22.0 so my first suggestion would be to move to the latest release so
that you have all the current fixes when you are doing your testing.
> Not possible to connect to IBM's IIB AMQP broker
>
>
> Key: QPIDJMS-261
> URL: https://issues.apache.org/jira/browse/QPIDJMS-261
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.20.0
> Environment: Java 1.8
>Reporter: Tin Nguyen
> Attachments: qpid.0.11.1.log, qpid.0.11.1.pcapng, qpid.0.20.0.log,
> qpid.0.20.0.pcapng
>
>
> With the latest 0.20 version I'm not able to connect to IBM's Integration Bus
> running AMQP implementation (afaik it's just a rip off from qpid).
> Seems like something changed with the way qpid-jms handles SASL
> authentication? It's working in 0.11.1 so I tried to look into the changes
> but there were quite a few.
> I don't have access to the IBM server but the admin told me that my client
> didn't get authenticated.
> log output from the qpid client:
> 2348 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO
> o.a.q.j.s.SaslMechanismFinder - Best match for SASL auth was: SASL-PLAIN
> 8120 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] WARN
> o.a.q.j.p.a.b.AmqpResourceBuilder - Open of resource:(JmsConnectionInfo {
> ID:9088d3b3-0cba-4fb4-bb87-207872077309:1, configuredURI =
> amqp://SERVER:5672/TOPIC, connectedURI = null }) failed: AMQXR0041E: A
> connection was not authorized for channel SYSTEM.DEF.AMQP received from
> 10.2.190.60. MQRC 2035 MQRC_NOT_AUTHORIZED [condition =
> amqp:unauthorized-access]
> 8121 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO
> o.a.q.j.p.a.AmqpProvider - Transport failed: An existing connection was
> forcibly closed by the remote host
> Caught exception, exiting.
> javax.jms.JMSSecurityException: AMQXR0041E: A connection was not authorized
> for channel SYSTEM.DEF.AMQP received from 10.2.10.60. MQRC 2035
> MQRC_NOT_AUTHORIZED [condition = amqp:unauthorized-access]
> LOGS on IBM server
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
> Host(SERVER) Installation(Installation1)
> VRMF(9.0.0.0) QMgr(UUFNLB1E)
>
> AMQ5534: User ID 'hadoop' authentication failed
> EXPLANATION:
> The user ID and password supplied by the 'AMQP' program could not be
> authenticated.
> Additional information: 'N/A'.
> ACTION:
> Ensure that the correct user ID and password are provided by the application.
> Ensure that the authentication repository is correctly configured. Look at
> previous error messages for any additional information.
> - amqzfuca.c : 4486
> ---
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
> Host(SERVER) Installation(Installation1)
> VRMF(9.0.0.0) QMgr(UUFNLB1E)
>
> AMQ5542: The failed authentication check was caused by the queue manager
> CONNAUTH CHCKCLNT(REQDADM) configuration.
> EXPLANATION:
> The user ID 'hadoop' and its password were checked because the queue manager
> connection authority (CONNAUTH) configuration refers to an authentication
> information (AUTHINFO) object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with
> CHCKCLNT(REQDADM).
> This message accompanies a previous error to clarify the reason for the user
> ID
> and password check.
> ACTION:
> Refer to the previous error for more information.
> Ensure that a password is specified by the client application and that the
> password is correct for the user ID. The authentication configuration of the
> queue manager connection determines the user ID repository. For example, the
> local operating system user database or an LDAP server.
> If the CHCKCLNT setting is OPTIONAL, the authentication check can be avoided
> by
> not passing a user ID across the channel. For example, by omitting the MQCSP
> structure from the client MQCONNX API call.
> To avoid the authentication check, you can amend the authentication
> configuration of the queue manager connection, but you should generally not
> allow unauthenticated remote access.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
