[jira] [Commented] (PROTON-1869) [Python] Compiler conversion warnings with Win64 builds
[ https://issues.apache.org/jira/browse/PROTON-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523229#comment-16523229 ] ASF subversion and git services commented on PROTON-1869: - Commit 7c0a3387a5096d86541dbddfeb55f36eb0b85dd8 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7c0a338 ] PROTON-1869: Fix some SWIG Python Win64 type/pointer conversion problems > [Python] Compiler conversion warnings with Win64 builds > --- > > Key: PROTON-1869 > URL: https://issues.apache.org/jira/browse/PROTON-1869 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.24.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] [Commented] (PROTON-1868) [Python] pn_handle_t binding does not reliably work with Win64
[ https://issues.apache.org/jira/browse/PROTON-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523228#comment-16523228 ] ASF subversion and git services commented on PROTON-1868: - Commit 798894f63dba6a0d4eaa6e015d6f5ac64274be2f in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=798894f ] PROTON-1868: Fix pn_handle_t python binding on Visual Studio 64 bit compiles > [Python] pn_handle_t binding does not reliably work with Win64 > -- > > Key: PROTON-1868 > URL: https://issues.apache.org/jira/browse/PROTON-1868 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding, ruby-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.24.0 > > > pn_handle_t is treated by swig as identical to uintptr_t which is defined as > unsigned long. However under Win64 this is a 32 bit int which is not long > enough to fit all 64 bit addresses. > The swig code should be changed to either define uintptr_t as unsigned long > long for 64 bit builds which is always 64 bits (on all platforms). > Or we should use a custom typemap for pn_handle_t which uses PyLong_AsVoidPtr > & PyLong_FromVoidPtr. -- 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-1868) [Python] pn_handle_t binding does not reliably work with Win64
[ https://issues.apache.org/jira/browse/PROTON-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-1868: Component/s: ruby-binding python-binding > [Python] pn_handle_t binding does not reliably work with Win64 > -- > > Key: PROTON-1868 > URL: https://issues.apache.org/jira/browse/PROTON-1868 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding, ruby-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.24.0 > > > pn_handle_t is treated by swig as identical to uintptr_t which is defined as > unsigned long. However under Win64 this is a 32 bit int which is not long > enough to fit all 64 bit addresses. > The swig code should be changed to either define uintptr_t as unsigned long > long for 64 bit builds which is always 64 bits (on all platforms). > Or we should use a custom typemap for pn_handle_t which uses PyLong_AsVoidPtr > & PyLong_FromVoidPtr. -- 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-1869) [Python] Compiler conversion warnings with Win64 builds
Andrew Stitcher created PROTON-1869: --- Summary: [Python] Compiler conversion warnings with Win64 builds Key: PROTON-1869 URL: https://issues.apache.org/jira/browse/PROTON-1869 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.24.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] [Created] (PROTON-1868) [Python] pn_handle_t binding does not reliably work with Win64
Andrew Stitcher created PROTON-1868: --- Summary: [Python] pn_handle_t binding does not reliably work with Win64 Key: PROTON-1868 URL: https://issues.apache.org/jira/browse/PROTON-1868 Project: Qpid Proton Issue Type: Bug Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.24.0 pn_handle_t is treated by swig as identical to uintptr_t which is defined as unsigned long. However under Win64 this is a 32 bit int which is not long enough to fit all 64 bit addresses. The swig code should be changed to either define uintptr_t as unsigned long long for 64 bit builds which is always 64 bits (on all platforms). Or we should use a custom typemap for pn_handle_t which uses PyLong_AsVoidPtr & PyLong_FromVoidPtr. -- 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
[GitHub] qpid-dispatch pull request #332: Dispatch 1049 console tests
Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/332 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #332: Dispatch 1049 console tests
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/332 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=h1) Report > Merging [#332](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/af997544e1c7954f5ff0bdb3b17bdc69c21557d9?src=pr=desc) will **increase** coverage by `0.03%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=tree) ```diff @@Coverage Diff @@ ## master #332 +/- ## == + Coverage 86.56% 86.59% +0.03% == Files 69 69 Lines 1547915479 == + Hits1339913404 +5 + Misses 2080 2075 -5 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=tree) | Coverage Π| | |---|---|---| | [src/parse.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3BhcnNlLmM=) | `85.83% <0%> (-0.28%)` | :arrow_down: | | [src/router\_core/connections.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2Nvbm5lY3Rpb25zLmM=) | `95.24% <0%> (+0.11%)` | :arrow_up: | | [src/router\_node.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9ub2RlLmM=) | `94.72% <0%> (+0.14%)` | :arrow_up: | | [src/remote\_sasl.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3JlbW90ZV9zYXNsLmM=) | `83.28% <0%> (+0.29%)` | :arrow_up: | | [src/router\_core/transfer.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL3RyYW5zZmVyLmM=) | `90.95% <0%> (+0.31%)` | :arrow_up: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/332/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.79% <0%> (+0.57%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Π= absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=footer). Last update [af99754...0c51c78](https://codecov.io/gh/apache/qpid-dispatch/pull/332?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #332: Dispatch 1049 console tests
GitHub user ErnieAllen opened a pull request: https://github.com/apache/qpid-dispatch/pull/332 Dispatch 1049 console tests Console unit tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/ErnieAllen/qpid-dispatch DISPATCH-1049-console-tests Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/332.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #332 commit 0d4d233a9f9c8d7bbc451f6d50213fb99a35e688 Author: Ernest Allen Date: 2018-06-25T12:56:46Z DISPATCH-1049 Add console tests commit 0c51c78f2e33978e28a99b6fda391e0dc7c0de1d Author: Ernest Allen Date: 2018-06-25T13:12:39Z DISPATCH-1049 Added license headers --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #331: Test new CMakeLists.txt
Github user ErnieAllen closed the pull request at: https://github.com/apache/qpid-dispatch/pull/331 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #331: Test new CMakeLists.txt
GitHub user ErnieAllen opened a pull request: https://github.com/apache/qpid-dispatch/pull/331 Test new CMakeLists.txt Testing if npm exists before npx. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ErnieAllen/qpid-dispatch ernie-console-build Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/331.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #331 commit 4764c92959e934829f3fafcd8ce9c5f1934e5cc3 Author: Ernest Allen Date: 2018-06-25T20:40:28Z Test new CMakeLists.txt --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1866) cannot tell whether peer specified expiry-policy on terminus
[
https://issues.apache.org/jira/browse/PROTON-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522761#comment-16522761
]
Robbie Gemmell commented on PROTON-1866:
Change committed in:
http://git-wip-us.apache.org/repos/asf/qpid-proton/commit/ccb9e5a3
{noformat}
PROTON-1866: provide method to determine whether expiry policy was set
explicitly or not
Commit: ccb9e5a388022e529502dcc547b7862b2185d6bc
Committer: Gordon Sim
Committed: Mon Jun 25 17:52:40 2018 +0100
{noformat}
> cannot tell whether peer specified expiry-policy on terminus
>
>
> Key: PROTON-1866
> URL: https://issues.apache.org/jira/browse/PROTON-1866
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.23.0
>Reporter: Gordon Sim
>Assignee: Gordon Sim
>Priority: Major
> Fix For: proton-c-0.24.0
>
>
> This prevents anything using proton-c to behave differently if an explicit
> policy is set.
--
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-395) remote connection closure can lead to send exception even though failover is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-395:
---
Summary: remote connection closure can lead to send exception even though
failover is enabled (was: remote connection:forced can lead to send exception
even though failover is enabled)
> remote connection closure can lead to send exception even though failover 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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] [Updated] (QPIDJMS-395) remote connection:forced can lead to send exception even though failover is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-395:
---
Summary: remote connection:forced can lead to send exception even though
failover is enabled (was: connection:forced leads to JMSException even though
reconnect is enabled)
> remote connection:forced can lead to send exception even though failover 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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] [Updated] (QPIDJMS-393) async send CompletionListener not signalled when sent while TX is in doubt
[ https://issues.apache.org/jira/browse/QPIDJMS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-393: --- Summary: async send CompletionListener not signalled when sent while TX is in doubt (was: Async Completion sends not signaled when sent while TX is in doubt) > async send CompletionListener not signalled 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] [Updated] (QPIDJMS-394) CompletionListener can be signalled 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 ] Robbie Gemmell updated QPIDJMS-394: --- Summary: CompletionListener can be signalled in error when send blocked waiting for failover (was: Completion Listener singaled in error when send blocked waiting for failover) > CompletionListener can be signalled 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] [Resolved] (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:all-tabpanel
]
Timothy Bish resolved QPIDJMS-395.
--
Resolution: Fixed
Fix such that resends are attempted on connection remote close, and more
specific exception is thrown when not using failover to aid in debug.
> 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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,
[jira] [Updated] (QPIDJMS-396) Performance improvements for inter-thread event signalling
[ https://issues.apache.org/jira/browse/QPIDJMS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-396: --- Description: 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. Credit [~nigro@gmail.com] on initial code and idea. was: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. > 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 >Priority: Major > 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. > Credit [~nigro@gmail.com] on initial code and idea. -- 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-396) Performance improvements for inter-thread event signalling
[
https://issues.apache.org/jira/browse/QPIDJMS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522654#comment-16522654
]
Robbie Gemmell commented on QPIDJMS-396:
A fixup commit:
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/842ce905
{noformat}
Commit: 842ce9059f7d515500eebcbf850f514f259a43a6
Author: Robbie Gemmell
Authored: Mon Jun 25 19:19:06 2018 +0100
QPIDJMS-396: avoid corner case leading to unexpected wait
{noformat}
> 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
>Priority: Major
> 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=16522592#comment-16522592
]
Timothy Bish commented on QPIDJMS-395:
--
Fix for handling connection remote closed and resending pending messages:
https://git1-us-west.apache.org/repos/asf?p=qpid-jms.git;a=commit;h=fe0307b58beb7ec344f728e34a7ca0e3ef103add
{noformat}
QPIDJMS-395 Resend message in flight when remote closed
When the remote closes the connection and an inflight send
is outstanding we should handle the close and resend those
messages that are still awaiting dispositions in the same
manner as we do when the connection unexpectedly drops when
using the Failover feature.
{noformat}
> 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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
>
[jira] [Updated] (PROTON-1615) c++: container leaks if exception thrown by handler.
[
https://issues.apache.org/jira/browse/PROTON-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1615:
---
Fix Version/s: (was: proton-c-0.24.0)
> c++: container leaks if exception thrown by handler.
>
>
> Key: PROTON-1615
> URL: https://issues.apache.org/jira/browse/PROTON-1615
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Labels: leak
>
> An exception throw by a handler is re-thrown out of container.run() as
> expected, however
> the container does not shut down cleanly and many leaks are reported by
> valgrind or asan. The container should be exception-safe.
> To demonstrate the problem apply this small patch to the helloworld_direct
> example.
> examples/cpp/helloworld_direct.cpp | 1 +
> modified examples/cpp/helloworld_direct.cpp
> @@ -53,6 +53,7 @@ class hello_world_direct : public proton::messaging_handler
> {
>
> // Receive one message and stop listener
> void on_message(proton::delivery &, proton::message ) OVERRIDE {
> +throw std::runtime_error("thrown from on_message");
> std::cout << m.body() << std::endl;
> listener.stop();
> }
--
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-1496) C epoll proactor needs better timer implementation for connections
[ https://issues.apache.org/jira/browse/PROTON-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1496: --- Fix Version/s: (was: proton-c-0.24.0) > C epoll proactor needs better timer implementation for connections > -- > > Key: PROTON-1496 > URL: https://issues.apache.org/jira/browse/PROTON-1496 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 > Environment: Linux environments with epoll support >Reporter: Cliff Jansen >Assignee: Alan Conway >Priority: Major > > The epoll proactor allocates a timerfd per connection. This is a convenience > for the initial implementation and may surprise some applications running > into system limits on file descriptors twice as fast as expected. > The timer is used for heartbeats. It should be possible to write a > per-proactor heartbeat timer that is shared among the connections -- 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-1795) [cpp] imporved documentation for complex type mapping
[ https://issues.apache.org/jira/browse/PROTON-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1795: --- Fix Version/s: (was: proton-c-0.24.0) > [cpp] imporved documentation for complex type mapping > - > > Key: PROTON-1795 > URL: https://issues.apache.org/jira/browse/PROTON-1795 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > > The complex type mapping section of the doc is brief and cryptic: > > [http://qpid.apache.org/releases/qpid-proton-0.21.0/proton/cpp/api/types_page.html] > > Needs review and improvement, including (but not limited to) > * explain why we allow conversion of AMQP maps to/from sequences: > order-preserving > * clarify use of #include files to enable all or selected conversions. > * include example 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] [Updated] (PROTON-1833) [cpp] Crash on Windows after calling container::stop()
[
https://issues.apache.org/jira/browse/PROTON-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1833:
---
Fix Version/s: (was: proton-c-0.24.0)
> [cpp] Crash on Windows after calling container::stop()
> --
>
> Key: PROTON-1833
> URL: https://issues.apache.org/jira/browse/PROTON-1833
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.21.0
> Environment: Proton version : 0.21
> Windows 7 - 64 bits
> Visual studio 2010
>Reporter: Baptiste
>Assignee: Cliff Jansen
>Priority: Critical
> Labels: crash, windows
>
> Just creating a proton::container, listening locally on
> [0.0.0.0:5672|http://0.0.0.0:5672/] and then call stop() on the container and
> getting outside of the scope (object is then destroy) => the crash happen.
> Where does it crash ? In *win_iocp.c*, the line in red
> void pn_proactor_free(pn_proactor_t *p)
> {
> {color:#ff}DeleteTimerQueueEx(p->timer_queue,
> INVALID_HANDLE_VALUE){color};
> DeleteCriticalSection(>timer_lock);
> DeleteCriticalSection(>bind_lock);
> proactor_shutdown(p);
> delete p->reaper;
> WSACleanup();
> pn_collector_free(p->collector);
> free(p);
> }
>
> NOTE:
> A lot of tests failed on windows :
> 1> The following tests FAILED:
> 1> 8 - cpp-container_test (Failed)
> 1> 10 - cpp-reconnect_test (Failed)
> 1> 21 - c-proactor-tests (Failed)
> 1> 23 - c-example-tests (Failed)
> 1> 24 - cpp-example-container (Failed)
> 1> 25 - cpp-example-container-ssl (Failed)
--
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-1770) [cpp] win_iocp fix for seg fault in reconnect test
[
https://issues.apache.org/jira/browse/PROTON-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-1770:
---
Fix Version/s: (was: proton-c-0.24.0)
> [cpp] win_iocp fix for seg fault in reconnect test
> --
>
> Key: PROTON-1770
> URL: https://issues.apache.org/jira/browse/PROTON-1770
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding, proton-c
>Affects Versions: proton-c-0.20.0
>Reporter: Alan Conway
>Assignee: Cliff Jansen
>Priority: Major
> Labels: windows
>
> See [https://issues.jboss.org/browse/ENTMQCL-600] for details and reproducer
> code, summary:
>
> Using the to be attached reproducer and broker configuration:
> Running amqsender
> ./amqsender microseconds>
> e.g.
> ./amqsender testbox111:5672 testbox111:5673 anon anon Q1 1
> You can reproduce the coredump with just one broker
> 1. keep slave down
> 2. start master broker
> 3. run amqsender with a very low frequency
> 4. kill master broker
> This should reproduce the coredump.
> The reproducer has events implemented for on_transport_close yet we see:
> {code}
> .
> .
> .
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_WAKE, pn_connection<0x7fffec000b90>)
> AMQSender::on_connection_wake pn_connection<0x7fffec000b90>
> [0x7fffec0169b0]:(PN_TRANSPORT_TAIL_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_ERROR, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_HEAD_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_TRANSPORT_CLOSED, pn_transport<0x7fffec0169b0>)
> [0x7fffec0169b0]:(PN_CONNECTION_INIT, pn_connection<0x7fffec000b90>)
> Thread 1 "amqsender" received signal SIGSEGV, Segmentation fault.
> 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-lib-2.1.26-26.2.fc24.x86_64 cyrus-sasl-md5-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-plain-2.1.26-26.2.fc24.x86_64
> cyrus-sasl-scram-2.1.26-26.2.fc24.x86_64 keyutils-libs-1.5.9-8.fc24.x86_64
> krb5-libs-1.14.4-7.fc25.x86_64 libcom_err-1.43.3-1.fc25.x86_64
> libcrypt-nss-2.24-4.fc25.x86_64 libdb-5.3.28-16.fc25.x86_64
> libgcc-6.3.1-1.fc25.x86_64 libselinux-2.5-13.fc25.x86_64
> libstdc++-6.3.1-1.fc25.x86_64 nss-softokn-freebl-3.28.3-1.1.fc25.x86_64
> openssl-libs-1.0.2k-1.fc25.x86_64 pcre-8.40-5.fc25.x86_64
> zlib-1.2.8-10.fc24.x86_64
> (gdb) bt
> #0 0x772bcdd0 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x776dc4fa in lock (m=0x1a0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:112
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> #3 0x776def0e in pn_connection_wake (c=0x7fffec000b90) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:1302
> #4 0x77b81b82 in proton::container::impl::connection_work_queue::add
> (this=0x7fffec001d30, f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/proactor_container_impl.cpp:118
> #5 0x77bacde5 in proton::work_queue::add (this=0x7fffec001cd8,
> f=...) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/bindings/cpp/src/work_queue.cpp:43
> #6 0x0040536f in AMQSender::send (this=this@entry=0x7fffd960,
> strMsg="7578") at ../attachments/AMQSender.cpp:42
> #7 0x0040328f in main (argc=, argv=0x7fffdbd8) at
> ../attachments/amqsend.cpp:20
> (gdb) frame 2
> #2 0x776dcc09 in wake (ctx=0x7fffec2b8ac0) at
> /home/rkieley/LocalProjects/src/rh/rh-qpid-proton/proton-c/src/proactor/epoll.c:436
> 436 lock(>eventfd_mutex);
> (gdb) print p
> $3 = (pn_proactor_t *) 0x0
> (gdb)
> {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] [Updated] (PROTON-778) [c] Optimize de-duplication of PN_LINK_FLOW events
[ https://issues.apache.org/jira/browse/PROTON-778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-778: -- Fix Version/s: (was: proton-c-0.24.0) > [c] Optimize de-duplication of PN_LINK_FLOW events > -- > > Key: PROTON-778 > URL: https://issues.apache.org/jira/browse/PROTON-778 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.8 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: perf > > As per Rafi's suggestion on the proton mailing list: > http://mail-archives.apache.org/mod_mbox/qpid-proton/201412.mbox/%3CCACL1BnB5s6hTVA7KpjHKE02d1sLZb=PZPOQqpjUUeeaVk=g...@mail.gmail.com%3E > To summarize: emit the PN_LINK_FLOW event for local credit change only once > after all pending messages for a given link have been written to the > transport. -- 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-1866) cannot tell whether peer specified expiry-policy on terminus
[ https://issues.apache.org/jira/browse/PROTON-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1866: --- Fix Version/s: proton-c-0.24.0 > cannot tell whether peer specified expiry-policy on terminus > > > Key: PROTON-1866 > URL: https://issues.apache.org/jira/browse/PROTON-1866 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.23.0 >Reporter: Gordon Sim >Priority: Major > Fix For: proton-c-0.24.0 > > > This prevents anything using proton-c to behave differently if an explicit > policy is set. -- 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] (PROTON-1866) cannot tell whether peer specified expiry-policy on terminus
[ https://issues.apache.org/jira/browse/PROTON-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-1866: -- Assignee: Gordon Sim > cannot tell whether peer specified expiry-policy on terminus > > > Key: PROTON-1866 > URL: https://issues.apache.org/jira/browse/PROTON-1866 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.23.0 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > Fix For: proton-c-0.24.0 > > > This prevents anything using proton-c to behave differently if an explicit > policy is set. -- 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-396) Performance improvements for inter-thread event signalling
[ https://issues.apache.org/jira/browse/QPIDJMS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-396. -- Resolution: Fixed > 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 >Priority: Major > 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] (DISPATCH-1041) Add new test to validate global delivery counts provided by the router
[ https://issues.apache.org/jira/browse/DISPATCH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522569#comment-16522569 ] ASF GitHub Bot commented on DISPATCH-1041: -- Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/327 > Add new test to validate global delivery counts provided by the router > -- > > Key: DISPATCH-1041 > URL: https://issues.apache.org/jira/browse/DISPATCH-1041 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.2.0 > > > The following are global counts provided by the router - > # deliveriesEgressRouteContainer > # deliveriesIngressRouteContainer > # deliveriesTransit > # deliveriesEgress > # deliveriesIngress > # modifiedDeliveries > # releasedDeliveries > # rejectedDeliveries > # acceptedDeliveries > # droppedPresettledDeliveries > # presettledDeliveries -- 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
[GitHub] qpid-dispatch pull request #327: DISPATCH-1041 - Add tests to validate each ...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/327 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1041) Add new test to validate global delivery counts provided by the router
[ https://issues.apache.org/jira/browse/DISPATCH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522567#comment-16522567 ] ASF subversion and git services commented on DISPATCH-1041: --- Commit a9bf2923717d3ae9efb36fe72284a544e02d9b44 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a9bf292 ] DISPATCH-1041 - Add tests to validate each global delivery count accurately > Add new test to validate global delivery counts provided by the router > -- > > Key: DISPATCH-1041 > URL: https://issues.apache.org/jira/browse/DISPATCH-1041 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.2.0 > > > The following are global counts provided by the router - > # deliveriesEgressRouteContainer > # deliveriesIngressRouteContainer > # deliveriesTransit > # deliveriesEgress > # deliveriesIngress > # modifiedDeliveries > # releasedDeliveries > # rejectedDeliveries > # acceptedDeliveries > # droppedPresettledDeliveries > # presettledDeliveries -- 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] (DISPATCH-1041) Add new test to validate global delivery counts provided by the router
[ https://issues.apache.org/jira/browse/DISPATCH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1041. - Resolution: Fixed > Add new test to validate global delivery counts provided by the router > -- > > Key: DISPATCH-1041 > URL: https://issues.apache.org/jira/browse/DISPATCH-1041 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.2.0 > > > The following are global counts provided by the router - > # deliveriesEgressRouteContainer > # deliveriesIngressRouteContainer > # deliveriesTransit > # deliveriesEgress > # deliveriesIngress > # modifiedDeliveries > # releasedDeliveries > # rejectedDeliveries > # acceptedDeliveries > # droppedPresettledDeliveries > # presettledDeliveries -- 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-396) Performance improvements for inter-thread event signalling
[
https://issues.apache.org/jira/browse/QPIDJMS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522560#comment-16522560
]
Timothy Bish commented on QPIDJMS-396:
--
Commit that resolves this:
https://git1-us-west.apache.org/repos/asf?p=qpid-jms.git;a=commit;h=c66d888114021da31d9032c841c08903dd31cc89
{quote}
QPIDJMS-396 Allow for faster reaction times on sync operations
For sync operations from the JMS layer into the provider we can
more quickly process the events by using a spin-wait future that
checks in a short spin for the completion of the target event.
The spin will back off and eventually back down to a parked wait
that will be signalled by the normal wait / notify pattern.
{quote}
> 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
>Priority: Major
> 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] [Updated] (PROTON-1816) [c] deprecate old netaddr function names
[ https://issues.apache.org/jira/browse/PROTON-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1816: --- Fix Version/s: (was: proton-c-0.24.0) proton-c-0.25.0 > [c] deprecate old netaddr function names > > > Key: PROTON-1816 > URL: https://issues.apache.org/jira/browse/PROTON-1816 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-j-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: proton-c-0.25.0 > > > See PROTON-1781 - the functions were re-named but the deprecation macros were > commented out to give people a release cycle to adjust to the new names. -- 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-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] [Updated] (PROTON-1801) Strip the version from the /usr/share/proton dir
[ https://issues.apache.org/jira/browse/PROTON-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1801: Fix Version/s: (was: proton-c-0.24.0) > Strip the version from the /usr/share/proton dir > > > Key: PROTON-1801 > URL: https://issues.apache.org/jira/browse/PROTON-1801 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > > It's contrary to the dominant convention, and it litters /usr/share with old > dirs. -- 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-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-342: --- Fix Version/s: (was: proton-c-0.24.0) > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Assignee: Justin Ross >Priority: Major > Labels: docs > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- 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-1867) Debug libs missing in Windows build
[ https://issues.apache.org/jira/browse/PROTON-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1867. - Resolution: Fixed > Debug libs missing in Windows build > --- > > Key: PROTON-1867 > URL: https://issues.apache.org/jira/browse/PROTON-1867 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.24.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] [Commented] (DISPATCH-1041) Add new test to validate global delivery counts provided by the router
[ https://issues.apache.org/jira/browse/DISPATCH-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522443#comment-16522443 ] ASF GitHub Bot commented on DISPATCH-1041: -- Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/327 It covers everything now! > Add new test to validate global delivery counts provided by the router > -- > > Key: DISPATCH-1041 > URL: https://issues.apache.org/jira/browse/DISPATCH-1041 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.1.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.2.0 > > > The following are global counts provided by the router - > # deliveriesEgressRouteContainer > # deliveriesIngressRouteContainer > # deliveriesTransit > # deliveriesEgress > # deliveriesIngress > # modifiedDeliveries > # releasedDeliveries > # rejectedDeliveries > # acceptedDeliveries > # droppedPresettledDeliveries > # presettledDeliveries -- 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
[GitHub] qpid-dispatch issue #327: DISPATCH-1041 - Add tests to validate each global ...
Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/327 It covers everything now! --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1049) Add console tests
Ernest Allen created DISPATCH-1049: -- Summary: Add console tests Key: DISPATCH-1049 URL: https://issues.apache.org/jira/browse/DISPATCH-1049 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.1.0 Reporter: Ernest Allen Assignee: Ernest Allen Add tests for the console's javascript code to the test system. -- 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] (DISPATCH-1017) Use a javascript build system for the console
[ https://issues.apache.org/jira/browse/DISPATCH-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1017. Resolution: Implemented Fix Version/s: 1.2.0 > Use a javascript build system for the console > - > > Key: DISPATCH-1017 > URL: https://issues.apache.org/jira/browse/DISPATCH-1017 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.1.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > Fix For: 1.2.0 > > Attachments: CMakeLists.txt > > > It's time to use a javascript build system such as gulp for the console. > A build system would run during the router's 'make install' and do the > following: > * npm install all 3rd party libraries > * compile any typescript and scss files to .js and .css respectively > * package all .css files (3rd party and homegrown) into a single .css file > * package all .js files (again 3rd party and homegrown) into a single .js > file > * minify the css and js files > * run a javascript linter > After the gulp build, only a few files would need to be copied to the console > install directory. > To ensure the downstream package builds are consistent, the package_lock.json > file should specify which version of the 3rd party libraries to use. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-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=16522055#comment-16522055
]
Robbie Gemmell edited comment on QPIDJMS-395 at 6/25/18 10:16 AM:
--
The git->JIRA comment bot is playing up. Changes were made against this JIRA in
the following commits:
[http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/4bfe7f5a]
{noformat}
commit 4bfe7f5ae60680d220dbe2b7cbcfeb824b5e6e9d
Author: Timothy Bish
Date: Tue Jun 19 15:03:15 2018 -0400
QPIDJMS-395 Add failed state in provider to prevent possible race
Adds a failed state to the AMQP provider such that any queued actions
such as a send which race into the provider between the time a
connection error is detected and the failover bits close the provider
received a consistent exception that allows normal failover processing
to occur.
{noformat}
[http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/38459911]
{noformat}
commit 3845991106aaad1421fbf3bdb4375f367c2ac9cd
Author: Timothy Bish
Date: Tue Jun 19 19:04:20 2018 -0400
QPIDJMS-395 Throw a more descriptive exception type when forced
Use a somewhat more descriptive exception type when the connection is
remotely closed due to a forced error condition to aid in debug.
{noformat}
[http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/09546c55]
{noformat}
commit 09546c553c0a8fccedcc36b73e4ef33d42ceff7f
Author: Timothy Bish
Date: Thu Jun 21 18:13:31 2018 -0400
QPIDJMS-395 Adding additional failover handling tests
Add new test that validates reconnect on error after a successful
connection was made and the next reconnect has its open attempt
rejected. Client should reconnect to final peer and return to normal
operation.
{noformat}
was (Author: gemmellr):
The git->JIRA comment bot is playing up. Changes were made against this JIRA in
the following commits:
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/4bfe7f5a
{noformat}
commit 4bfe7f5ae60680d220dbe2b7cbcfeb824b5e6e9d
Author: Timothy Bish
Date: Tue Jun 19 15:03:15 2018 -0400
QPIDJMS-395 Add failed state in provider to prevent possible race
Adds a failed state to the AMQP provider such that any queued actions
such as a send which race into the provider between the time a
connection error is detected and the failover bits close the provider
received a consistent exception that allows normal failover processing
to occur.
{noformat}
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/38459911
{noformat}
commit 3845991106aaad1421fbf3bdb4375f367c2ac9cd
Author: Timothy Bish
Date: Tue Jun 19 19:04:20 2018 -0400
QPIDJMS-395 Throw a more descriptive exception type when forced
Use a somewhat more descriptive exception type when the connection is
remotely closed due to a forced error condition to aid in debug.
{noformat}
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/09546c55
{noformat}
commit 09546c553c0a8fccedcc36b73e4ef33d42ceff7f
Author: Timothy Bish
Date: Thu Jun 21 18:13:31 2018 -0400
QPIDJMS-395 Adding additional failover handling tests
Add new test that validates reconnect on error after a successful
connection was made and the next reconnect has its open attempt
rejected. Client should reconnect to final peer and return to normal
operation.
{noformat}
> 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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
> +++
>
[jira] [Assigned] (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:all-tabpanel
]
Robbie Gemmell reassigned QPIDJMS-395:
--
Assignee: Timothy Bish
> 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
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.34.0
>
>
> 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, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false}
[jira] [Updated] (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:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-395:
---
Fix Version/s: 0.34.0
> 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
> Fix For: 0.34.0
>
>
> 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, rcvSettleMode=null, state=null,
> resume=false, aborted=false, batchable=false} (179)
>
[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=16522055#comment-16522055
]
Robbie Gemmell commented on QPIDJMS-395:
The git->JIRA comment bot is playing up. Changes were made against this JIRA in
the following commits:
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/4bfe7f5a
{noformat}
commit 4bfe7f5ae60680d220dbe2b7cbcfeb824b5e6e9d
Author: Timothy Bish
Date: Tue Jun 19 15:03:15 2018 -0400
QPIDJMS-395 Add failed state in provider to prevent possible race
Adds a failed state to the AMQP provider such that any queued actions
such as a send which race into the provider between the time a
connection error is detected and the failover bits close the provider
received a consistent exception that allows normal failover processing
to occur.
{noformat}
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/38459911
{noformat}
commit 3845991106aaad1421fbf3bdb4375f367c2ac9cd
Author: Timothy Bish
Date: Tue Jun 19 19:04:20 2018 -0400
QPIDJMS-395 Throw a more descriptive exception type when forced
Use a somewhat more descriptive exception type when the connection is
remotely closed due to a forced error condition to aid in debug.
{noformat}
http://git-wip-us.apache.org/repos/asf/qpid-jms/commit/09546c55
{noformat}
commit 09546c553c0a8fccedcc36b73e4ef33d42ceff7f
Author: Timothy Bish
Date: Thu Jun 21 18:13:31 2018 -0400
QPIDJMS-395 Adding additional failover handling tests
Add new test that validates reconnect on error after a successful
connection was made and the next reconnect has its open attempt
rejected. Client should reconnect to final peer and return to normal
operation.
{noformat}
> 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]
>
