Re: JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
On 6 December 2016 at 01:29, Keith W wrote: > Hi all, > > I'm looking at some fails reported by the Java System Testsuite when > run against the Qpid JMS Client. > > One failing group is related to QueueBrowsers, for example > QueueBrowserAutoAckTest#testBrowsingWithSelector. > > The test assumes that each invocation of QueueBrowser#getEnumeration() > produce a *distinct* browser which independently sees all the > (matching) messages on the queue. This was true for the legacy 0-x > Qpid JMS client (each call to getEnumeration creates a server side > queue browser) but not so for the Qpid JMS Client. The following code > behaves differently. > > QueueBrowser browser = _clientSession.createBrowser(_queue); > final Enumeration enumeration1 = browser.getEnumeration(); > final Enumeration enumeration2 = browser.getEnumeration(); > assertNotSame(enumeration1, enumeration2) > > The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me. > > "The browse methods return a java.util.Enumeration that is used to > scan the queue’s messages. It may be an enumeration of the entire > content of a queue, or it may contain only the messages matching a > message selector." > > However, from a quick look at the JMS RI, it looks like the Qpid JMS > Client follows the single enumeration approach. > > I think the legacy client has wrong behaviour and the test wrong. > Any comments? > > cheers Keith > Yes - it sounds to me that the test is wrong... it should instead create a new browser for each time it wants to browse the queue, rather than relying on getEnumeration() to requery on each invocation. -- Rob > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
JMS - Behaviour of multiple invocations of QueueBrowser#getEnumeration
Hi all, I'm looking at some fails reported by the Java System Testsuite when run against the Qpid JMS Client. One failing group is related to QueueBrowsers, for example QueueBrowserAutoAckTest#testBrowsingWithSelector. The test assumes that each invocation of QueueBrowser#getEnumeration() produce a *distinct* browser which independently sees all the (matching) messages on the queue. This was true for the legacy 0-x Qpid JMS client (each call to getEnumeration creates a server side queue browser) but not so for the Qpid JMS Client. The following code behaves differently. QueueBrowser browser = _clientSession.createBrowser(_queue); final Enumeration enumeration1 = browser.getEnumeration(); final Enumeration enumeration2 = browser.getEnumeration(); assertNotSame(enumeration1, enumeration2) The JMS 1.2 (and JMS 2.0) don't seem tremendously clear to me. "The browse methods return a java.util.Enumeration that is used to scan the queue’s messages. It may be an enumeration of the entire content of a queue, or it may contain only the messages matching a message selector." However, from a quick look at the JMS RI, it looks like the Qpid JMS Client follows the single enumeration approach. I think the legacy client has wrong behaviour and the test wrong. Any comments? cheers Keith - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7574) Make management libraries Python 3 compatible
[ https://issues.apache.org/jira/browse/QPID-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7574: -- Attachment: qpid-cpp-management-python3.diff > Make management libraries Python 3 compatible > - > > Key: QPID-7574 > URL: https://issues.apache.org/jira/browse/QPID-7574 > Project: Qpid > Issue Type: Improvement > Components: Qpid Managment Framework >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.37.0 > > Attachments: qpid-cpp-management-python3.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7574) Make management libraries Python 3 compatible
[ https://issues.apache.org/jira/browse/QPID-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7574: -- Labels: patch (was: ) > Make management libraries Python 3 compatible > - > > Key: QPID-7574 > URL: https://issues.apache.org/jira/browse/QPID-7574 > Project: Qpid > Issue Type: Improvement > Components: Qpid Managment Framework >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross > Labels: patch > Fix For: qpid-cpp-1.37.0 > > Attachments: qpid-cpp-management-python3.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7574) Make management libraries Python 3 compatible
[ https://issues.apache.org/jira/browse/QPID-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-7574: -- Fix Version/s: (was: qpid-cpp-1.36.0) qpid-cpp-1.37.0 > Make management libraries Python 3 compatible > - > > Key: QPID-7574 > URL: https://issues.apache.org/jira/browse/QPID-7574 > Project: Qpid > Issue Type: Improvement > Components: Qpid Managment Framework >Affects Versions: qpid-cpp-1.35.0 >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: qpid-cpp-1.37.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7574) Make management libraries Python 3 compatible
Justin Ross created QPID-7574: - Summary: Make management libraries Python 3 compatible Key: QPID-7574 URL: https://issues.apache.org/jira/browse/QPID-7574 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Affects Versions: qpid-cpp-1.35.0 Reporter: Justin Ross Assignee: Justin Ross Fix For: qpid-cpp-1.36.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723378#comment-15723378 ] ASF subversion and git services commented on QPID-7546: --- Commit 1772807 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1772807 ] QPID-7546 : implement transaction counting statistics > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-586) Dispatch crash on running c sender and receiver
[
https://issues.apache.org/jira/browse/DISPATCH-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-586.
Resolution: Fixed
This issue looks very similar to the proton object lifecycle management issue
addressed by DISPATCH-583 which has been fixed.
Mark, can you please try with the latest dispatch master branch build?
> Dispatch crash on running c sender and receiver
> ---
>
> Key: DISPATCH-586
> URL: https://issues.apache.org/jira/browse/DISPATCH-586
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: build.sh, receiver.c, sender.c
>
>
> Sender and receiver c classes are attached.
> Start the router (dispatch-master and proton-master)
> Start the senders and receivers like this
> ./receiver -a 172.123.10.11:1 -c 36000 -q -s test6_1 &
> ./sender -a 172.123.10.11:1 -c 36000 -q -u -t test6_1
> The router crashes with the following backtrace
> {noformat}
> (gdb) bt
> #0 0x0070 in ?? ()
> #1 0x7f31bba40de0 in pn_class_free (clazz=0x7f31a0058f80,
> object=0x7f31a0025680) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/object/object.c:117
> #2 0x7f31bba40fcf in pn_free (object=) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/object/object.c:263
> #3 0x7f31bba4bcf2 in pni_free_children (children=0x7f31a0017180,
> freed=0x7f31a0017040) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/engine/engine.c:456
> #4 0x7f31bba4c509 in pn_session_finalize (object=0x7f31a0038fa0) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/engine/engine.c:926
> #5 0x7f31bba40d98 in pn_class_decref (clazz=0x7f31bbc78500 ,
> object=0x7f31a0038fa0) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/object/object.c:95
> #6 0x7f31bba4f140 in pn_event_finalize (event=0x7f31a0016b40) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/events/event.c:212
> #7 pn_event_finalize_cast (object=0x7f31a0016b40) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/events/event.c:257
> #8 0x7f31bba40d98 in pn_class_decref (clazz=0x7f31bbc78600 ,
> clazz@entry=0x7f31bbc77f00 , object=0x7f31a0016b40)
> at /usr/src/debug/qpid-proton-0.14.0/proton-c/src/object/object.c:95
> #9 0x7f31bba40faf in pn_decref (object=) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/object/object.c:253
> #10 0x7f31bba4f402 in pn_collector_pop
> (collector=collector@entry=0x7f31a0019340) at
> /usr/src/debug/qpid-proton-0.14.0/proton-c/src/events/event.c:189
> #11 0x7f31bbcbc82e in process_connector (cxtr=,
> qd_server=0x15f7bb0) at /usr/src/debug/qpid-dispatch-0.7.0/src/server.c:856
> #12 thread_run (arg=) at
> /usr/src/debug/qpid-dispatch-0.7.0/src/server.c:1080
> #13 0x7f31bb818dc5 in start_thread () from /lib64/libpthread.so.0
> #14 0x7f31bad741cd in clone () from /lib64/libc.so.6
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-583. Resolution: Fixed > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723260#comment-15723260 ] ASF subversion and git services commented on DISPATCH-583: -- Commit d918b7a2c64b394bd6ea91c9e3cc5eddb0c2319a in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d918b7a ] DISPATCH-583 - Fixed lifecycle management of proton links and sessions. These are now freed after the collector is done with all the events (cherry picked from commit 5737eb45df2ba94de7dfc7817792e1afe18df73b) > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-59) Create a HOWTO file on writing a new shim
[ https://issues.apache.org/jira/browse/QPIDIT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-59: --- Summary: Create a HOWTO file on writing a new shim (was: Add a Shim HOWTO) > Create a HOWTO file on writing a new shim > - > > Key: QPIDIT-59 > URL: https://issues.apache.org/jira/browse/QPIDIT-59 > Project: Apache QPID IT > Issue Type: Task > Components: Documentation >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Create a file which lays out how to write a shim. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDIT-61) Condense common code from the Python tests into a test module.
[ https://issues.apache.org/jira/browse/QPIDIT-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned QPIDIT-61: -- Assignee: Kim van der Riet > Condense common code from the Python tests into a test module. > -- > > Key: QPIDIT-61 > URL: https://issues.apache.org/jira/browse/QPIDIT-61 > Project: Apache QPID IT > Issue Type: Task >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Each test was written independently of the others. While this is a quick way > to start, it has not lead to a lot of duplicated code and common patterns. It > would help maintenance and readability of the code if the common bits were > placed into a test library. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-61) Condense common code from the Python tests into a test module.
Kim van der Riet created QPIDIT-61: -- Summary: Condense common code from the Python tests into a test module. Key: QPIDIT-61 URL: https://issues.apache.org/jira/browse/QPIDIT-61 Project: Apache QPID IT Issue Type: Task Reporter: Kim van der Riet Each test was written independently of the others. While this is a quick way to start, it has not lead to a lot of duplicated code and common patterns. It would help maintenance and readability of the code if the common bits were placed into a test library. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-60) Create a HOWTO file on writing a new test
Kim van der Riet created QPIDIT-60: -- Summary: Create a HOWTO file on writing a new test Key: QPIDIT-60 URL: https://issues.apache.org/jira/browse/QPIDIT-60 Project: Apache QPID IT Issue Type: Task Components: Documentation Reporter: Kim van der Riet Assignee: Kim van der Riet Write a HOWTO file which lays out the steps in writing a new test. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-59) Add a Shim HOWTO
[ https://issues.apache.org/jira/browse/QPIDIT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-59: --- Component/s: Documentation > Add a Shim HOWTO > > > Key: QPIDIT-59 > URL: https://issues.apache.org/jira/browse/QPIDIT-59 > Project: Apache QPID IT > Issue Type: Task > Components: Documentation >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Create a file which lays out how to write a shim. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-59) Add a Shim HOWTO
Kim van der Riet created QPIDIT-59: -- Summary: Add a Shim HOWTO Key: QPIDIT-59 URL: https://issues.apache.org/jira/browse/QPIDIT-59 Project: Apache QPID IT Issue Type: Task Reporter: Kim van der Riet Assignee: Kim van der Riet Create a file which lays out how to write a shim. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDIT-57) Cmake installer should check for presence of Node.js and Rhea client
[ https://issues.apache.org/jira/browse/QPIDIT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722962#comment-15722962 ] Kim van der Riet commented on QPIDIT-57: The installer should check the shims directory to find the necessary information for build dependencies for each shim and include the shim if these dependencies are found. This could take the form of an included cmake fragment or some other metadata that cmake can easily consume. > Cmake installer should check for presence of Node.js and Rhea client > > > Key: QPIDIT-57 > URL: https://issues.apache.org/jira/browse/QPIDIT-57 > Project: Apache QPID IT > Issue Type: Bug > Components: Installation >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Currently the presence of both node.js and Rhea are assumed. The cmake > installer should check for the presence of node.js, and if that is present, > then for Rhea itself. If found, then the Rhea tests should be enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-58) Add auto-detection of shims
Kim van der Riet created QPIDIT-58: -- Summary: Add auto-detection of shims Key: QPIDIT-58 URL: https://issues.apache.org/jira/browse/QPIDIT-58 Project: Apache QPID IT Issue Type: Task Reporter: Kim van der Riet Assignee: Kim van der Riet Currently the shims are included by hard-coding paths into the test files. A small change in directory structure will enable the shims to be auto-detected at run-time and included if present. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7573) [Java Broker] Document new operational logging for configured object lifecycle and management operations
[
https://issues.apache.org/jira/browse/QPID-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorenz Quack updated QPID-7573:
---
Component/s: Java Broker
Documentation
> [Java Broker] Document new operational logging for configured object
> lifecycle and management operations
>
>
> Key: QPID-7573
> URL: https://issues.apache.org/jira/browse/QPID-7573
> Project: Qpid
> Issue Type: Improvement
> Components: Documentation, Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2,
> qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1,
> qpid-java-6.2
>Reporter: Alex Rudyy
>
> Operational logging for life cycle and management operations for
> Authentication Providers, Keystores, Trustores, ACL Providers, etc is missed
> in Broker documentation.
> An example of missed operational logging:
> {noformat}
> CREATE = ATH-1001 : Create "{0}"
> OPEN = ATH-1002 : Open
> CLOSE = ATH-1003 : Close
> DELETE = ATH-1004 : Delete "{0}"
> OPERATION = ATH-1005 : Operation : {0}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #119: DISPATCH-583 - Fixed lifecycle management o...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/119 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7371) Log failed login attempts
[ https://issues.apache.org/jira/browse/QPID-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722694#comment-15722694 ] ASF subversion and git services commented on QPID-7371: --- Commit 1772712 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1772712 ] QPID-7371: [Java Broker] Add operational logging ATH-1010 for failed login attempts > Log failed login attempts > - > > Key: QPID-7371 > URL: https://issues.apache.org/jira/browse/QPID-7371 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.2 > > > The Broker for Java should log unsuccessful login attempts for both > management and messaging using an operational log message. > The message should include the end point generating the request and the user > id provided by the user, if one is available. For authentication mechanisms > that are token based (such as OAUTH2) there will be no user id. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722695#comment-15722695 ] ASF GitHub Bot commented on DISPATCH-583: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/119 > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-583) Random segmentation fault
[ https://issues.apache.org/jira/browse/DISPATCH-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722686#comment-15722686 ] ASF GitHub Bot commented on DISPATCH-583: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/119#discussion_r90902246 --- Diff: include/qpid/dispatch/server.h --- @@ -477,6 +477,15 @@ typedef int (*qd_pn_event_handler_cb_t)(void *handler_context, void* conn_contex /** + * Post event process handler + * Invoke only after all proton events have been popped from the collector. + * + * @param conn The connection for which all proton events have been popped. + */ +typedef void (*qd_pn_event_complete_cb_t)(qd_connection_t *conn); --- End diff -- All of the callback's need to include the context argument (even it you don't use it in your handler). > Random segmentation fault > - > > Key: DISPATCH-583 > URL: https://issues.apache.org/jira/browse/DISPATCH-583 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd.conf > > > Hello, > working with the following project : > https://github.com/EnMasseProject/mqtt-frontend > using the router, I have random "segmentation fault" errors when the > SubscribeTest is executed. It happens running the test 3-4 times ... or 20 > times ... totally random. > You can reproduce it, cloning the above repo and running : > mvn -Dtest=SubscribeTest test > I used the route built from the repo source code (about 2 weeks ago) but > applying the patch for message annotations on that. > I got the backtrace of one of the crash : > #0 0x000f00747369 in ?? () > #1 0x7f0eceddcf69 in pn_class_equals (clazz=, > a=, b=b@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:169 > #2 0x7f0eceddd466 in pn_list_index (list=list@entry=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:88 > #3 0x7f0eceddd559 in pn_list_remove (list=0x7f0eb802c0c0, > value=value@entry=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/object/list.c:99 > #4 0x7f0ecede82ea in pn_link_finalize (object=0x7f0eb800bd90) at > /qpid-proton-0.15.0/proton-c/src/engine/engine.c:1129 > #5 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013480 , > object=0x7f0eb800bd90) at /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #6 0x7f0ecedeadb0 in pn_event_finalize (event=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:212 > #7 pn_event_finalize_cast (object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:257 > #8 0x7f0eceddce19 in pn_class_decref (clazz=0x7f0ecf013600 , > clazz@entry=0x7f0ecf012f00 , object=0x7f0eb802a580) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:95 > #9 0x7f0eceddd02f in pn_decref (object=) at > /qpid-proton-0.15.0/proton-c/src/object/object.c:253 > #10 0x7f0ecedeb0a2 in pn_collector_pop > (collector=collector@entry=0x7f0eb8036450) at > /qpid-proton-0.15.0/proton-c/src/events/event.c:189 > #11 0x7f0ecf055d43 in process_connector (cxtr=0x7f0eb8002f90, > qd_server=0x2517e70) at /qpid-dispatch/src/server.c:851 > #12 thread_run (arg=) at /qpid-dispatch/src/server.c:1075 > #13 0x7f0ecebb45ba in start_thread () from /lib64/libpthread.so.0 > #14 0x7f0ece1037cd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #119: DISPATCH-583 - Fixed lifecycle management o...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/119#discussion_r90902246 --- Diff: include/qpid/dispatch/server.h --- @@ -477,6 +477,15 @@ typedef int (*qd_pn_event_handler_cb_t)(void *handler_context, void* conn_contex /** + * Post event process handler + * Invoke only after all proton events have been popped from the collector. + * + * @param conn The connection for which all proton events have been popped. + */ +typedef void (*qd_pn_event_complete_cb_t)(qd_connection_t *conn); --- End diff -- All of the callback's need to include the context argument (even it you don't use it in your handler). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7573) [Java Broker] Document new operational logging for configured object lifecycle and management operations
Alex Rudyy created QPID-7573:
Summary: [Java Broker] Document new operational logging for
configured object lifecycle and management operations
Key: QPID-7573
URL: https://issues.apache.org/jira/browse/QPID-7573
Project: Qpid
Issue Type: Improvement
Affects Versions: qpid-java-6.1, qpid-java-6.0.5, qpid-java-6.0.4,
qpid-java-6.0.3, qpid-java-6.0.2, qpid-java-6.0.1, qpid-java-6.0, qpid-java-6.2
Reporter: Alex Rudyy
Operational logging for life cycle and management operations for Authentication
Providers, Keystores, Trustores, ACL Providers, etc is missed in Broker
documentation.
An example of missed operational logging:
{noformat}
CREATE = ATH-1001 : Create "{0}"
OPEN = ATH-1002 : Open
CLOSE = ATH-1003 : Close
DELETE = ATH-1004 : Delete "{0}"
OPERATION = ATH-1005 : Operation : {0}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-589) Missing links on topology page
[ https://issues.apache.org/jira/browse/DISPATCH-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-589. --- Resolution: Fixed Fix Version/s: 0.8.0 > Missing links on topology page > -- > > Key: DISPATCH-589 > URL: https://issues.apache.org/jira/browse/DISPATCH-589 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 0.8.0 > > > Some links between nodes are missing on the topology graph. This appears to > be intermittent. > It looks like the connection names are not unique across the router network. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-589) Missing links on topology page
[ https://issues.apache.org/jira/browse/DISPATCH-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722388#comment-15722388 ] ASF subversion and git services commented on DISPATCH-589: -- Commit ba4d5c29df212e450d4bde4858e1069efa5b0742 in qpid-dispatch's branch refs/heads/master from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ba4d5c2 ] DISPATCH-589 Don't use connection.name as a unique link identifier > Missing links on topology page > -- > > Key: DISPATCH-589 > URL: https://issues.apache.org/jira/browse/DISPATCH-589 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Reporter: Ernest Allen >Assignee: Ernest Allen > > Some links between nodes are missing on the topology graph. This appears to > be intermittent. > It looks like the connection names are not unique across the router network. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-589) Missing links on topology page
Ernest Allen created DISPATCH-589: - Summary: Missing links on topology page Key: DISPATCH-589 URL: https://issues.apache.org/jira/browse/DISPATCH-589 Project: Qpid Dispatch Issue Type: Bug Components: Console Reporter: Ernest Allen Assignee: Ernest Allen Some links between nodes are missing on the topology graph. This appears to be intermittent. It looks like the connection names are not unique across the router network. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15722272#comment-15722272 ] ASF subversion and git services commented on QPID-7546: --- Commit 1772666 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1772666 ] QPID-7546: [Java Broker] Prevent messages without header section causing a NPE within Message_1_0#getExpiration > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
I actually quite like this approach --Rob On 5 December 2016 at 12:40, Robbie Gemmell wrote: > On 5 December 2016 at 12:39, Robbie Gemmell > wrote: > > On 3 December 2016 at 18:45, Keith W wrote: > >> For now, given you are presumably talking about the Qpid Java > broker > >> herecan you simply try opening the link and have it fail if not > >> supported? I'd guess if you try to attach to the management > address, > >> since it doesnt automatically create entities by default it would > have > >> to refuse the link instead? > >> > >> Absolutely - this was actually my first thought. My difficultly is > >> that the tests need to work with the older protocols AMQP-0-8..0-10 > >> and older releases so I can't rely on a creating a producer against > >> $management explicitly failing. This lead me to look at whether AMQP > >> Management could be somehow detected up front from the Connection > >> object itself as a simpler way. There are workarounds I can take. > >> > >> I can't help but feel though that there will be other occasions when > >> the application might wish to know about the peer's > >> offered-capabilities and possibly the peer's open properties too, for > >> instance, for bug avoidance. I notice that Websphere MQ's > >> JmsConnectionMetaData [1] implements a java,util.Map in addition to > >> javax.jms.ConnectionMetaData. I don't actually know how they use it > >> but it strikes me it might offer a reasonablly unobtrusive way to > >> expose capabilities (as one map entry "capabilities" => List) and > >> properties (as another "properties" => Map). > >> > >> [1] http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/ > com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/ > JmsConnectionMetaData.html > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > > > > Yes, it looks like essentially every object in their impl does the same: > > http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0. > 0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/ > client/jms/JmsPropertyContext.html > > (Note to self, don't accidentally press whatever the kb shortcut for send > is :P) > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
[jira] [Commented] (PROTON-1370) Don't leave detached links in active state
[ https://issues.apache.org/jira/browse/PROTON-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1570#comment-1570 ] Robbie Gemmell commented on PROTON-1370: proton-j looks to be inconsistent on this. If you locally detach a link its local state remains unchanged (so, ACTIVE), but when a detach frame arrives for a remotely trigged detach the remote state is changed to CLOSED. A DETACHED state might be nice, but would be a breaking change for many peoples usage (its also an Enum, so further breakage likely). I dont think there is a way to re-attach a given link object, only starting fresh one a new one. > Don't leave detached links in active state > -- > > Key: PROTON-1370 > URL: https://issues.apache.org/jira/browse/PROTON-1370 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Reporter: Justin Ross > Fix For: 0.17.0 > > > The alternative ATM is closed, which on balance seems like a better choice. > Links are likely to be recreated from scratch in practical resume scenarios. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
On 5 December 2016 at 12:39, Robbie Gemmell wrote: > On 3 December 2016 at 18:45, Keith W wrote: >> For now, given you are presumably talking about the Qpid Java broker >> herecan you simply try opening the link and have it fail if not >> supported? I'd guess if you try to attach to the management address, >> since it doesnt automatically create entities by default it would have >> to refuse the link instead? >> >> Absolutely - this was actually my first thought. My difficultly is >> that the tests need to work with the older protocols AMQP-0-8..0-10 >> and older releases so I can't rely on a creating a producer against >> $management explicitly failing. This lead me to look at whether AMQP >> Management could be somehow detected up front from the Connection >> object itself as a simpler way. There are workarounds I can take. >> >> I can't help but feel though that there will be other occasions when >> the application might wish to know about the peer's >> offered-capabilities and possibly the peer's open properties too, for >> instance, for bug avoidance. I notice that Websphere MQ's >> JmsConnectionMetaData [1] implements a java,util.Map in addition to >> javax.jms.ConnectionMetaData. I don't actually know how they use it >> but it strikes me it might offer a reasonablly unobtrusive way to >> expose capabilities (as one map entry "capabilities" => List) and >> properties (as another "properties" => Map). >> >> [1] >> http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/JmsConnectionMetaData.html >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > Yes, it looks like essentially every object in their impl does the same: http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/JmsPropertyContext.html (Note to self, don't accidentally press whatever the kb shortcut for send is :P) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
On 3 December 2016 at 18:45, Keith W wrote: >>> >> For now, given you are presumably talking about the Qpid Java broker >>> >> herecan you simply try opening the link and have it fail if not >>> >> supported? I'd guess if you try to attach to the management address, >>> >> since it doesnt automatically create entities by default it would have >>> >> to refuse the link instead? > > Absolutely - this was actually my first thought. My difficultly is > that the tests need to work with the older protocols AMQP-0-8..0-10 > and older releases so I can't rely on a creating a producer against > $management explicitly failing. This lead me to look at whether AMQP > Management could be somehow detected up front from the Connection > object itself as a simpler way. There are workarounds I can take. > > I can't help but feel though that there will be other occasions when > the application might wish to know about the peer's > offered-capabilities and possibly the peer's open properties too, for > instance, for bug avoidance. I notice that Websphere MQ's > JmsConnectionMetaData [1] implements a java,util.Map in addition to > javax.jms.ConnectionMetaData. I don't actually know how they use it > but it strikes me it might offer a reasonablly unobtrusive way to > expose capabilities (as one map entry "capabilities" => List) and > properties (as another "properties" => Map). > > [1] > http://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.javadoc.doc/WMQJMSClasses/com/ibm/msg/client/jms/JmsConnectionMetaData.html > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > Yes, it looks like essentially every object in their impl does the same: - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Detecting presence of AMQP-MANAGEMENT server capability from the Qpid JMS Client
On 2 December 2016 at 18:29, Rob Godfrey wrote: > On 2 December 2016 at 19:03, Robbie Gemmell > wrote: > >> On 2 December 2016 at 17:36, Rob Godfrey wrote: >> > On 2 December 2016 at 17:13, Robbie Gemmell >> > wrote: >> > >> >> Yes, there wont currently be a way to do this, thus far the >> >> capabilities have only ever been used for things the client itself >> >> acts upon. Also, for any extended behaviour present thus far we have >> >> only used e.g vendor properties and such like within the existing API, >> >> and have resisted adding additional APIs beyond those provided by JMS. >> >> I'm not sure there is a facility we could use here for such things >> >> though, one to think about. >> >> >> >> >> > The only way I can think to expose this is via defining a format for the >> > JMSProviderName in the ConnectionMetaData that serializes the offered >> > capabilities and server side defined connection properties in some way. >> If >> > this was standardised then one could parse the version string to find out >> > the necessary information. >> > >> >> At first thought it feels like that might be a stretch too far :) >> > > Yeah - I didn't say I *liked* the thought... but other than horribly > abusing JMSX properties in some way, that seemed like the only way to get > information about the connection in a "standardized" way. > > >> >> > As you point out this doesn't seem to be necessary for amqp management >> > (since the detection of $management" should be enough presuming you are >> not >> > talking to a service which auto-creates destinations... But other >> > properties/capabilities might affect how your application functions. >> > >> > Of much more interest to me (particularly in the use of AMQP management) >> is >> > the ability set properties on Destinations (through JNDI would suffice, >> > though also having a String format for Sessin.createQueue would be >> > better). In particular being able to control the local source/target >> > address (and possibly in future the link name). The "direct" request >> > response model requires that the client creates an receiving link with a >> > given target address (and a source address of $management)... the >> reply-to >> > on messages sent to $management is then that target address on the >> > consumer. Currently there is no way to achieve this with the JMS client >> :-( >> > >> > -- Rob >> > >> >> Indeed, we currently have no system in place for per-destination >> manipulations of the AMQP link details like that, only some bits >> around prefetch/settlement/redelivery etc. >> >> > Yeah - as far as implementing some upcoming AMQP standards, I think that > will become an issue... not sure where the best forum to discuss it is > though.. > > -- Rob > > I think these would be discussed here at Qpid as implementation details before qualifying for discussion in other forums. >> > >> >> For now, given you are presumably talking about the Qpid Java broker >> >> herecan you simply try opening the link and have it fail if not >> >> supported? I'd guess if you try to attach to the management address, >> >> since it doesnt automatically create entities by default it would have >> >> to refuse the link instead? >> >> >> >> Robbie >> >> >> >> On 2 December 2016 at 15:39, Keith W wrote: >> >> > Hi, >> >> > >> >> > In QPID-7556, we intend to advertise the Qpid Broker for Java AMQP >> >> > Management ability with an AMQP 1.0 open performative >> >> > offered-capability [1] of 'AMQP-MANAGEMENT'. >> >> > >> >> > As a user of the Qpid JMS Client, how do I detect that the server >> >> > offers this capability? >> >> > >> >> > At the moment, from what I see of the public API, I don't have a way >> >> > to check for an arbitrary server offered-capabilities. >> >> > AmqpConnectionProperties cherry picks the capabilities that are >> >> > currently known/interesting but there is no way to check for an >> >> > arbitrary one. >> >> > >> >> > AmqpConnectionProperties could be simply changed to detect the >> >> > AMQP-MANAGEMENT (isAmpqManagementSupported()), or it could offer an >> >> > API to the user could enquire on a particular capability. >> >> > >> >> > My use case is test automation. I need check whether I can use AMQP >> >> > Management so I may fallback back to an older management technique, >> >> > but, I believe the feature would have general utility. >> >> > >> >> > cheers Keith. >> >> > >> >> > >> >> > [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core- >> >> transport-v1.0-os.html#type-open >> >> > >> >> > - >> >> > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> >> > For additional commands, e-mail: dev-h...@qpid.apache.org >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> >> For additional commands, e-mail: dev-h...@qpid.apache.org >> >> >> >> >> >> -
