[jira] [Commented] (DISPATCH-577) Server logs show unexpected POLLNVAL errors.
[ https://issues.apache.org/jira/browse/DISPATCH-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765258#comment-15765258 ] ASF subversion and git services commented on DISPATCH-577: -- Commit b325f6bea366d029bf6366a0aa8ad69f82ce2b17 in qpid-dispatch's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=b325f6b ] DISPATCH-577: Fix latency regression introduced by commit 6e6929c That commit introduced sporadic high latency messages, caused by insufficient polling. This fixes the problem and is still fairly conservative: it checks the need to re-poll before read/write processing rather than after, which could result in at most one extra poll when the transport becomes un-readable/un-writable. > Server logs show unexpected POLLNVAL errors. > > > Key: DISPATCH-577 > URL: https://issues.apache.org/jira/browse/DISPATCH-577 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Fix For: 0.8.0 > > > Logs show "unexpected poll event 0x0020" trace messages indicating POLLNVAL > returned in poll events. The router is not detecting connection closure > immediately and is trying to poll on closed sockets. -- 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] (QPIDJMS-207) Implement the JMS 2.0 API
[ https://issues.apache.org/jira/browse/QPIDJMS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765148#comment-15765148 ] ASF subversion and git services commented on QPIDJMS-207: - Commit ff7076ab5ec10dc040af336bbb7a25b3b8cae554 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=ff7076a ] QPIDJMS-207 Fix some cases where QueueSession did not throw proper error The QueueSession needs to throw IllegalStateException for the new 2.0 create shared consumer methods > Implement the JMS 2.0 API > - > > Key: QPIDJMS-207 > URL: https://issues.apache.org/jira/browse/QPIDJMS-207 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Affects Versions: 0.11.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.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] (PROTON-1376) [C, windows] Release 0.16 build fail - src/protocol.h clobbered
[ https://issues.apache.org/jira/browse/PROTON-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764948#comment-15764948 ] ASF subversion and git services commented on PROTON-1376: - Commit 9377d859b5096dfeb3e00c935610784ecbc3c04f in qpid-proton's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9377d85 ] PROTON-1376: Serialize re-construction of generated files for Windows Windows builds wrongly regenerate files for libraries qpid-proton and qpid-proton-core. Regeneration creates file churn that sometimes breaks builds. This patch introduces a phony dependency so that the generated file reconstruction does not cause a problem. > [C, windows] Release 0.16 build fail - src/protocol.h clobbered > --- > > Key: PROTON-1376 > URL: https://issues.apache.org/jira/browse/PROTON-1376 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 > Environment: Visual Studio 2012, x64 >Reporter: Chuck Rolke > > Target generated_c_files builds the src/protocol.h and src/encodings.h files. > Then projects qpid-proton and qpid-proton-core depend on generated_c_files. > It appears that generated_c_files as a dependency does not respect existing > src/protocol.h and src/encodings.h files and generates them three times in > total. > On a four-core build system the files are created three times but well before > other build threads try to use them. On other systems the timing is such that > a compilation of codec.c needs protocol.h but it is erased by the third file > creation. > {noformat} > 2>-- Build started: Project: generated_c_files, Configuration: Debug x64 > -- > 2>Build started 12/12/2016 4:49:28 PM. > 2>CustomBuild: > 2> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 2> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 2> Generating src/protocol.h > 2> Generating src/encodings.h > 2> > 2>Build succeeded. > 3>-- Build started: Project: qpid-proton, Configuration: Debug x64 -- > 4>-- Build started: Project: qpid-proton-core, Configuration: Debug x64 > -- > 3> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 3> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 3> Generating src/encodings.h > 3> Generating src/protocol.h > 3>ClCompile: > 3> object.c > 3> list.c > 3> map.c > 3> string.c > 3> iterator.c > 4>Build started 12/12/2016 4:49:29 PM. > 3> record.c > 3> log.c > 3> util.c > 3> error.c > 3> buffer.c > 4>CustomBuild: > 4> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 3> types.c > 4> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 4> Generating src/encodings.h > 3> framing.c > 3> codec.c > 4> Generating src/protocol.h > 3>..\..\proton-c\src\core\codec.c(33): fatal error C1083: Cannot open include > file: 'protocol.h': No such file or directory > {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] [Commented] (QPID-7592) [AMQP1.0] leak from Session_1_0#_outgoingUnsettled for long lived JMS auto-ack consuming session.
[ https://issues.apache.org/jira/browse/QPID-7592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764937#comment-15764937 ] ASF subversion and git services commented on QPID-7592: --- Commit 1775336 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1775336 ] QPID-7592: [Java Broker] Remove settled entries from the outgoing unsettled map. Also removed dead code from ReceivingLinkEndpoint > [AMQP1.0] leak from Session_1_0#_outgoingUnsettled for long lived JMS > auto-ack consuming session. > - > > Key: QPID-7592 > URL: https://issues.apache.org/jira/browse/QPID-7592 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > > Running the Qpid Broker inside a profiler I see a leakage of Delivery objects > for a long lived AMQP 1.0 consuming session (using JMS session auto-ack). > The leak is originating from Session_1_0#_outgoingUnsettled. -- 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-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[ https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764932#comment-15764932 ] ASF subversion and git services commented on QPID-7593: --- Commit 1775335 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1775335 ] QPID-7593: [Java Broker] Prevent a singleton removed QueueConsumerNode at the tail of the list holding otherewise unused objects (consumer and all) in memory. > Abnormally ending an AMQP1.0 connection with consumer leaks the connection, > session and objects related to the consumer > --- > > Key: QPID-7593 > URL: https://issues.apache.org/jira/browse/QPID-7593 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-7.0.0 >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > Attachments: Screen Shot 2016-12-20 at 08.16.37.png > > > If I run the following code, jvisualvm shows that the object that underlies > the AMQP1.0 Connection, Session and Consumer are leaked. > The GC root is the QueueConsumerNodeList associated with the > Queue/QueueConsumerManager. The node the tail and is in the deleted state > and will be eventually scavenged (once new consumers join the queue). This > is common with the other protocols and I believe this aspect is as designed. > However, I think the fact that the Connections/Session/ConsumerTarget remains > referenced is a defect. It shows us that the ConsumerTarget_1.0 > (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not > being closed. Other protocols don't show this same defect. > {code:java} > Properties properties = new Properties(); > properties.load(resourceAsStream); > Context context = new InitialContext(properties); > ConnectionFactory connectionFactory = (ConnectionFactory) > context.lookup("qpidConnectionfactory"); > Connection connection = connectionFactory.createConnection(); > connection.start(); > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > Destination destination = (Destination) context.lookup("myqueue"); > MessageConsumer messageConsumer = > session.createConsumer(destination); > if (true) System.exit(1); > {code} > I expect this defect does not appear in release versions of the product. -- 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: AMQP 1.0/Python - Question re. encoding of maps and lists : failing qpid_tests.broker_1_0.translation.TranslationTests.test_translate* against Java Broker
On 20/12/16 18:20, Keith W wrote: On 20 December 2016 at 10:14, Gordon Sim wrote: On 19/12/16 15:57, Keith W wrote: By debugging the Java Broker's translation module, I can see that the AMQP 1.0 publishing end is sending the map encoded within a DataSection. This surprises me - I was expecting the application-data to be an amqp-value containing the map. The Java Broker doesn't know how to translate this for the 0-10 and hence the test fails. Why does Qpid Python / swigged client encode the map this way? The swig layer has some special logic for managing message content that predates 1.0 and works the same way for both 1.0 and 0-10. The content-type is used to indicate the type in both cases. 1.0 required some changes to the messaging API (set-/get- ContentObject()) to allow value sections to be used. I suspect the swig binding was just never changed to use those changes. Thanks Gordon for the swift reply. That all makes sense and I was able to find the code concerned. It matches your suspicions. Do you know if the bindings are due to have their AMQP 1.0 support refreshed? I don't know of any such plan. The swigged client is really only used for tests at present. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764891#comment-15764891 ] ASF subversion and git services commented on DISPATCH-103: -- Commit fcdaf22a826de23f73cb991291c46e2cb8ca1886 in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=fcdaf22 ] DISPATCH-103 - fixed the http-none stub to properly build when websockets is not built. > Websocket Listeners > --- > > Key: DISPATCH-103 > URL: https://issues.apache.org/jira/browse/DISPATCH-103 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Alan Conway > > Add an option in configured listeners to use websockets encapsulation. This > will allow AMQP clients inside web browsers to directly connect to the > message bus. -- 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-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764875#comment-15764875 ] ASF subversion and git services commented on QPID-7595: --- Commit dd8e5b350b6d89263754b8bf781376d78d150490 in qpid-cpp's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=dd8e5b3 ] QPID-7595: Raise minimum cmake version for windows > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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: AMQP 1.0/Python - Question re. encoding of maps and lists : failing qpid_tests.broker_1_0.translation.TranslationTests.test_translate* against Java Broker
On 20 December 2016 at 10:14, Gordon Sim wrote: > On 19/12/16 15:57, Keith W wrote: >> >> By debugging the Java Broker's translation module, I can see that the >> AMQP 1.0 publishing end is sending the map encoded within a >> DataSection. This surprises me - I was expecting the application-data >> to be an amqp-value containing the map. The Java Broker doesn't know >> how to translate this for the 0-10 and hence the test fails. >> >> Why does Qpid Python / swigged client encode the map this way? > > > The swig layer has some special logic for managing message content that > predates 1.0 and works the same way for both 1.0 and 0-10. The content-type > is used to indicate the type in both cases. > > 1.0 required some changes to the messaging API (set-/get- ContentObject()) > to allow value sections to be used. I suspect the swig binding was just > never changed to use those changes. > Thanks Gordon for the swift reply. That all makes sense and I was able to find the code concerned. It matches your suspicions. Do you know if the bindings are due to have their AMQP 1.0 support refreshed? > > - > 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
[jira] [Commented] (QPID-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764854#comment-15764854 ] ASF subversion and git services commented on QPID-7595: --- Commit 3e1746577ad54cce2cecc4c6c83ca363482ea34a in qpid-cpp's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=3e17465 ] Revert "QPID-7595: Higher required cmake version for Windows" This reverts commit 70ef8c91a73fb8df1ce35bbdc643fd8011c7728e. > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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] [Comment Edited] (QPID-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764821#comment-15764821 ] Andrew Stitcher edited comment on QPID-7595 at 12/20/16 6:00 PM: - This fix is in the wrong place - it needs to be in the form of {noformat} if (NOT MSVC) { minimum is minimum for unix etc. } else { minimum for msvc } {noformat} not hidden away in some place that no one ever looks at. was (Author: astitcher): This fix is in the wrong place - it needs to be in the form of {{{ if (NOT MSVC) { minimum is minimum for unix etc. } else { minimum for msvc } }}} not hidden away in some place that no one ever looks at. > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764821#comment-15764821 ] Andrew Stitcher commented on QPID-7595: --- This fix is in the wrong place - it needs to be in the form of {{{ if (NOT MSVC) { minimum is minimum for unix etc. } else { minimum for msvc } }}} not hidden away in some place that no one ever looks at. > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764811#comment-15764811 ] ASF subversion and git services commented on QPID-7595: --- Commit 70ef8c91a73fb8df1ce35bbdc643fd8011c7728e in qpid-cpp's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-cpp.git;h=70ef8c9 ] QPID-7595: Higher required cmake version for Windows > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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-595) dispositions propagated after link detach on link route
[ https://issues.apache.org/jira/browse/DISPATCH-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-595. Resolution: Fixed > dispositions propagated after link detach on link route > --- > > Key: DISPATCH-595 > URL: https://issues.apache.org/jira/browse/DISPATCH-595 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > We have a subscriber that is link routed through router to a broker. If the > subscriber detaches immediately after accepting a message, the > acknowledgement of that message is only relaye dto the broker after the > relaying of the link detach. This means the message is left on the queue, > though the subscriber had explicitly accepted it. > {noformat} > Tue Dec 13 17:43:52 2016 AGENT (warning) routerId is deprecated, use id > instead > Tue Dec 13 17:43:52 2016 SERVER (warning) HTTP support is not available > Tue Dec 13 17:43:52 2016 SERVER (info) Container Name: Router.A > Tue Dec 13 17:43:52 2016 ROUTER (info) Router started in Standalone mode > Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) Router Core thread running. > 0/Router.A > Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription > M/$management > Tue Dec 13 17:43:52 2016 AGENT (info) Activating management agent on > $_management_internal > Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription > L/$management > Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription > L/$_management_internal > Tue Dec 13 17:43:52 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:5672 > proto=any, role=normal > Tue Dec 13 17:43:52 2016 CONN_MGR (info) Configured Connector: 0.0.0.0:5673 > proto=any, role=route-container > Tue Dec 13 17:43:52 2016 POLICY (info) Policy configured maxConnections: > 65535, policyDir: '', access rules enabled: 'false' > Tue Dec 13 17:43:52 2016 POLICY (info) Policy fallback defaultVhost is > defined: '$default' > Tue Dec 13 17:43:52 2016 SERVER (info) Operational, 4 Threads Running > [0x7f4764006fd0]: -> SASL > [0x7f4764006fd0]: <- SASL > [0x7f4764006fd0]:0 <- @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]] > [0x7f4764006fd0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, > initial-response=b"anonymous@localhost.localdomain"] > [0x7f4764006fd0]:0 <- @sasl-outcome(68) [code=0] > [0x7f4764006fd0]: -> AMQP > [0x7f4764006fd0]:0 -> @open(16) [container-id="Router.A", hostname="0.0.0.0", > max-frame-size=16384, channel-max=32767, idle-time-out=8000, > offered-capabilities=:"ANONYMOUS-RELAY", > properties={:product="qpid-dispatch-router", :version="0.8.0"}] > [0x7f4764006fd0]: <- AMQP > [0x7f4764006fd0]:0 <- @open(16) [container-id="0.0.0.0", > max-frame-size=4294967295, channel-max=65535, idle-time-out=3, > offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container", > :"DELAYED_DELIVERY"], properties={:product="apache-activemq-artemis", > :version="1.6.0-SNAPSHOT"}] > Tue Dec 13 17:43:53 2016 ROUTER_CORE (info) Link Route Activated > 'linkRoute/0' on connection redirect > Tue Dec 13 17:43:53 2016 ROUTER_CORE (info) Link Route Activated > 'linkRoute/1' on connection redirect > [0x7f4760006b70]: <- SASL > [0x7f4760006b70]: -> SASL > [0x7f4760006b70]:0 -> @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :"DIGEST-MD5", :PLAIN]] > [0x7f4760006b70]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS, > initial-response=b"anonymous@localhost.localdomain"] > [0x7f4760006b70]:0 -> @sasl-outcome(68) [code=0] > [0x7f4760006b70]: <- AMQP > [0x7f4760006b70]:0 <- @open(16) [container-id="myclient", > hostname="localhost", channel-max=32767] > [0x7f4760006b70]:0 <- @begin(17) [next-outgoing-id=0, > incoming-window=2147483647, outgoing-window=2147483647] > [0x7f4760006b70]:0 <- @attach(18) [name="mysubscription", handle=0, > role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) > [address="test", durable=2, expiry-policy=:never, timeout=0, dynamic=false, > capabilities=:topic], target=@target(41) [durable=0, timeout=0, > dynamic=false], initial-delivery-count=0] > [0x7f4760006b70]:0 <- @flow(19) [incoming-window=2147483647, > next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, > link-credit=10, drain=false] > [0x7f4760006b70]: -> AMQP > [0x7f4760006b70]:0 -> @open(16) [container-id="Router.A", > max-frame-size=16384, channel-max=32767, idle-time-out=8000, > offered-capabilities=:"ANONYMOUS-RELAY", > properties={:product="qpid-dispatch-router", :version="0.8.0"}] > [0x7f4760006b70]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0, > incoming-window=100, outgoing-window=2147483647] > [0x7f4764006fd0]:0 -> @begin(17) [next-outgoing-id=0, incoming-
[jira] [Commented] (DISPATCH-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764687#comment-15764687 ] ASF subversion and git services commented on DISPATCH-103: -- Commit 6ecbdba9c09a48960eb98fa95afca92b50eb2cb1 in qpid-dispatch's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=6ecbdba ] DISPATCH-103: Browser-friendly SSL test certificate authority Updated certificates test/ssl_certs to be more inter-operable with browswers: tested chrome, firefox. Authority cert uses RSA encryption and sets extension flags to identify itself as a root CA. Needed to test SSL for HTTP listeners. > Websocket Listeners > --- > > Key: DISPATCH-103 > URL: https://issues.apache.org/jira/browse/DISPATCH-103 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Alan Conway > > Add an option in configured listeners to use websockets encapsulation. This > will allow AMQP clients inside web browsers to directly connect to the > message bus. -- 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-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764689#comment-15764689 ] ASF subversion and git services commented on DISPATCH-103: -- Commit 9442bb0b231d008d604db565254d8d6014070516 in qpid-dispatch's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=9442bb0 ] DISPATCH-103: SSL support for HTTP/WebSocket listeners Re-worked HTTP implementation: stability, performance and maintainability improvements. - Use single lws_context per dispatch router. - Use separate lws_vhost per dispatch listener for independent SSL configuration. - Include libwebsocket messages in dispatch logs (module HTTP) - Move HTTP code out of driver and into server (not POSIX-specific) - Fix some memory and connection close bugs Apply dispatch SSL listener configuration to libwebsocket vhosts. Tests to verify HTTP access working correctly. The console does not yet work over HTTPs, there are some console issues to fix for that to work. > Websocket Listeners > --- > > Key: DISPATCH-103 > URL: https://issues.apache.org/jira/browse/DISPATCH-103 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Assignee: Alan Conway > > Add an option in configured listeners to use websockets encapsulation. This > will allow AMQP clients inside web browsers to directly connect to the > message bus. -- 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] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-598: -- Assignee: Ganesh Murthy > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Blocker > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- 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-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764667#comment-15764667 ] ASF GitHub Bot commented on DISPATCH-598: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/131 DISPATCH-598 - Added code to temporarily fix the crash that is being … …caused when PN_LINK_REMOTE_CLOSE and PN_SESSION_REMOTE_CLOSE events come in on the same collector loop. A more comprehensive fix is being worked on for the 0.9 release You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-598 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/131.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #131 commit 052b508d13724b09e3d33ba135aa0daee1f9ad68 Author: Ganesh Murthy Date: 2016-12-20T16:55:52Z DISPATCH-598 - Added code to temporarily fix the crash that is being caused when PN_LINK_REMOTE_CLOSE and PN_SESSION_REMOTE_CLOSE events come in on the same collector loop. A more comprehensive fix is being worked on for the 0.9 release > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars >Priority: Blocker > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- 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 #131: DISPATCH-598 - Added code to temporarily fi...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/131 DISPATCH-598 - Added code to temporarily fix the crash that is being ⦠â¦caused when PN_LINK_REMOTE_CLOSE and PN_SESSION_REMOTE_CLOSE events come in on the same collector loop. A more comprehensive fix is being worked on for the 0.9 release You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-598 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/131.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #131 commit 052b508d13724b09e3d33ba135aa0daee1f9ad68 Author: Ganesh Murthy Date: 2016-12-20T16:55:52Z DISPATCH-598 - Added code to temporarily fix the crash that is being caused when PN_LINK_REMOTE_CLOSE and PN_SESSION_REMOTE_CLOSE events come in on the same collector loop. A more comprehensive fix is being worked on for the 0.9 release --- 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] [Resolved] (QPID-7563) Implement Virtualhost centric REST interface
[ https://issues.apache.org/jira/browse/QPID-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7563. -- Resolution: Fixed The changes look good to me > Implement Virtualhost centric REST interface > > > Key: QPID-7563 > URL: https://issues.apache.org/jira/browse/QPID-7563 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > For use-cases where the Broker to hosts a shared service where different > applications are assigned to be different virtual hosts the broker should > offer the ability to manage these virtualhosts independently. It should > behave as if it were a chrooted prison. > AMQP Management already offers this ability. The HTTP management interface > should change to offer the same thing. > The REST API of a virtualhost will service the only virtualhost's subtree. > The formation of the service urls will reflect this structure. > {{/virtualhost}} will be analogous to {{/broker}} and will service the > virtualhost root. {{/queue/}} will serve all the queues defined on the > virtualhost, {{/queue/}} will serve only the names queue. > To offer the virtualhost service, the HTTPPort will be changed to support > VirtualHostAliases. As with an AMQPPort, with a HostNameAlias, a HTTP port > will be capable of presenting an interface for any virtualhost whose name > matches the hostname of the incoming request. A new alias type will support > a one to one mapping between port and virtualhost interface. > The scope of the initial work will be the REST API. It would be acceptable > to leave the other services (SASL, structure, metadata) for a future JIRA. > -- 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] (PROTON-1376) [C, windows] Release 0.16 build fail - src/protocol.h clobbered
[ https://issues.apache.org/jira/browse/PROTON-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764490#comment-15764490 ] Andrew Stitcher commented on PROTON-1376: - Thanks for investigating this - I have run into this issue as a sporadic windows only build failure, and didn't realise it was because the generated_c_files target is being run multiple times. I can't say I much like the false dependency solution, but if it works then I'm ok with committing it with a comment that it is only there to force a particular build order on Windows. > [C, windows] Release 0.16 build fail - src/protocol.h clobbered > --- > > Key: PROTON-1376 > URL: https://issues.apache.org/jira/browse/PROTON-1376 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 > Environment: Visual Studio 2012, x64 >Reporter: Chuck Rolke > > Target generated_c_files builds the src/protocol.h and src/encodings.h files. > Then projects qpid-proton and qpid-proton-core depend on generated_c_files. > It appears that generated_c_files as a dependency does not respect existing > src/protocol.h and src/encodings.h files and generates them three times in > total. > On a four-core build system the files are created three times but well before > other build threads try to use them. On other systems the timing is such that > a compilation of codec.c needs protocol.h but it is erased by the third file > creation. > {noformat} > 2>-- Build started: Project: generated_c_files, Configuration: Debug x64 > -- > 2>Build started 12/12/2016 4:49:28 PM. > 2>CustomBuild: > 2> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 2> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 2> Generating src/protocol.h > 2> Generating src/encodings.h > 2> > 2>Build succeeded. > 3>-- Build started: Project: qpid-proton, Configuration: Debug x64 -- > 4>-- Build started: Project: qpid-proton-core, Configuration: Debug x64 > -- > 3> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 3> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 3> Generating src/encodings.h > 3> Generating src/protocol.h > 3>ClCompile: > 3> object.c > 3> list.c > 3> map.c > 3> string.c > 3> iterator.c > 4>Build started 12/12/2016 4:49:29 PM. > 3> record.c > 3> log.c > 3> util.c > 3> error.c > 3> buffer.c > 4>CustomBuild: > 4> Building Custom Rule P:/qpid-proton/proton-c/CMakeLists.txt > 3> types.c > 4> CMake does not need to re-run because > P:\qpid-proton\build\proton-c\CMakeFiles\generate.stamp is up-to-date. > 4> Generating src/encodings.h > 3> framing.c > 3> codec.c > 4> Generating src/protocol.h > 3>..\..\proton-c\src\core\codec.c(33): fatal error C1083: Cannot open include > file: 'protocol.h': No such file or directory > {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] [Comment Edited] (QPID-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764470#comment-15764470 ] Andrew Stitcher edited comment on QPID-7595 at 12/20/16 3:37 PM: - I don't regard this as a significant problem because in practice all versions of cmake on windows machines are under the builders control and can be easily upgraded (either manually or using chocolatey). The cmake_minimum_required is the version available on ubuntu 1204 - even rhel 6 has a later version - 2.8.12 I think. If we want to up the minimum ubuntu to 1404 then we can go to 2.8.12. Is this a case where you are unable to upgrade cmake on a windows platform? I'm not aware if you can make the cmake_minimum_version conditional somehow, but that maybe a solution - although it will make the cmake file a little harder to read if possible. Better requirement docs would help here. was (Author: astitcher): I don't regard this as a significant problem because in practice all versions of cmake on windows machines are under the builders control and can be easily upgraded (either manually or using chocolatey). The cmake_minimum_required is the version available on ubuntu 1404 - even rhel 6 has a later version - 2.8.12 I think. Is this a case where you are unable to upgrade cmake on a windows platform? I'm not aware if you can make the cmake_minimum_version conditional somehow, but that maybe a solution - although it will make the cmake file a little harder to read if possible. Better requirement docs would help here. > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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-7595) [C++ Windows] CMake required version is too low for installation
[ https://issues.apache.org/jira/browse/QPID-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764470#comment-15764470 ] Andrew Stitcher commented on QPID-7595: --- I don't regard this as a significant problem because in practice all versions of cmake on windows machines are under the builders control and can be easily upgraded (either manually or using chocolatey). The cmake_minimum_required is the version available on ubuntu 1404 - even rhel 6 has a later version - 2.8.12 I think. Is this a case where you are unable to upgrade cmake on a windows platform? I'm not aware if you can make the cmake_minimum_version conditional somehow, but that maybe a solution - although it will make the cmake file a little harder to read if possible. Better requirement docs would help here. > [C++ Windows] CMake required version is too low for installation > > > Key: QPID-7595 > URL: https://issues.apache.org/jira/browse/QPID-7595 > Project: Qpid > Issue Type: Bug > Components: Build Tools >Affects Versions: qpid-cpp-1.35.0 > Environment: Windows >Reporter: Chuck Rolke > > The top level cmake lists declares > {noformat} > cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) > {noformat} > But the installation in src/msvc.cmake on Windows uses > {noformat} > $ > {noformat} > > which was introduced in CMake 3.1. -- 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-7563) Implement Virtualhost centric REST interface
[ https://issues.apache.org/jira/browse/QPID-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1576#comment-1576 ] Rob Godfrey commented on QPID-7563: --- {quote} * The current implementation for VH centric REST API depends on external configuration like DNS sub domain being configured. Thus, it could be difficult to test it in a restricted environment where the privileges to configure sub-domain are not available. Perhaps, adding an alternative way (not dependning from external settings) to configure VH centric REST API would be benefitial for testing use cases and local testing. For example, an http header can be used to define the root name, or, root object can be saved in session with special root selection service and used by the rest of REST servlets. It seem that root name extraction can be encapsulated into special factory which can be configured on HttpManagement rather then having it hardcoded as request.getServerName(). That would make the solution easy testable. {quote} The way to test is to not put the DNS name in the HTTP request, but rather the name you want to test with, se http://stackoverflow.com/questions/3390549/set-curl-to-use-local-virtual-hosts for example for how to do this with cURL. {quote} * AbstractServlet ** Alias pattern matching is evaluated for every request. Would it be better to cache the root object in session and invoke Port#getAddressSpace only when root is not found in session? {quote} We could, however I'm not sure that in practice this will be very expensive (in general there will be 0 or 1 aliases I imagine) so I'm dubious as to the benefits of caching {quote} * ApiDocsServlet ** doGet (old name doGetWithSubjectAndActor) The "latest/" is added into category url link by default. Thus, when user willcall the api doc servlet using http://default.localhost:8080/apidocs/latest/ the link will be built incorrectly. I think that "latest/" should be added into link only when servletPathParts.length == 2. If version is specified (/apidocs/v6.1/) the generated links are broken. Perhaps, request.getPathInfo() or HttpManagementUtil.getPathInfoElements would be easier to use here. ** writeCategoryDescription it does not need hierarchy parameter {quote} Fixed {quote} * BrokerQueryServlet ** In VH root: VH query fails with : Invalid path I think that getParent was meant to be implemented as {code} protected Broker getParent(final HttpServletRequest request, final ConfiguredObject managedObject) { return managedObject instanceof Broker ? (Broker)managedObject : HttpManagementUtil.getBroker(request.getServletContext()) ; } {code} {quote} No - BrokerQueryServlet just deliberately doesn't work through the virtual host view it makes no sense to talk about a BrokerQuery when you are not allowed to know about the Broker :-) {quote} * StructureServlet ** There is a duplicate code for getting children and associated object. The duplicate code can be moved into a separate method {quote} factored out the common code > Implement Virtualhost centric REST interface > > > Key: QPID-7563 > URL: https://issues.apache.org/jira/browse/QPID-7563 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > For use-cases where the Broker to hosts a shared service where different > applications are assigned to be different virtual hosts the broker should > offer the ability to manage these virtualhosts independently. It should > behave as if it were a chrooted prison. > AMQP Management already offers this ability. The HTTP management interface > should change to offer the same thing. > The REST API of a virtualhost will service the only virtualhost's subtree. > The formation of the service urls will reflect this structure. > {{/virtualhost}} will be analogous to {{/broker}} and will service the > virtualhost root. {{/queue/}} will serve all the queues defined on the > virtualhost, {{/queue/}} will serve only the names queue. > To offer the virtualhost service, the HTTPPort will be changed to support > VirtualHostAliases. As with an AMQPPort, with a HostNameAlias, a HTTP port > will be capable of presenting an interface for any virtualhost whose name > matches the hostname of the incoming request. A new alias type will support > a one to one mapping between port and virtualhost interface. > The scope of the initial work will be the REST API. It would be acceptable > to leave the other services (SASL, structure, metadata) for a future JIRA. > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-un
[jira] [Commented] (QPID-7563) Implement Virtualhost centric REST interface
[ https://issues.apache.org/jira/browse/QPID-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764441#comment-15764441 ] ASF subversion and git services commented on QPID-7563: --- Commit 1775306 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1775306 ] QPID-7563 : Update in response to review comments > Implement Virtualhost centric REST interface > > > Key: QPID-7563 > URL: https://issues.apache.org/jira/browse/QPID-7563 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > For use-cases where the Broker to hosts a shared service where different > applications are assigned to be different virtual hosts the broker should > offer the ability to manage these virtualhosts independently. It should > behave as if it were a chrooted prison. > AMQP Management already offers this ability. The HTTP management interface > should change to offer the same thing. > The REST API of a virtualhost will service the only virtualhost's subtree. > The formation of the service urls will reflect this structure. > {{/virtualhost}} will be analogous to {{/broker}} and will service the > virtualhost root. {{/queue/}} will serve all the queues defined on the > virtualhost, {{/queue/}} will serve only the names queue. > To offer the virtualhost service, the HTTPPort will be changed to support > VirtualHostAliases. As with an AMQPPort, with a HostNameAlias, a HTTP port > will be capable of presenting an interface for any virtualhost whose name > matches the hostname of the incoming request. A new alias type will support > a one to one mapping between port and virtualhost interface. > The scope of the initial work will be the REST API. It would be acceptable > to leave the other services (SASL, structure, metadata) for a future JIRA. > -- 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-7595) [C++ Windows] CMake required version is too low for installation
Chuck Rolke created QPID-7595: - Summary: [C++ Windows] CMake required version is too low for installation Key: QPID-7595 URL: https://issues.apache.org/jira/browse/QPID-7595 Project: Qpid Issue Type: Bug Components: Build Tools Affects Versions: qpid-cpp-1.35.0 Environment: Windows Reporter: Chuck Rolke The top level cmake lists declares {noformat} cmake_minimum_required(VERSION 2.8.7 FATAL_ERROR) {noformat} But the installation in src/msvc.cmake on Windows uses {noformat} $ {noformat} which was introduced in CMake 3.1. -- 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] (QPID-7473) [Java Broker] Asynchronous message recoverer should always delete orphan messages from the store
[ https://issues.apache.org/jira/browse/QPID-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7473. -- Resolution: Fixed The changes look good to me > [Java Broker] Asynchronous message recoverer should always delete orphan > messages from the store > > > Key: QPID-7473 > URL: https://issues.apache.org/jira/browse/QPID-7473 > Project: Qpid > Issue Type: Bug > Components: 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 >Reporter: Alex Rudyy >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > Asynchronous message recoverer can leave orphan messages in store in the > following scenario: > * transient messages for non-durable queues were flown to disk due reaching > 'flow to disk' memory threshold > * broker is restarted with flown to disk transient messages and there is no > durable queue on the virtual host > Asynchronous message recoverer performs orphan messages deletion only as part > of the last QueueRecoveringTask. Thus, if there is no persistent queue on the > virtual host, the orphan message deletion will not be triggered -- 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-7563) Implement Virtualhost centric REST interface
[ https://issues.apache.org/jira/browse/QPID-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764316#comment-15764316 ] Alex Rudyy commented on QPID-7563: -- I reviewed the changes. The changes in general look good to me with some minor comments below: * The current implementation for VH centric REST API depends on external configuration like DNS sub domain being configured. Thus, it could be difficult to test it in a restricted environment where the privileges to configure sub-domain are not available. Perhaps, adding an alternative way (not dependning from external settings) to configure VH centric REST API would be benefitial for testing use cases and local testing. For example, an http header can be used to define the root name, or, root object can be saved in session with special root selection service and used by the rest of REST servlets. It seem that root name extraction can be encapsulated into special factory which can be configured on HttpManagement rather then having it hardcoded as {{request.getServerName()}}. That would make the solution easy testable. * AbstractServlet ** Alias pattern matching is evaluated for every request. Would it be better to cache the root object in session and invoke Port#getAddressSpace only when root is not found in session? * ApiDocsServlet ** doGet (old name doGetWithSubjectAndActor) The "latest/" is added into category url link by default. Thus, when user willcall the api doc servlet using http://default.localhost:8080/apidocs/latest/ the link will be built incorrectly. I think that "latest/" should be added into link only when servletPathParts.length == 2. If version is specified (/apidocs/v6.1/) the generated links are broken. Perhaps, request.getPathInfo() or HttpManagementUtil.getPathInfoElements would be easier to use here. ** writeCategoryDescription it does not need hierarchy parameter * BrokerQueryServlet ** In VH root: VH query fails with : Invalid path I think that getParent was meant to be implemented as {code} protected Broker getParent(final HttpServletRequest request, final ConfiguredObject managedObject) { return managedObject instanceof Broker ? (Broker)managedObject : HttpManagementUtil.getBroker(request.getServletContext()) ; } {code} * StructureServlet ** There is a duplicate code for getting children and associated object. The duplicate code can be moved into a separate method > Implement Virtualhost centric REST interface > > > Key: QPID-7563 > URL: https://issues.apache.org/jira/browse/QPID-7563 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > For use-cases where the Broker to hosts a shared service where different > applications are assigned to be different virtual hosts the broker should > offer the ability to manage these virtualhosts independently. It should > behave as if it were a chrooted prison. > AMQP Management already offers this ability. The HTTP management interface > should change to offer the same thing. > The REST API of a virtualhost will service the only virtualhost's subtree. > The formation of the service urls will reflect this structure. > {{/virtualhost}} will be analogous to {{/broker}} and will service the > virtualhost root. {{/queue/}} will serve all the queues defined on the > virtualhost, {{/queue/}} will serve only the names queue. > To offer the virtualhost service, the HTTPPort will be changed to support > VirtualHostAliases. As with an AMQPPort, with a HostNameAlias, a HTTP port > will be capable of presenting an interface for any virtualhost whose name > matches the hostname of the incoming request. A new alias type will support > a one to one mapping between port and virtualhost interface. > The scope of the initial work will be the REST API. It would be acceptable > to leave the other services (SASL, structure, metadata) for a future JIRA. > -- 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-7594) [Java Broker] Refactor Web Management Console to support virtual host centric UI
[ https://issues.apache.org/jira/browse/QPID-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7594: - Description: Virtual host centric REST interfaces have been added as part of QPID-7563. The Web Management Console needs to be changed to support virtual host centric REST interfaces and provide a Virtualhost centric UI to the end user. As part of QPID-7563 the existing servlets( REST, apidocs, Structure, MetaData, Query and QueueReports) have been updated so, that if the request is determined to have come through on a URL which is aliases to a specific vhost, then the results from the servlet will be specific to the vhost, and paths will reflect a virtual host root. The Web Management Console at the moment does not respect the virtual host root. The following changes are required to fully support virtual host centric view: * VH aliases UI should be available for the HTTP port. User should be able to add/remove aliases for HTTP port * On user authentication, the Console invokes Broker operations getUser, getGroups to get the authenticated user and groups. It seems corresponding operations need to be added to VH and the Console would need to call VH to retrieve user and group information. Management#getAuthenticatedUserAndGroups should respect VH root. At the moment "broker" root is hard-coded in the method. * Console uses Broker userpreferences to get the timezone, tabs, etc. It seems that Console should be getting userpreferences from VH in VH centric view * Console tries to open a Broker tab by default. In VH centric view the VH tab should be opened instead. * On clicking on root item in a navigation tree a VH tab should be opened. At the moment, Broker tab is opened. * Queue tab should not be calling querybroker to get the queue depth.It should call VH query API instead. * Saving tab in preference should work against VH in VH centric view * Dashboard UI in VH centric view do not need to cal broker preferences. Dashboard creation dialog displays the correct VH but somehow it is not selected. It seems that this dialog can be completely omitted in VH centric view. * Query UI should be executed against VH query rest API. The dialog to create query displays the correct VH selected but somehow it is not selected and broker API is called. That needs to be fixed. Potentially, the widget for selection of association of query can be disabled or hidden. The same is for query cloning dialog * Preferences dialog calls broker userpreferences. In VH centric view VH userpreferences should be used At the moment, it is unclear how to display all available VH for the user (in order to provide a convenient way to switch between VHs). Even if user have access to multiple VHs, the DNS sub-domain and VH alias for http port might not be configured. Potentially, http port aliases can be used to assume that sub-domain is configured. I am not sure whether we really need a UI for switching between multiple VHs. was: Virtual host centric REST interfaces have been added as part of QPID-7563. The Web Management Console needs to be changed to support virtual host centric REST interfaces and provide a Virtualhost centric UI to the end user. As part of QPID-7563 the existing servlets( REST, apidocs, Structure, MetaData, Query and QueueReports) have been updated so, that if the request is determined to have come through on a URL which is aliases to a specific vhost, then the results from the servlet will be specific to the vhost, and paths will reflect a virtual host root. The Web Management Console at the moment does not respect the virtual host root. The following changes are required to fully support virtual host centric view: * VH aliases UI should be available for the HTTP port. User should be able to add/remove aliases for HTTP port * On user authentication, the Console invokes Broker operations getUser, getGroups to get the authenticated user and groups. It seems corresponding operations need to be added to VH and the Console would need to call VH to retrieve user and group information. Management#getAuthenticatedUserAndGroups should respect VH root. At the moment "broker" root is hard-coded in the method. * Console uses Broker userpreferences to get the timezone, tabs, etc. It seems that Console should be getting userpreferences from VH in VH centric view * Console tries to open a Broker tab by default. In VH centric view the VH tab should be opened instead. * On clicking on root item in a navigation tree a VH tab should be opened. At the moment, Broker tab is opened. * Queue tab should not be calling querybroker to get the queue depth.It should call VH query API instead. * Saving tab in preference should work against VH in VH centric view * Dashboard UI in VH centric view do not need to cal broker preferences. Dashboard creation dialog displays the correct VH but somehow it
[jira] [Created] (QPID-7594) [Java Broker] Refactor Web Management Console to support virtual host centric UI
Alex Rudyy created QPID-7594: Summary: [Java Broker] Refactor Web Management Console to support virtual host centric UI Key: QPID-7594 URL: https://issues.apache.org/jira/browse/QPID-7594 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Alex Rudyy Fix For: qpid-java-6.2 Virtual host centric REST interfaces have been added as part of QPID-7563. The Web Management Console needs to be changed to support virtual host centric REST interfaces and provide a Virtualhost centric UI to the end user. As part of QPID-7563 the existing servlets( REST, apidocs, Structure, MetaData, Query and QueueReports) have been updated so, that if the request is determined to have come through on a URL which is aliases to a specific vhost, then the results from the servlet will be specific to the vhost, and paths will reflect a virtual host root. The Web Management Console at the moment does not respect the virtual host root. The following changes are required to fully support virtual host centric view: * VH aliases UI should be available for the HTTP port. User should be able to add/remove aliases for HTTP port * On user authentication, the Console invokes Broker operations getUser, getGroups to get the authenticated user and groups. It seems corresponding operations need to be added to VH and the Console would need to call VH to retrieve user and group information. Management#getAuthenticatedUserAndGroups should respect VH root. At the moment "broker" root is hard-coded in the method. * Console uses Broker userpreferences to get the timezone, tabs, etc. It seems that Console should be getting userpreferences from VH in VH centric view * Console tries to open a Broker tab by default. In VH centric view the VH tab should be opened instead. * On clicking on root item in a navigation tree a VH tab should be opened. At the moment, Broker tab is opened. * Queue tab should not be calling querybroker to get the queue depth.It should call VH query API instead. * Saving tab in preference should work against VH in VH centric view * Dashboard UI in VH centric view do not need to cal broker preferences. Dashboard creation dialog displays the correct VH but somehow it is not selected. It seems that this dialog can be completely omitted in VH centric view. * Query UI should be executed against VH query rest API. The dialog to create query displays the correct VH selected but somehow it is not selected and broker API is called. That needs to be fixed. Potentially, the widget for selection of association of query can be disabled or hidden. The same is for query cloning dialog * Preferences dialog calls broker userpreferences. In VH centric view VH userpreferences should be used -- 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: AMQP 1.0/Python - Question re. encoding of maps and lists : failing qpid_tests.broker_1_0.translation.TranslationTests.test_translate* against Java Broker
On 19/12/16 15:57, Keith W wrote: By debugging the Java Broker's translation module, I can see that the AMQP 1.0 publishing end is sending the map encoded within a DataSection. This surprises me - I was expecting the application-data to be an amqp-value containing the map. The Java Broker doesn't know how to translate this for the 0-10 and hence the test fails. Why does Qpid Python / swigged client encode the map this way? The swig layer has some special logic for managing message content that predates 1.0 and works the same way for both 1.0 and 0-10. The content-type is used to indicate the type in both cases. 1.0 required some changes to the messaging API (set-/get- ContentObject()) to allow value sections to be used. I suspect the swig binding was just never changed to use those changes. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[ https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7593: - Description: If I run the following code, jvisualvm shows that the object that underlies the AMQP1.0 Connection, Session and Consumer are leaked. The GC root is the QueueConsumerNodeList associated with the Queue/QueueConsumerManager. The node the tail and is in the deleted state and will be eventually scavenged (once new consumers join the queue). This is common with the other protocols and I believe this aspect is as designed. However, I think the fact that the Connections/Session/ConsumerTarget remains referenced is a defect. It shows us that the ConsumerTarget_1.0 (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not being closed. Other protocols don't show this same defect. {code:java} Properties properties = new Properties(); properties.load(resourceAsStream); Context context = new InitialContext(properties); ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup("qpidConnectionfactory"); Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = (Destination) context.lookup("myqueue"); MessageConsumer messageConsumer = session.createConsumer(destination); if (true) System.exit(1); {code} I expect this defect does not appear in release versions of the product. was: If I run the following code, jvisualvm shows that the object that underlies the AMQP1.0 Connection, Session and Consumer are leaked. The GC root is the QueueConsumerNodeList associated with the Queue/QueueConsumerManager. The node the tail and is in the deleted state and will be eventually scavenged (once new consumers join the queue). This is common with the other protocols and I believe this aspect is as designed. However, I think the fact that the Connections/Session/ConsumerTarget remains referenced is a defect. It shows us that the ConsumerTarget_1.0 (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not being closed. Other protocols don't show this same defect. {code:java} Properties properties = new Properties(); properties.load(resourceAsStream); Context context = new InitialContext(properties); ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup("qpidConnectionfactory"); Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = (Destination) context.lookup("myqueue"); MessageConsumer messageConsumer = session.createConsumer(destination); if (true) System.exit(1); {code} > Abnormally ending an AMQP1.0 connection with consumer leaks the connection, > session and objects related to the consumer > --- > > Key: QPID-7593 > URL: https://issues.apache.org/jira/browse/QPID-7593 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-7.0.0 >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > Attachments: Screen Shot 2016-12-20 at 08.16.37.png > > > If I run the following code, jvisualvm shows that the object that underlies > the AMQP1.0 Connection, Session and Consumer are leaked. > The GC root is the QueueConsumerNodeList associated with the > Queue/QueueConsumerManager. The node the tail and is in the deleted state > and will be eventually scavenged (once new consumers join the queue). This > is common with the other protocols and I believe this aspect is as designed. > However, I think the fact that the Connections/Session/ConsumerTarget remains > referenced is a defect. It shows us that the ConsumerTarget_1.0 > (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not > being closed. Other protocols don't show this same defect. > {code:java} > Properties properties = new Properties(); > properties.load(resourceAsStream); > Context context = new InitialContext(properties); > ConnectionFactory connectionFactory = (ConnectionFactory) > context.lookup("qpidConnectionfactory"); > Connection connection = connectionFactory.createConnection(); > connection.start(); > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > Destination destination = (Destination)
[jira] [Updated] (QPID-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[ https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7593: - Affects Version/s: qpid-java-7.0.0 > Abnormally ending an AMQP1.0 connection with consumer leaks the connection, > session and objects related to the consumer > --- > > Key: QPID-7593 > URL: https://issues.apache.org/jira/browse/QPID-7593 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-7.0.0 >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > Attachments: Screen Shot 2016-12-20 at 08.16.37.png > > > If I run the following code, jvisualvm shows that the object that underlies > the AMQP1.0 Connection, Session and Consumer are leaked. > The GC root is the QueueConsumerNodeList associated with the > Queue/QueueConsumerManager. The node the tail and is in the deleted state > and will be eventually scavenged (once new consumers join the queue). This > is common with the other protocols and I believe this aspect is as designed. > However, I think the fact that the Connections/Session/ConsumerTarget remains > referenced is a defect. It shows us that the ConsumerTarget_1.0 > (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not > being closed. Other protocols don't show this same defect. > {code:java} > Properties properties = new Properties(); > properties.load(resourceAsStream); > Context context = new InitialContext(properties); > ConnectionFactory connectionFactory = (ConnectionFactory) > context.lookup("qpidConnectionfactory"); > Connection connection = connectionFactory.createConnection(); > connection.start(); > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > Destination destination = (Destination) context.lookup("myqueue"); > MessageConsumer messageConsumer = > session.createConsumer(destination); > if (true) System.exit(1); > {code} > I expect this defect does not appear in release versions of the product. -- 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-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[ https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15763603#comment-15763603 ] Keith Wall commented on QPID-7593: -- VisualVM screenshot attached. > Abnormally ending an AMQP1.0 connection with consumer leaks the connection, > session and objects related to the consumer > --- > > Key: QPID-7593 > URL: https://issues.apache.org/jira/browse/QPID-7593 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > Attachments: Screen Shot 2016-12-20 at 08.16.37.png > > > If I run the following code, jvisualvm shows that the object that underlies > the AMQP1.0 Connection, Session and Consumer are leaked. > The GC root is the QueueConsumerNodeList associated with the > Queue/QueueConsumerManager. The node the tail and is in the deleted state > and will be eventually scavenged (once new consumers join the queue). This > is common with the other protocols and I believe this aspect is as designed. > However, I think the fact that the Connections/Session/ConsumerTarget remains > referenced is a defect. It shows us that the ConsumerTarget_1.0 > (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not > being closed. Other protocols don't show this same defect. > {code:java} > Properties properties = new Properties(); > properties.load(resourceAsStream); > Context context = new InitialContext(properties); > ConnectionFactory connectionFactory = (ConnectionFactory) > context.lookup("qpidConnectionfactory"); > Connection connection = connectionFactory.createConnection(); > connection.start(); > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > Destination destination = (Destination) context.lookup("myqueue"); > MessageConsumer messageConsumer = > session.createConsumer(destination); > if (true) System.exit(1); > {code} -- 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-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
[ https://issues.apache.org/jira/browse/QPID-7593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7593: - Attachment: Screen Shot 2016-12-20 at 08.16.37.png > Abnormally ending an AMQP1.0 connection with consumer leaks the connection, > session and objects related to the consumer > --- > > Key: QPID-7593 > URL: https://issues.apache.org/jira/browse/QPID-7593 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-7.0.0 > > Attachments: Screen Shot 2016-12-20 at 08.16.37.png > > > If I run the following code, jvisualvm shows that the object that underlies > the AMQP1.0 Connection, Session and Consumer are leaked. > The GC root is the QueueConsumerNodeList associated with the > Queue/QueueConsumerManager. The node the tail and is in the deleted state > and will be eventually scavenged (once new consumers join the queue). This > is common with the other protocols and I believe this aspect is as designed. > However, I think the fact that the Connections/Session/ConsumerTarget remains > referenced is a defect. It shows us that the ConsumerTarget_1.0 > (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not > being closed. Other protocols don't show this same defect. > {code:java} > Properties properties = new Properties(); > properties.load(resourceAsStream); > Context context = new InitialContext(properties); > ConnectionFactory connectionFactory = (ConnectionFactory) > context.lookup("qpidConnectionfactory"); > Connection connection = connectionFactory.createConnection(); > connection.start(); > Session session = connection.createSession(false, > Session.AUTO_ACKNOWLEDGE); > Destination destination = (Destination) context.lookup("myqueue"); > MessageConsumer messageConsumer = > session.createConsumer(destination); > if (true) System.exit(1); > {code} -- 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-7593) Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer
Keith Wall created QPID-7593: Summary: Abnormally ending an AMQP1.0 connection with consumer leaks the connection, session and objects related to the consumer Key: QPID-7593 URL: https://issues.apache.org/jira/browse/QPID-7593 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-7.0.0 If I run the following code, jvisualvm shows that the object that underlies the AMQP1.0 Connection, Session and Consumer are leaked. The GC root is the QueueConsumerNodeList associated with the Queue/QueueConsumerManager. The node the tail and is in the deleted state and will be eventually scavenged (once new consumers join the queue). This is common with the other protocols and I believe this aspect is as designed. However, I think the fact that the Connections/Session/ConsumerTarget remains referenced is a defect. It shows us that the ConsumerTarget_1.0 (org/apache/qpid/server/consumer/AbstractConsumerTarget.java:284) is not being closed. Other protocols don't show this same defect. {code:java} Properties properties = new Properties(); properties.load(resourceAsStream); Context context = new InitialContext(properties); ConnectionFactory connectionFactory = (ConnectionFactory) context.lookup("qpidConnectionfactory"); Connection connection = connectionFactory.createConnection(); connection.start(); Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE); Destination destination = (Destination) context.lookup("myqueue"); MessageConsumer messageConsumer = session.createConsumer(destination); if (true) System.exit(1); {code} -- 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