date:20161220


[ 
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

2016-12-20 Thread ASF subversion and git services (JIRA)


[ 
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

2016-12-20 Thread Ganesh Murthy (JIRA)


 [ 
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

2016-12-20 Thread ASF subversion and git services (JIRA)


[ 
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

2016-12-20 Thread ASF subversion and git services (JIRA)


[ 
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()

2016-12-20 Thread Ganesh Murthy (JIRA)


 [ 
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()

2016-12-20 Thread ASF GitHub Bot (JIRA)


[ 
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...

2016-12-20 Thread ganeshmurthy

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

2016-12-20 Thread ASF subversion and git services (JIRA)


[ 
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

2016-12-20 Thread Rob Godfrey (JIRA)


[ 
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

2016-12-20 Thread Chuck Rolke (JIRA)

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.

[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

2016-12-20 Thread Gordon Sim


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