[jira] [Commented] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539380#comment-16539380 ] ASF subversion and git services commented on DISPATCH-1069: --- Commit f87a33389b268ef5fe20a8b08179310f1c135d28 in qpid-dispatch's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f87a333 ] DISPATCH-1069: memory grows on a long-lived connection Fixed by removing the test `pn_link_get_context(link)` while handling PN_LINK_LOCAL_CLOSE. qd_link_free() can clear the pn_link context before the PN_LINK_LOCAL_CLOSE event is handled, in that case the link was never freed. The fix won't cause double-free. pn_link_free() is only called in 2 places, handling PN_LINK_LOCAL_CLOSE and PN_LINK_REMOTE_CLOSE. In both cases it is only called if the link is closed at both ends. It is not possible for both of these events to fire for the same link with both ends closed, the one that fires first will always have the other end open. > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- 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-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved DISPATCH-1069. --- Resolution: Fixed > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- 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] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-1069: -- Attachment: link-leak.py > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- 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] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
[ https://issues.apache.org/jira/browse/DISPATCH-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-1069: -- Attachment: link-leak.c > memory grows on a long-lived connection when links are opened and closed > > > Key: DISPATCH-1069 > URL: https://issues.apache.org/jira/browse/DISPATCH-1069 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.2.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Attachments: link-leak.c, link-leak.py > > > The attached reproducers link-leak.c and link-leak.py open and close links > repeatedly on the same connection. This causes the routers memory use to grow. > Massif shows that the memory is due to pn_link_t and related objects. > PROTON-905 describes an old bug where link information is leaked but > experiments show this is not happening with modern proton. > I suspect the growth is due to dispatch sometimes failing to call > pn_link_free() but investigation is still ongoing. -- 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-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-905. Resolution: Fixed Fix Version/s: (was: proton-c-future) proton-c-0.24.0 > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: leak > Fix For: proton-c-0.24.0 > > Attachments: link-leak.c, test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- 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-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539305#comment-16539305 ] Alan Conway commented on PROTON-905: Correction - my C reproducer does not show this problem in plain proton C. In my earlier test the C example broker was growing because of per-address overhead in the broker, not because of leaked links. I'm not seeing growth when all the receivers use the same address. I've opened DISPATCH-1069 for a dispatch memory growth problem that we originally suspected was related to this issue, but I suspect now that it is a dispatch bug rather than a proton-C bug. As far as I can tell, this issue was fixed at some point in the past - I don't see it in current proton. > Long-lived connections leak sessions and links > -- > > Key: PROTON-905 > URL: https://issues.apache.org/jira/browse/PROTON-905 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9.1, 0.10 >Reporter: Ken Giusti >Assignee: Alan Conway >Priority: Major > Labels: leak > Fix For: proton-c-future > > Attachments: link-leak.c, test-send.py > > > I found this issue while debugging a crash dump of qpidd. > Long lived connections do not free its sessions/link. > This only applies when NOT using the event model. The version of qpidd I > tested against (0.30) still uses the iterative model. Point to consider, I > don't know why this is the case. > Details: I have a test script that opens a single connection, then > continually creates sessions/links over that connection, sending one message > before closing and freeing the sessions/links. See attached. > Over time the qpidd run time consumes all memory on the system and is killed > by OOM. To be clear, I'm using drain to remove all sent messages - there is > no message build up. > On debugging this, I'm finding thousands of session objects on the > connections free sessions weakref list. Every one of those sessions has a > refcount of one. > Once the connection is finalized, all session objects are freed. But until > then, freed sessions continue to accumulate indefinitely. -- 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] (DISPATCH-1069) memory grows on a long-lived connection when links are opened and closed
Alan Conway created DISPATCH-1069: - Summary: memory grows on a long-lived connection when links are opened and closed Key: DISPATCH-1069 URL: https://issues.apache.org/jira/browse/DISPATCH-1069 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 1.2.0 Reporter: Alan Conway Assignee: Alan Conway The attached reproducers link-leak.c and link-leak.py open and close links repeatedly on the same connection. This causes the routers memory use to grow. Massif shows that the memory is due to pn_link_t and related objects. PROTON-905 describes an old bug where link information is leaked but experiments show this is not happening with modern proton. I suspect the growth is due to dispatch sometimes failing to call pn_link_free() but investigation is still ongoing. -- 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-1008) Router should preserve original connection information when attempting to make failover connections
[
https://issues.apache.org/jira/browse/DISPATCH-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539303#comment-16539303
]
ASF subversion and git services commented on DISPATCH-1008:
---
Commit cc3ab65578701dd0df262ce346f0443cc21b9975 in qpid-dispatch's branch
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=cc3ab65 ]
DISPATCH-1008: Failover test waits for inter-router status
After Router A fails over from B to C, wait for the inter-router
connection to RouterC to show up in RouterC's management stack
before declaring an error.
> Router should preserve original connection information when attempting to
> make failover connections
> ---
>
> Key: DISPATCH-1008
> URL: https://issues.apache.org/jira/browse/DISPATCH-1008
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: broker-slave.xml, broker.xml, qdrouterd-failover.conf
>
>
> # Start artemis master and slave brokers and the router with the attached
> config files.
> # Notice that the router receives an open frame from the master broker with
> the following failover information
> #
> {noformat}
> 2018-05-22 22:11:11.830106 -0230 SERVER (trace) [1]:0 <- @open(16)
> [container-id="localhost", max-frame-size=4294967295, channel-max=65535,
> idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis",
> :"failover-server-list"=[{:hostname="0.0.0.8", :scheme="amqp", :port=61617,
> :"network-host"="0.0.0.0"}]"}]{noformat}
>
> # Now, kill the master broker and notice that the router correctly fails
> over to the slave broker. But the slave broker does not provide any failover
> information in its open frame and hence the router erases its original master
> broker connection information
> # When the master broker is now restarted and the slave broker is killed,
> the router attempts to repeatedly connect only to the slave broker but never
> attempts a connection to the master broker.
> # If the router did not erase its failover list but preserved the original
> master connection information, it would have connected the master broker.
--
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-jms issue #19: Save allocation of new promise on each writeAndFlush
Github user tabish121 commented on the issue: https://github.com/apache/qpid-jms/pull/19 I spent some time reviewing netty code and getting a handle on how this would change the current behavior. From what I can see this should be safe to apply. The tests all pass from a local checkout as well. I'd recommend creating a JIRA and updating the PR with the JIRA issue to link up the work done here. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1007) Document using patterns for policy hostnames
[ https://issues.apache.org/jira/browse/DISPATCH-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Hardesty closed DISPATCH-1007. -- Resolution: Duplicate > Document using patterns for policy hostnames > > > Key: DISPATCH-1007 > URL: https://issues.apache.org/jira/browse/DISPATCH-1007 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > This was documented previously in the old book, but needs to be ported to the > new book. > https://github.com/apache/qpid-dispatch/pull/304 -- 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-1892) Deliveries on different links use the same delivery-id
Marcel Meulemans created PROTON-1892: Summary: Deliveries on different links use the same delivery-id Key: PROTON-1892 URL: https://issues.apache.org/jira/browse/PROTON-1892 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.27.1 Reporter: Marcel Meulemans Attachments: proton-j-delivery-id-fix.patch, proton-trace.log Given a session with two outgoing links the situation can occur that two deliveries on separate links share the same delivery-id. This situation occurs when a multi frame transfer is being sent on link A and a new (single frame) transfer is sent (multiplexed) on link B before the delivery on link A completes. The reason this occurs is because the increment of the delivery id counter (maintained per session) is delayed until the entire (multi frame) delivery is complete ([here|https://github.com/apache/qpid-proton-j/blob/e5a7dcade2996b2b68967949ddf1377f954bf579/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L619]) allowing the second delivery to get the same delivery id when calling getOutgoingDeliveryId [here|https://github.com/apache/qpid-proton-j/blob/e5a7dcade2996b2b68967949ddf1377f954bf579/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L559] My 100% reproduction scenario is as follows: * Run artemis (2.6.2 which uses proton-j 0.27.1) with an AMQP connector * Send a large message (10MB) to queue A * Send a couple of small messages to queue B * Connect a proton-c based client with a small maxFrameSize (8K) and limited credit to artemis and simultaneously subscribe to both queues (I think a flow frame triggers artemis to initiate a transfer therefore the limited credit). With proton-c trace logging enable you will get something like this: [^proton-trace.log] The attached patch fixes the issue. [^proton-j-delivery-id-fix.patch] -- 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] (DISPATCH-1068) Doc capability for vhost policy sources and targets to handle multiple wildcards
Ben Hardesty created DISPATCH-1068: -- Summary: Doc capability for vhost policy sources and targets to handle multiple wildcards Key: DISPATCH-1068 URL: https://issues.apache.org/jira/browse/DISPATCH-1068 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.2.0 Reporter: Ben Hardesty Assignee: Ben Hardesty When configuring vhost policies to enable a user group to access a source or target address, you can use a wildcard to denote an address pattern that matches multiple addresses. Previously you could only use the wildcard as the last character in the address name, but now you can use a wildcard anywhere in the address name. -- 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] (DISPATCH-1067) Doc improvements for router policies
Ben Hardesty created DISPATCH-1067: -- Summary: Doc improvements for router policies Key: DISPATCH-1067 URL: https://issues.apache.org/jira/browse/DISPATCH-1067 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.2.0 Reporter: Ben Hardesty Assignee: Ben Hardesty The router policy doc needs to be updated to cover the following enhancements: * Patterns for policy hostnames (DISPATCH-990) * New policy config attributes (DISPATCH-976) * Policy username substitution improvements (DISPATCH-1011) * Allow vhost policies to be configured in the router configuration file (DISPATCH-1013) -- 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] (QPIDIT-129) tests reference wrong 'shim' version for Qpid JMS
[
https://issues.apache.org/jira/browse/QPIDIT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538956#comment-16538956
]
ASF subversion and git services commented on QPIDIT-129:
Commit 7af2e6db6299ebd4b656b404791160153caebe26 in qpid-interop-test's branch
refs/heads/master from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=7af2e6d ]
QPIDIT-129: Updated hard-coded shim version number in qit_common.py.
> tests reference wrong 'shim' version for Qpid JMS
> -
>
> Key: QPIDIT-129
> URL: https://issues.apache.org/jira/browse/QPIDIT-129
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.2.0
>Reporter: Robbie Gemmell
>Assignee: Kim van der Riet
>Priority: Blocker
> Fix For: 0.2.0
>
>
> The installed 0.2.0 RC2 tests look for the wrong shim, at:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.1.0-jar-with-dependencies.jar
> {noformat}
> While the file actually installed, after the changes in RC2 is now correctly
> named:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.2.0-jar-with-dependencies.jar
> {noformat}
> This causes the tests to fail (once QPIDIT-128 is worked around).
--
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] (QPIDIT-129) tests reference wrong 'shim' version for Qpid JMS
[
https://issues.apache.org/jira/browse/QPIDIT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538932#comment-16538932
]
Kim van der Riet commented on QPIDIT-129:
-
There is an ugly hard-coded declaration of the shim version number in
{{qit_common.py:42}}. The version of the shim to use should be known by some
other means that automatically changes when QIT is built. For now, I have
updated the ugly declaration, and the JMS tests are working again.
However, I want to keep this open until I have made a fix which automatically
changes the version number at build time.
> tests reference wrong 'shim' version for Qpid JMS
> -
>
> Key: QPIDIT-129
> URL: https://issues.apache.org/jira/browse/QPIDIT-129
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.2.0
>Reporter: Robbie Gemmell
>Assignee: Kim van der Riet
>Priority: Blocker
> Fix For: 0.2.0
>
>
> The installed 0.2.0 RC2 tests look for the wrong shim, at:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.1.0-jar-with-dependencies.jar
> {noformat}
> While the file actually installed, after the changes in RC2 is now correctly
> named:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.2.0-jar-with-dependencies.jar
> {noformat}
> This causes the tests to fail (once QPIDIT-128 is worked around).
--
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] (QPIDIT-129) tests reference wrong 'shim' version for Qpid JMS
[
https://issues.apache.org/jira/browse/QPIDIT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538928#comment-16538928
]
ASF subversion and git services commented on QPIDIT-129:
Commit d3bcb0c737e4f4f7f171af8ae4e528edea937d2f in qpid-interop-test's branch
refs/heads/0.2.0 from [~kpvdr]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=d3bcb0c ]
QPIDIT-129: Updated hard-coded shim version number in qit_common.py.
> tests reference wrong 'shim' version for Qpid JMS
> -
>
> Key: QPIDIT-129
> URL: https://issues.apache.org/jira/browse/QPIDIT-129
> Project: Apache QPID Interoperability Test Suite
> Issue Type: Bug
> Components: Installation
>Affects Versions: 0.2.0
>Reporter: Robbie Gemmell
>Assignee: Kim van der Riet
>Priority: Blocker
> Fix For: 0.2.0
>
>
> The installed 0.2.0 RC2 tests look for the wrong shim, at:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.1.0-jar-with-dependencies.jar
> {noformat}
> While the file actually installed, after the changes in RC2 is now correctly
> named:
> {noformat}
> /path.to/install/libexec/qpid_interop_test/shims/qpid-jms/qpid-interop-test-jms-shim-0.2.0-jar-with-dependencies.jar
> {noformat}
> This causes the tests to fail (once QPIDIT-128 is worked around).
--
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-1060) test suite leaves some running routers behind
[
https://issues.apache.org/jira/browse/DISPATCH-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1060.
-
Resolution: Fixed
Fix Version/s: 1.3.0
> test suite leaves some running routers behind
> -
>
> Key: DISPATCH-1060
> URL: https://issues.apache.org/jira/browse/DISPATCH-1060
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.2.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.3.0
>
>
> Running the test suite leaves behind some running routers. Looking at running
> processes, I noticed:
> {noformat}
> user 88721 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88726 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88731 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88736 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88741 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88746 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88993 1554 TS 19 17:16 pts/16 00:00:00 qdrouterd -c
> expect_fail.conf -I /path.to/qpid-dispatch-1.2.0/python
> {noformat}
> Using pwdx to look closer seems to reveal which tests left each router behind:
> {noformat}
> 88721:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterIngressEgressTest/setUpClass
> (deleted)
> 88726:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterModifiedTest/setUpClass
> (deleted)
> 88731:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterRejectedTest/setUpClass
> (deleted)
> 88736:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterReleasedDroppedPresettledTest/setUpClass
> (deleted)
> 88741:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/RouteContainerEgressCount/setUpClass
> (deleted)
> 88746:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/RouteContainerIngressCount/setUpClass
> (deleted)
> 88993:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_http/RouterTestHttp/test_http_listener_delete
> (deleted)
> {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] (DISPATCH-1060) test suite leaves some running routers behind
[
https://issues.apache.org/jira/browse/DISPATCH-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538834#comment-16538834
]
ASF subversion and git services commented on DISPATCH-1060:
---
Commit 42a4666f1579c5aa3bb020a94f90285c671e4c12 in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=42a4666 ]
DISPATCH-1060 - Fixed tests that were creating internal router instances
instead of using functions offered by the test framework
> test suite leaves some running routers behind
> -
>
> Key: DISPATCH-1060
> URL: https://issues.apache.org/jira/browse/DISPATCH-1060
> Project: Qpid Dispatch
> Issue Type: Test
>Affects Versions: 1.2.0
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
>Priority: Major
>
> Running the test suite leaves behind some running routers. Looking at running
> processes, I noticed:
> {noformat}
> user 88721 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88726 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88731 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88736 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88741 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88746 1554 TS 19 17:15 pts/16 00:00:00 qdrouterd -c A.conf -I
> /path.to/qpid-dispatch-1.2.0/python
> user 88993 1554 TS 19 17:16 pts/16 00:00:00 qdrouterd -c
> expect_fail.conf -I /path.to/qpid-dispatch-1.2.0/python
> {noformat}
> Using pwdx to look closer seems to reveal which tests left each router behind:
> {noformat}
> 88721:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterIngressEgressTest/setUpClass
> (deleted)
> 88726:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterModifiedTest/setUpClass
> (deleted)
> 88731:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterRejectedTest/setUpClass
> (deleted)
> 88736:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/OneRouterReleasedDroppedPresettledTest/setUpClass
> (deleted)
> 88741:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/RouteContainerEgressCount/setUpClass
> (deleted)
> 88746:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_global_delivery_counts/RouteContainerIngressCount/setUpClass
> (deleted)
> 88993:
> /path.to/qpid-dispatch-1.2.0/build/tests/system_test.dir/system_tests_http/RouterTestHttp/test_http_listener_delete
> (deleted)
> {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] (DISPATCH-977) Document transaction support
[ https://issues.apache.org/jira/browse/DISPATCH-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-977. Resolution: Fixed Fix Version/s: 1.3.0 > Document transaction support > > > Key: DISPATCH-977 > URL: https://issues.apache.org/jira/browse/DISPATCH-977 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > Fix For: 1.3.0 > > > Dispatch Router provides transaction support through link routes and > $coordinator. This capability should be documented. -- 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-977) Document transaction support
[ https://issues.apache.org/jira/browse/DISPATCH-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538740#comment-16538740 ] ASF subversion and git services commented on DISPATCH-977: -- Commit 3938487f849d86bb0ac8250f0af9be9d1d95965c in qpid-dispatch's branch refs/heads/master from [~bhardest] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=3938487 ] DISPATCH-977 - Add transaction coordinator step to link routing procedure. This closes #293 > Document transaction support > > > Key: DISPATCH-977 > URL: https://issues.apache.org/jira/browse/DISPATCH-977 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > Fix For: 1.3.0 > > > Dispatch Router provides transaction support through link routes and > $coordinator. This capability should be documented. -- 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-977) Document transaction support
[ https://issues.apache.org/jira/browse/DISPATCH-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538742#comment-16538742 ] ASF GitHub Bot commented on DISPATCH-977: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/293 > Document transaction support > > > Key: DISPATCH-977 > URL: https://issues.apache.org/jira/browse/DISPATCH-977 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > Fix For: 1.3.0 > > > Dispatch Router provides transaction support through link routes and > $coordinator. This capability should be documented. -- 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 #293: DISPATCH-977: Add transaction coordinator s...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/293 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1065) Doc new router statistics
[ https://issues.apache.org/jira/browse/DISPATCH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-1065. - Resolution: Fixed Fix Version/s: 1.3.0 > Doc new router statistics > - > > Key: DISPATCH-1065 > URL: https://issues.apache.org/jira/browse/DISPATCH-1065 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > Fix For: 1.3.0 > > > Additional statistics are available from the router via the management > protocol. New statistics include: > * Number of pre-settled deliveries dropped on a link > * Global scope counters for link and address statistics > * Per-ingress counts for settled deliveries on egress links > Managment tool doc (qdstat/qdmanage) should be updated to reflect these new > statistics. -- 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-1065) Doc new router statistics
[ https://issues.apache.org/jira/browse/DISPATCH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538595#comment-16538595 ] ASF subversion and git services commented on DISPATCH-1065: --- Commit 19c4118c2d8efe0eb2c80b715623a14d56e5290b in qpid-dispatch's branch refs/heads/master from [~bhardest] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=19c4118 ] DISPATCH-1065 - Update qdstat output for enhanced stats. This closes #337 > Doc new router statistics > - > > Key: DISPATCH-1065 > URL: https://issues.apache.org/jira/browse/DISPATCH-1065 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > Additional statistics are available from the router via the management > protocol. New statistics include: > * Number of pre-settled deliveries dropped on a link > * Global scope counters for link and address statistics > * Per-ingress counts for settled deliveries on egress links > Managment tool doc (qdstat/qdmanage) should be updated to reflect these new > statistics. -- 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-1065) Doc new router statistics
[ https://issues.apache.org/jira/browse/DISPATCH-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538596#comment-16538596 ] ASF GitHub Bot commented on DISPATCH-1065: -- Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/337 > Doc new router statistics > - > > Key: DISPATCH-1065 > URL: https://issues.apache.org/jira/browse/DISPATCH-1065 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.2.0 >Reporter: Ben Hardesty >Assignee: Ben Hardesty >Priority: Major > > Additional statistics are available from the router via the management > protocol. New statistics include: > * Number of pre-settled deliveries dropped on a link > * Global scope counters for link and address statistics > * Per-ingress counts for settled deliveries on egress links > Managment tool doc (qdstat/qdmanage) should be updated to reflect these new > statistics. -- 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 #337: DISPATCH-1065 - Update qdstat output for en...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/337 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1008) Router should preserve original connection information when attempting to make failover connections
[
https://issues.apache.org/jira/browse/DISPATCH-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538563#comment-16538563
]
ASF subversion and git services commented on DISPATCH-1008:
---
Commit 95ef612ccb848b3050ab882e5ebb6cebdb763f08 in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=95ef612 ]
DISPATCH-1008 - Increased the number of attempts to check for connector to 10
so that slower systems will not fail
> Router should preserve original connection information when attempting to
> make failover connections
> ---
>
> Key: DISPATCH-1008
> URL: https://issues.apache.org/jira/browse/DISPATCH-1008
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: broker-slave.xml, broker.xml, qdrouterd-failover.conf
>
>
> # Start artemis master and slave brokers and the router with the attached
> config files.
> # Notice that the router receives an open frame from the master broker with
> the following failover information
> #
> {noformat}
> 2018-05-22 22:11:11.830106 -0230 SERVER (trace) [1]:0 <- @open(16)
> [container-id="localhost", max-frame-size=4294967295, channel-max=65535,
> idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY", :"SHARED-SUBS", :"ANONYMOUS-RELAY"],
> properties={:product="apache-activemq-artemis",
> :"failover-server-list"=[{:hostname="0.0.0.8", :scheme="amqp", :port=61617,
> :"network-host"="0.0.0.0"}]"}]{noformat}
>
> # Now, kill the master broker and notice that the router correctly fails
> over to the slave broker. But the slave broker does not provide any failover
> information in its open frame and hence the router erases its original master
> broker connection information
> # When the master broker is now restarted and the slave broker is killed,
> the router attempts to repeatedly connect only to the slave broker but never
> attempts a connection to the master broker.
> # If the router did not erase its failover list but preserved the original
> master connection information, it would have connected the master broker.
--
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-1891) empty composite buffer slice should not allow appending new data
[ https://issues.apache.org/jira/browse/PROTON-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538480#comment-16538480 ] ASF subversion and git services commented on PROTON-1891: - Commit e36cc1d4a5858521c46ed82195dd5bccd87e706d in qpid-proton-j's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=e36cc1d ] PROTON-1891: ensure the empty slice rejects appends like non-empty slices do > empty composite buffer slice should not allow appending new data > > > Key: PROTON-1891 > URL: https://issues.apache.org/jira/browse/PROTON-1891 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.27.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.28.0 > > > The CompositeReadableBuffer allows aggregating incoming data to be used by > other areas. If a CRB is sliced we prevent appending the slice with new data, > however a specific empty slice is returned if the buffer had no readable data > and this doesn't do the same as intended. -- 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-1891) empty composite buffer slice should not allow appending new data
[ https://issues.apache.org/jira/browse/PROTON-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1891. Resolution: Fixed > empty composite buffer slice should not allow appending new data > > > Key: PROTON-1891 > URL: https://issues.apache.org/jira/browse/PROTON-1891 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.27.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: proton-j-0.28.0 > > > The CompositeReadableBuffer allows aggregating incoming data to be used by > other areas. If a CRB is sliced we prevent appending the slice with new data, > however a specific empty slice is returned if the buffer had no readable data > and this doesn't do the same as intended. -- 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-1891) empty composite buffer slice should not allow appending new data
Robbie Gemmell created PROTON-1891: -- Summary: empty composite buffer slice should not allow appending new data Key: PROTON-1891 URL: https://issues.apache.org/jira/browse/PROTON-1891 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.27.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: proton-j-0.28.0 The CompositeReadableBuffer allows aggregating incoming data to be used by other areas. If a CRB is sliced we prevent appending the slice with new data, however a specific empty slice is returned if the buffer had no readable data and this doesn't do the same as intended. -- 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-1890) [c++] implement idle_timeout and heartbeats
[
https://issues.apache.org/jira/browse/PROTON-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538399#comment-16538399
]
Robbie Gemmell commented on PROTON-1890:
Without more detail this report seems like it could be invalid.
{quote}
The only change i made to this example is to send messages continuously inside
the send() method.
{quote}
Depending on what you specifically mean here, this might be improper usage if
it ties up the container thread. I'd suggest you attach the diff showing what
you actually did, so someone familiar with the C++ bits (not me) might be able
to better reason about what you've done.
{quote}
The other end is detecting the error as it is sending the empty frames and no
response is heard.
{quote}
Any empty/heartbeat frames sent are entirely independent in each direction,
based on the advertised needs of the other peer. No 'response' is required or
expected.
{quote}
The proton is not sending the heartbeat messages (empty frames) as the sender
is busy in sending the data frames. Is it not necessary to send empty frames
even if the data frames are sent?
{quote}
Any empty/heartbeat frames are only sent due to the absence of other traffic.
If actual traffic is occurring, no heartbeat frames will need to be sent. As
above though, I think you could perhaps be misusing the container thread so it
cant actually do things like send heartbeats anyway.
(This all assumes the other side advertised an idle-timeout in their Open frame
to indicate they require real traffic or heartbeats at a certain frequency. If
they didn't, none will be sent as no need was indicated).
> [c++] implement idle_timeout and heartbeats
> ---
>
> Key: PROTON-1890
> URL: https://issues.apache.org/jira/browse/PROTON-1890
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.16.0
>Reporter: Praveen Bodke
>Priority: Major
>
> This is similar issue reported in PROTON-1782 for ruby.
> We are facing this issue in cpp binding and i am able to reproduce the issue
> with scheduled_send_03.cpp example. The test scenario is to drop all the
> packets from both the interfaces after the successful connection. The only
> change i made to this example is to send messages continuously inside the
> send() method. The other end is detecting the error as it is sending the
> empty frames and no response is heard.
> The proton is not sending the heartbeat messages (empty frames) as the sender
> is busy in sending the data frames. Is it not necessary to send empty frames
> even if the data frames are sent?
>
--
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-1890) [c++] implement idle_timeout and heartbeats
Praveen Bodke created PROTON-1890: - Summary: [c++] implement idle_timeout and heartbeats Key: PROTON-1890 URL: https://issues.apache.org/jira/browse/PROTON-1890 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.16.0 Reporter: Praveen Bodke This is similar issue reported in PROTON-1782 for ruby. We are facing this issue in cpp binding and i am able to reproduce the issue with scheduled_send_03.cpp example. The test scenario is to drop all the packets from both the interfaces after the successful connection. The only change i made to this example is to send messages continuously inside the send() method. The other end is detecting the error as it is sending the empty frames and no response is heard. The proton is not sending the heartbeat messages (empty frames) as the sender is busy in sending the data frames. Is it not necessary to send empty frames even if the data frames are sent? -- 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
