Re: Review Request 59638: PROTON-1493: c-proactor make pn_proactor_interrupt async-signal-safe

[Cliff Jansen]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59638/#review176417
---


Ship it!




Ship It!

- Cliff Jansen


On May 30, 2017, 4:48 p.m., Alan Conway wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59638/
> ---
> 
> (Updated May 30, 2017, 4:48 p.m.)
> 
> 
> Review request for qpid, Andrew Stitcher and Cliff Jansen.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> ---
> 
> pn_proactor_interrupt() will  often be used from signal handlers so must be
> async-signal-safe. Updated the documentation and modified the implementations
> of pn_proactor_interrupt() to use only async-signal-safe calls, no locks.
> 
> 
> Diffs
> -
> 
>   examples/c/proactor/broker.c 7d95e7fc49e53cc5e36c62b814d39287005eb59f 
>   proton-c/include/proton/proactor.h 861afbed22df6cb6aa9e18c15cdb7cd9ed64eede 
>   proton-c/src/proactor/epoll.c 7490ecdcaf984ec33d9b26c6f0357c6de2e09d0f 
>   proton-c/src/proactor/libuv.c cf7a31b5711f207541c9e832b06bb13e7051ab69 
> 
> 
> Diff: https://reviews.apache.org/r/59638/diff/1/
> 
> 
> Testing
> ---
> 
> proactor self-tests on epoll and libuv proactor
> 
> 
> Thanks,
> 
> Alan Conway
> 
>

[jira] [Closed] (PROTON-1492) event_loop::inject link error with qpid-proton-0.17.0

[Greg Clinton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Clinton closed PROTON-1492.


building qpid-proton-0.17.0 with -DCMAKE_CXX_FLAGS=-std=c++11 seems to have 
taken care of my issue

> event_loop::inject link error with qpid-proton-0.17.0
> -
>
> Key: PROTON-1492
> URL: https://issues.apache.org/jira/browse/PROTON-1492
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.17.0
> Environment: ubuntu 16.04
>Reporter: Greg Clinton
>Assignee: Cliff Jansen
> Fix For: 0.17.0
>
>
> When I build my qpid-proton-0.17.0 program I get this link error:
> undefined reference to proton::event_loop::inject(std::function)
> Here is how I build:
> g++ -std=c++14 myprog.cpp -o myprog -lqpid-proton-cpp -lboost_system -lcrypto 
> -lssl
> Am I missing a library?
> Also, without -std=c++14 or -std=c++11 the link issue goes away. But I will 
> need -std=c++11 at least.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (PROTON-1492) event_loop::inject link error with qpid-proton-0.17.0

[Greg Clinton (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030329#comment-16030329
 ] 

Greg Clinton edited comment on PROTON-1492 at 5/30/17 11:08 PM:


building qpid-proton-0.17.0 with -DCMAKE_CXX_FLAGS=-std=c++11 seems to have 
taken care of my issue


was (Author: greg.clin...@gmail.com):
building qpid-proton-0.17.0 -DCMAKE_CXX_FLAGS=-std=c++11 seems to have taken 
care of my issue

> event_loop::inject link error with qpid-proton-0.17.0
> -
>
> Key: PROTON-1492
> URL: https://issues.apache.org/jira/browse/PROTON-1492
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.17.0
> Environment: ubuntu 16.04
>Reporter: Greg Clinton
>Assignee: Cliff Jansen
> Fix For: 0.17.0
>
>
> When I build my qpid-proton-0.17.0 program I get this link error:
> undefined reference to proton::event_loop::inject(std::function)
> Here is how I build:
> g++ -std=c++14 myprog.cpp -o myprog -lqpid-proton-cpp -lboost_system -lcrypto 
> -lssl
> Am I missing a library?
> Also, without -std=c++14 or -std=c++11 the link issue goes away. But I will 
> need -std=c++11 at least.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (PROTON-1492) event_loop::inject link error with qpid-proton-0.17.0

[Greg Clinton (JIRA)]

 [ 
https://issues.apache.org/jira/browse/PROTON-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Greg Clinton resolved PROTON-1492.
--
   Resolution: Fixed
Fix Version/s: 0.17.0

building qpid-proton-0.17.0 with -DCMAKE_CXX_FLAGS=-std=c++11 seems to have 
taken care of my issue

> event_loop::inject link error with qpid-proton-0.17.0
> -
>
> Key: PROTON-1492
> URL: https://issues.apache.org/jira/browse/PROTON-1492
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.17.0
> Environment: ubuntu 16.04
>Reporter: Greg Clinton
>Assignee: Cliff Jansen
> Fix For: 0.17.0
>
>
> When I build my qpid-proton-0.17.0 program I get this link error:
> undefined reference to proton::event_loop::inject(std::function)
> Here is how I build:
> g++ -std=c++14 myprog.cpp -o myprog -lqpid-proton-cpp -lboost_system -lcrypto 
> -lssl
> Am I missing a library?
> Also, without -std=c++14 or -std=c++11 the link issue goes away. But I will 
> need -std=c++11 at least.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (PROTON-1492) event_loop::inject link error with qpid-proton-0.17.0

[Greg Clinton (JIRA)]

[ 
https://issues.apache.org/jira/browse/PROTON-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030329#comment-16030329
 ] 

Greg Clinton commented on PROTON-1492:
--

building qpid-proton-0.17.0 -DCMAKE_CXX_FLAGS=-std=c++11 seems to have taken 
care of my issue

> event_loop::inject link error with qpid-proton-0.17.0
> -
>
> Key: PROTON-1492
> URL: https://issues.apache.org/jira/browse/PROTON-1492
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.17.0
> Environment: ubuntu 16.04
>Reporter: Greg Clinton
>Assignee: Cliff Jansen
>
> When I build my qpid-proton-0.17.0 program I get this link error:
> undefined reference to proton::event_loop::inject(std::function)
> Here is how I build:
> g++ -std=c++14 myprog.cpp -o myprog -lqpid-proton-cpp -lboost_system -lcrypto 
> -lssl
> Am I missing a library?
> Also, without -std=c++14 or -std=c++11 the link issue goes away. But I will 
> need -std=c++11 at least.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-209) Three+ router test is needed in the system test suite.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029957#comment-16029957
 ] 

ASF GitHub Bot commented on DISPATCH-209:
-

GitHub user mgoulish opened a pull request:

https://github.com/apache/qpid-dispatch/pull/165

DISPATCH-209 : add a linear 3-router linkroute test

test #4 -- 3-router link-route 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgoulish/qpid-dispatch master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/165.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 #165


commit 06b24e87c77eb1136eb167d504d34424bf4d4e81
Author: mick goulish 
Date:   2017-05-30T19:02:29Z

DISPATCH-209 : add a linear 3-router linkroute test




> Three+ router test is needed in the system test suite.
> --
>
> Key: DISPATCH-209
> URL: https://issues.apache.org/jira/browse/DISPATCH-209
> Project: Qpid Dispatch
>  Issue Type: New Feature
>  Components: Tests
>Reporter: Ted Ross
>Assignee: michael goulish
> Fix For: 1.0.0
>
>
> There have arisen some issues that would have been caught had there been a 
> three-router test in the regression suite.  This test should be added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-dispatch pull request #165: DISPATCH-209 : add a linear 3-router linkro...

[mgoulish]

GitHub user mgoulish opened a pull request:

https://github.com/apache/qpid-dispatch/pull/165

DISPATCH-209 : add a linear 3-router linkroute test

test #4 -- 3-router link-route 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mgoulish/qpid-dispatch master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/qpid-dispatch/pull/165.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 #165


commit 06b24e87c77eb1136eb167d504d34424bf4d4e81
Author: mick goulish 
Date:   2017-05-30T19:02:29Z

DISPATCH-209 : add a linear 3-router linkroute test




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7616) VirtualHostNode name is not expanded before creating thread

[James Howe (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029811#comment-16029811
 ] 

James Howe commented on QPID-7616:
--

Like this, if I recall correctly.
https://stackoverflow.com/a/41552549/476716


> VirtualHostNode name is not expanded before creating thread
> ---
>
> Key: QPID-7616
> URL: https://issues.apache.org/jira/browse/QPID-7616
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: James Howe
>Priority: Trivial
>
> This results in, for example, a thread named 
> {{VirtualHostNode-$\{qpid.vhost\}-Config}}. Other threads have expanded the 
> parameter, e.g. {{virtualhost-default-receiver-pool-0}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton issue #105: Port of C++ binding to Proton Proactor

[alanconway]

Github user alanconway commented on the issue:

https://github.com/apache/qpid-proton/pull/105
  
I'm still happy with this. I have some ideas about simplifying the 
returned<>/thread_safe<> story but lets get this up on master as a starting 
point.


---
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] (DISPATCH-777) [system_tests_drain] pn_object_free: corrupted double-linked list

[Alan Conway (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DISPATCH-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Conway resolved DISPATCH-777.
--
Resolution: Fixed

> [system_tests_drain] pn_object_free: corrupted double-linked list
> -
>
> Key: DISPATCH-777
> URL: https://issues.apache.org/jira/browse/DISPATCH-777
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of qpid-proton and qpid-dispatch on debian 
> testing:
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher 
> Date:   Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy 
> Date:   Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you 
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: DISPATCH-777_1.core.zip, DISPATCH-777_2.core.zip, 
> DISPATCH-777_3.core.zip
>
>
> Execute the {{system_tests_drain}} test suite in Qpid Dispatch until the 
> error appears
> {{ctest -VV -R system_tests_drain --repeat-until-fail 1000}}
> There are several very similar errors possible. It either prints
> {{*** Error in `qdrouterd': corrupted double-linked list: 0x7f45a40103c0 
> ***}}
> or 
> {{** Error in `qdrouterd': double free or corruption (!prev): 
> 0x7f49ac013360 ***}}
> Logs and core files from three failures of the test are attached.
> {noformat}
> 15: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_drain"
> 15: Test timeout computed to be: 1500
> *** Error in `qdrouterd': double free or corruption (!prev): 
> 0x7f49ac013360 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.615: test_drain_support_1_all_messages 
> (system_tests_drain.DrainSupportTest) ... ok
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f49bc22df96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x7f49bc22e78e]
> /lib/libqpid-proton-core.so.11(pn_object_free+0x24)[0x7f49bd32a289]
> /lib/libqpid-proton-core.so.11(pn_class_decref+0xca)[0x7f49bd329d8a]
> /lib/libqpid-proton-core.so.11(pn_decref+0x22)[0x7f49bd32a2d2]
> /lib/libqpid-proton-proactor.so.11(+0x42f0)[0x7f49bd1142f0]
> /lib/libqpid-proton-proactor.so.11(+0x4395)[0x7f49bd114395]
> /lib/libqpid-proton-proactor.so.11(+0x4ac5)[0x7f49bd114ac5]
> /lib/libqpid-proton-proactor.so.11(+0x70e5)[0x7f49bd1170e5]
> /lib/libqpid-proton-proactor.so.11(pn_proactor_wait+0x1d)[0x7f49bd117185]
> /main/qpid-dispatch/build/src/libqpid-dispatch.so(+0x55e7a)[0x7f49bd5b8e7a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f49bcefa494]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f49bc29f93f]
> === Memory map: 
> 55694d2c5000-55694d2c8000 r-xp  fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c7000-55694d4c8000 r--p 2000 fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c8000-55694d4c9000 rw-p 3000 fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694eb26000-55694eea3000 rw-p  00:00 0  
> [heap]
> 7f49a400-7f49a4021000 rw-p  00:00 0 
> 7f49a4021000-7f49a800 ---p  00:00 0 
> 7f49a800-7f49a8021000 rw-p  00:00 0 
> 7f49a8021000-7f49ac00 ---p  00:00 0 
> 7f49ac00-7f49ac072000 rw-p  00:00 0 
> 7f49ac072000-7f49b000 ---p  00:00 0 
> 7f49b21b2000-7f49b21c8000 r-xp  fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b21c8000-7f49b23c7000 ---p 00016000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c7000-7f49b23c8000 r--p 00015000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c8000-7f49b23c9000 rw-p 00016000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c9000-7f49b23d3000 r-xp  fe:06 394180 
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b23d3000-7f49b25d3000 ---p a000 fe:06 394180 
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b25d3000-7f49b25d4000 r--p a000 fe:06 394180 
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b25d4000-7f49b25d5000 rw-p b000 fe:06 394180 
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b25d5000-7f49b25db000 rw-p  00:00 0 
> 7f49b25db000-7f49b25e r-xp  fe:06 530154   

[jira] [Commented] (DISPATCH-777) [system_tests_drain] pn_object_free: corrupted double-linked list

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029774#comment-16029774
 ] 

ASF subversion and git services commented on DISPATCH-777:
--

Commit 75cbe215a26e52b9de9eaa2efdb6d0bea4e44927 in qpid-dispatch's branch 
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=75cbe21 ]

DISPATCH-777: Restore delayed-activation code in router core.

Removed in error, required to ensure that connections are not activated
after they have been deleted by the router core thread.


> [system_tests_drain] pn_object_free: corrupted double-linked list
> -
>
> Key: DISPATCH-777
> URL: https://issues.apache.org/jira/browse/DISPATCH-777
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of qpid-proton and qpid-dispatch on debian 
> testing:
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher 
> Date:   Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy 
> Date:   Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you 
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
>Assignee: Alan Conway
> Fix For: 1.0.0
>
> Attachments: DISPATCH-777_1.core.zip, DISPATCH-777_2.core.zip, 
> DISPATCH-777_3.core.zip
>
>
> Execute the {{system_tests_drain}} test suite in Qpid Dispatch until the 
> error appears
> {{ctest -VV -R system_tests_drain --repeat-until-fail 1000}}
> There are several very similar errors possible. It either prints
> {{*** Error in `qdrouterd': corrupted double-linked list: 0x7f45a40103c0 
> ***}}
> or 
> {{** Error in `qdrouterd': double free or corruption (!prev): 
> 0x7f49ac013360 ***}}
> Logs and core files from three failures of the test are attached.
> {noformat}
> 15: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_drain"
> 15: Test timeout computed to be: 1500
> *** Error in `qdrouterd': double free or corruption (!prev): 
> 0x7f49ac013360 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.615: test_drain_support_1_all_messages 
> (system_tests_drain.DrainSupportTest) ... ok
> /lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f49bc22df96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7778e)[0x7f49bc22e78e]
> /lib/libqpid-proton-core.so.11(pn_object_free+0x24)[0x7f49bd32a289]
> /lib/libqpid-proton-core.so.11(pn_class_decref+0xca)[0x7f49bd329d8a]
> /lib/libqpid-proton-core.so.11(pn_decref+0x22)[0x7f49bd32a2d2]
> /lib/libqpid-proton-proactor.so.11(+0x42f0)[0x7f49bd1142f0]
> /lib/libqpid-proton-proactor.so.11(+0x4395)[0x7f49bd114395]
> /lib/libqpid-proton-proactor.so.11(+0x4ac5)[0x7f49bd114ac5]
> /lib/libqpid-proton-proactor.so.11(+0x70e5)[0x7f49bd1170e5]
> /lib/libqpid-proton-proactor.so.11(pn_proactor_wait+0x1d)[0x7f49bd117185]
> /main/qpid-dispatch/build/src/libqpid-dispatch.so(+0x55e7a)[0x7f49bd5b8e7a]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f49bcefa494]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f49bc29f93f]
> === Memory map: 
> 55694d2c5000-55694d2c8000 r-xp  fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c7000-55694d4c8000 r--p 2000 fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694d4c8000-55694d4c9000 rw-p 3000 fe:06 537578 
> /main/qpid-dispatch/build/router/qdrouterd
> 55694eb26000-55694eea3000 rw-p  00:00 0  
> [heap]
> 7f49a400-7f49a4021000 rw-p  00:00 0 
> 7f49a4021000-7f49a800 ---p  00:00 0 
> 7f49a800-7f49a8021000 rw-p  00:00 0 
> 7f49a8021000-7f49ac00 ---p  00:00 0 
> 7f49ac00-7f49ac072000 rw-p  00:00 0 
> 7f49ac072000-7f49b000 ---p  00:00 0 
> 7f49b21b2000-7f49b21c8000 r-xp  fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b21c8000-7f49b23c7000 ---p 00016000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c7000-7f49b23c8000 r--p 00015000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c8000-7f49b23c9000 rw-p 00016000 fe:06 394148 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> 7f49b23c9000-7f49b23d3000 r-xp  fe:06 394180 
> /usr/lib/x86_64-linux-gnu/libnss_files-2.24.so
> 7f49b23d3000-7f49b25d3000 ---p a000 fe:06 394180

Review Request 59638: PROTON-1493: c-proactor make pn_proactor_interrupt async-signal-safe

[Alan Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59638/
---

Review request for qpid, Andrew Stitcher and Cliff Jansen.


Repository: qpid-proton-git


Description
---

pn_proactor_interrupt() will  often be used from signal handlers so must be
async-signal-safe. Updated the documentation and modified the implementations
of pn_proactor_interrupt() to use only async-signal-safe calls, no locks.


Diffs
-

  examples/c/proactor/broker.c 7d95e7fc49e53cc5e36c62b814d39287005eb59f 
  proton-c/include/proton/proactor.h 861afbed22df6cb6aa9e18c15cdb7cd9ed64eede 
  proton-c/src/proactor/epoll.c 7490ecdcaf984ec33d9b26c6f0357c6de2e09d0f 
  proton-c/src/proactor/libuv.c cf7a31b5711f207541c9e832b06bb13e7051ab69 


Diff: https://reviews.apache.org/r/59638/diff/1/


Testing
---

proactor self-tests on epoll and libuv proactor


Thanks,

Alan Conway

[jira] [Commented] (QPID-7801) [Java Broker] Allow variable substitution of virtualhost in OAuth2 resolver URIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029683#comment-16029683
 ] 

ASF subversion and git services commented on QPID-7801:
---

Commit b5e769d8188508ffa2cb1e86ce3bd64ca4945894 in qpid-broker-j's branch 
refs/heads/master from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b5e769d ]

QPID-7801 : Remove erroneously committed change


> [Java Broker] Allow variable substitution of virtualhost in OAuth2 resolver 
> URIs 
> -
>
> Key: QPID-7801
> URL: https://issues.apache.org/jira/browse/QPID-7801
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Allow substitution of address space (based on resolution of SNI / HTTPS HOST 
> to vhost) in OAuth2 resolver URIs (to allow per vhost configuration).  Add 
> keycloak provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7801) [Java Broker] Allow variable substitution of virtualhost in OAuth2 resolver URIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029675#comment-16029675
 ] 

ASF subversion and git services commented on QPID-7801:
---

Commit ee97a9bdd9e2c3979e42c8c9158ae6f3aed201dc in qpid-broker-j's branch 
refs/heads/master from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ee97a9b ]

QPID-7801 : Allow substitution of address space (based on resolution of SNI / 
HTTPS HOST to vhost) in OAuth2 resolver URIs (to allow per vhost 
configuration).  Add keycloak provider


> [Java Broker] Allow variable substitution of virtualhost in OAuth2 resolver 
> URIs 
> -
>
> Key: QPID-7801
> URL: https://issues.apache.org/jira/browse/QPID-7801
> Project: Qpid
>  Issue Type: Improvement
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> Allow substitution of address space (based on resolution of SNI / HTTPS HOST 
> to vhost) in OAuth2 resolver URIs (to allow per vhost configuration).  Add 
> keycloak provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7801) [Java Broker] Allow variable substitution of virtualhost in OAuth2 resolver URIs

[Rob Godfrey (JIRA)]

Rob Godfrey created QPID-7801:
-

 Summary: [Java Broker] Allow variable substitution of virtualhost 
in OAuth2 resolver URIs 
 Key: QPID-7801
 URL: https://issues.apache.org/jira/browse/QPID-7801
 Project: Qpid
  Issue Type: Improvement
Reporter: Rob Godfrey
Assignee: Rob Godfrey


Allow substitution of address space (based on resolution of SNI / HTTPS HOST to 
vhost) in OAuth2 resolver URIs (to allow per vhost configuration).  Add 
keycloak provider



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (QPID-7757) [Java Broker Documentation] Improve Java Broker documentation about direct memory consumption by IO threads from port and virtual host pools

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029630#comment-16029630
 ] 

Keith Wall edited comment on QPID-7757 at 5/30/17 4:15 PM:
---

On reflection, the suggested detail is too low level and more likely to baffle 
the user. The user should be sizing the direct memory generously according to 
how many messages they wish the Broker to cache.  The existing detail supports 
this use-case.


was (Author: k-wall):
On reflection, the suggested detail is too low level and more likely to baffle 
the user. The user should be sizing the direct memory generously according to 
how many messages they wish the Broker to cache.

> [Java Broker Documentation] Improve Java Broker documentation about direct 
> memory consumption by IO threads from port and virtual host pools
> 
>
> Key: QPID-7757
> URL: https://issues.apache.org/jira/browse/QPID-7757
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Documentation
>Reporter: Alex Rudyy
> Attachments: 
> 0001-QPID-7757-Java-Broker-Documentation-Improve-Java-Bro.patch
>
>
> The current broker documentation does not provide any details about direct 
> memory consumption by IO threads from Port and Virtual Host pools. The Memory 
> section of documentation should be changed to include that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7757) [Java Broker Documentation] Improve Java Broker documentation about direct memory consumption by IO threads from port and virtual host pools

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7757.
--
Resolution: Not A Problem

On reflection, the suggested detail is too low level and more likely to baffle 
the user. The user should be sizing the direct memory generously according to 
how many messages they wish the Broker to cache.

> [Java Broker Documentation] Improve Java Broker documentation about direct 
> memory consumption by IO threads from port and virtual host pools
> 
>
> Key: QPID-7757
> URL: https://issues.apache.org/jira/browse/QPID-7757
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Documentation
>Reporter: Alex Rudyy
> Attachments: 
> 0001-QPID-7757-Java-Broker-Documentation-Improve-Java-Bro.patch
>
>
> The current broker documentation does not provide any details about direct 
> memory consumption by IO threads from Port and Virtual Host pools. The Memory 
> section of documentation should be changed to include that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (QPID-7616) VirtualHostNode name is not expanded before creating thread

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029596#comment-16029596
 ] 

Keith Wall edited comment on QPID-7616 at 5/30/17 3:55 PM:
---

Hi James How exactly are you reproducing this problem?  Running 6.1.1 out of 
the box and taking a thread dump shows me "VirtualHostNode-default-Config" so I 
wonder how exactly you are configuring the Broker.   Variable expansion is 
performed within the Broker's model core, so it surprises me when you say you 
see this inconsistently.


was (Author: k-wall):
Hi James How exactly are you reproducing this problem?  Running 6.1.1 out of 
the box and taking a thread dump shows me "VirtualHostNode-default-Config" so I 
wonder how exactly you are configuring the Broker.   Variable expansion is 
performed within the Broker's model core, so it surprises me when you say you 
see inconsistently.

> VirtualHostNode name is not expanded before creating thread
> ---
>
> Key: QPID-7616
> URL: https://issues.apache.org/jira/browse/QPID-7616
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: James Howe
>Priority: Trivial
>
> This results in, for example, a thread named 
> {{VirtualHostNode-$\{qpid.vhost\}-Config}}. Other threads have expanded the 
> parameter, e.g. {{virtualhost-default-receiver-pool-0}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7616) VirtualHostNode name is not expanded before creating thread

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029596#comment-16029596
 ] 

Keith Wall commented on QPID-7616:
--

Hi James How exactly are you reproducing this problem?  Running 6.1.1 out of 
the box and taking a thread dump shows me "VirtualHostNode-default-Config" so I 
wonder how exactly you are configuring the Broker.   Variable expansion is 
performed within the Broker's model core, so it surprises me when you say you 
see inconsistently.

> VirtualHostNode name is not expanded before creating thread
> ---
>
> Key: QPID-7616
> URL: https://issues.apache.org/jira/browse/QPID-7616
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1.1
>Reporter: James Howe
>Priority: Trivial
>
> This results in, for example, a thread named 
> {{VirtualHostNode-$\{qpid.vhost\}-Config}}. Other threads have expanded the 
> parameter, e.g. {{virtualhost-default-receiver-pool-0}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Lorenz Quack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack resolved QPID-7778.

Resolution: Fixed

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7606) Generalise Queue|Exchange#alternateExchange as alternateBinding

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7606:
-
Description: 
Queues and exchanges should have something akin to an "alternate binding" 
rather than an alternate exchange.  From this we can simplify the DLQ 
implementation to remove the need for DLEs (or at worst have a single DLE).

Alternate Bindings could be modelled as {{\{destination, arguments\}}}.  A 
supported argument might be {{replacementRoutingKey}} which if set could direct 
the routing through the alternate(s) (This is separate - see QPID-7771).

This work includes:

* changes to the model object themselves and the routing algorithms
* update the configuration upgrades to remap Exchange#alternativeExchange and 
Queue#alternativeExchange into the new model.
* the facility for automatic creation of a DLQ should be retained but it can be 
simplified to not create an DLE exchange.
* On upgrade, existing users' DLQ/DLEs must be retained as is, that is, there 
is no requirement to eliminate existing DLEs.  This is because we have no way 
to predict if the users made additional changes to these objects.



  was:
Queues and exchanges should have something akin to an "alternate binding" 
rather than an alternate exchange.  From this we can simplify the DLQ 
implementation to remove the need for DLEs (or at worst have a single DLE).

Alternate Bindings could be modelled as {{\{destination, arguments\}}}.  A 
supported argument might be {{replacementRoutingKey}} which if set could direct 
the routing through the alternate(s).



> Generalise Queue|Exchange#alternateExchange as alternateBinding
> ---
>
> Key: QPID-7606
> URL: https://issues.apache.org/jira/browse/QPID-7606
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Queues and exchanges should have something akin to an "alternate binding" 
> rather than an alternate exchange.  From this we can simplify the DLQ 
> implementation to remove the need for DLEs (or at worst have a single DLE).
> Alternate Bindings could be modelled as {{\{destination, arguments\}}}.  A 
> supported argument might be {{replacementRoutingKey}} which if set could 
> direct the routing through the alternate(s) (This is separate - see 
> QPID-7771).
> This work includes:
> * changes to the model object themselves and the routing algorithms
> * update the configuration upgrades to remap Exchange#alternativeExchange and 
> Queue#alternativeExchange into the new model.
> * the facility for automatic creation of a DLQ should be retained but it can 
> be simplified to not create an DLE exchange.
> * On upgrade, existing users' DLQ/DLEs must be retained as is, that is, there 
> is no requirement to eliminate existing DLEs.  This is because we have no way 
> to predict if the users made additional changes to these objects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (DISPATCH-778) qd_hash_internal_remove_item: Assertion `(bucket->items).size > 0' failed.

[Jiri Danek (JIRA)]

[ 
https://issues.apache.org/jira/browse/DISPATCH-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029559#comment-16029559
 ] 

Jiri Danek commented on DISPATCH-778:
-

I'll rerun the tests on a fast machine (not travis) and see if this is still 
there.

> qd_hash_internal_remove_item: Assertion `(bucket->items).size > 0' failed.
> --
>
> Key: DISPATCH-778
> URL: https://issues.apache.org/jira/browse/DISPATCH-778
> Project: Qpid Dispatch
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 1.0.0
> Environment: git tip of both proton and dispatch on debian testing
> {noformat}
> commit f7490003d3d88ee695cdbaaee887fb0c22a140a0
> Author: Andrew Stitcher 
> Date:   Fri May 19 09:54:00 2017 -0400
> NO-JIRA: Ensure _GNU_SOURCE & _POSIX_C_SOURCE are not redefined
> {noformat}
> {noformat}
> commit 8c9f4a581f7a62158d21bbe845edb3db60ae1d06
> Author: Ganesh Murthy 
> Date:   Tue May 16 11:25:39 2017 -0400
> NO-JIRA - Added extra documentation for the logMessage field. Thank you 
> Gordon Sim
> {noformat}
>Reporter: Jiri Danek
> Attachments: system_tests_two_routers.core.zip
>
>
> Reproducible essentially every time with the following command (although it 
> might take many iterations)
> {{ctest -VV -R system_tests_two_routers --repeat-until-fail 1000}}
> {noformat}
> test 27
>   Start 27: system_tests_two_routers
> 27: Test command: /usr/bin/python "/main/qpid-dispatch/build/tests/run.py" 
> "-m" "unittest" "-v" "system_tests_two_routers"
> 27: Test timeout computed to be: 1500
> 27: test_01_pre_settled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02a_multicast_unsettled (system_tests_two_routers.RouterTest) ... ok
> 27: test_02c_sender_settles_first (system_tests_two_routers.RouterTest) ... ok
> 27: test_03_propagated_disposition (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_04_unsettled_undeliverable (system_tests_two_routers.RouterTest) ... 
> ok
> 27: test_05_three_ack (system_tests_two_routers.RouterTest) ... ok
> 27: test_08_message_annotations (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_strip_message_annotations_custom 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_both_add_ingress_trace 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_in 
> (system_tests_two_routers.RouterTest) ... ok
> 27: test_08a_test_strip_message_annotations_no 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_no_add_trace 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_08a_test_strip_message_annotations_out_custom 
> (system_tests_two_routers.RouterTest) ... ERROR
> 27: test_09_management (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_10_semantics_multicast (system_tests_two_routers.RouterTest) ... 
> recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11a_semantics_closest_is_local (system_tests_two_routers.RouterTest) 
> ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_11b_semantics_closest_is_remote 
> (system_tests_two_routers.RouterTest) ... recv: Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_12_semantics_spread (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_13_to_override (system_tests_two_routers.RouterTest) ... recv: 
> Connection refused
> 27: send: Broken pipe
> 27: FAIL
> 27: test_14_excess_deliveries_released (system_tests_two_routers.RouterTest) 
> ... ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: ERROR:root:proton:io: recv: Connection refused
> 27: 

[jira] [Commented] (QPID-7605) [Java Broker] [AMQP1.0] Container id uniqueness

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029546#comment-16029546
 ] 

ASF subversion and git services commented on QPID-7605:
---

Commit 63b2806d552faa3fe2004b35bcf8a702671190e2 in qpid-broker-j's branch 
refs/heads/master from [~lorenz.quack]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=63b2806 ]

QPID-7605: [Java Broker] AMQP 1.0 support the soleconn AMQP extension

The standard is not finalised, yet. This reflects the WD02 status.


> [Java Broker] [AMQP1.0] Container id uniqueness
> ---
>
> Key: QPID-7605
> URL: https://issues.apache.org/jira/browse/QPID-7605
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 protocol layer implementation must ensure that the AMQP Open 
> performative container-id is unique amongst existing established connections.
> As the JMS client id maps to the container-id, so this will fulfil the JMS 
> requirement.  
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#setClientID-java.lang.String-
> Note that the Qpid JMS Client requires the Close performative with an Error 
> containing a hint to generate to correct JMS exception.  How will the Qpid 
> Broker know to do this?
> org.apache.qpid.jms.integration.FailedConnectionsIntegrationTest#testConnectWithInvalidClientIdThrowsICIDEWhenInvalidContainerHintPresent



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7778:
-
Priority: Minor  (was: Major)

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7778:
-
Status: Reviewable  (was: In Progress)

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029543#comment-16029543
 ] 

Keith Wall commented on QPID-7778:
--

Correct the client docbook.  I don't think this is worth back porting.

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029541#comment-16029541
 ] 

ASF subversion and git services commented on QPID-7778:
---

Commit aeb7377c8077d6873e896b04de527cbe2ed568ee in qpid-jms-amqp-0-x's branch 
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=aeb7377 ]

QPID-7778: [Documentation] State that JCE unlimited strength is required for 
message encryption feature


> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7778:
-
Fix Version/s: (was: qpid-java-broker-7.0.0)
   qpid-java-client-0-x-6.3.0

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7778) [Java Broker, Documentation] The Message encryption pages should mention that they require the Unlimited Strength JCE

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7778:
-
Component/s: Java Client

> [Java Broker, Documentation] The Message encryption pages should mention that 
> they require the Unlimited Strength JCE
> -
>
> Key: QPID-7778
> URL: https://issues.apache.org/jira/browse/QPID-7778
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client, Java Documentation
>Reporter: Lorenz Quack
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> Currently the documentation mentions the Unlimited Strength JCE in a couple 
> of places:
> * Installation: Generically mentions that some features may require it
> * Configuration Encryption: Explicitly mentions that it is needed for the 
> feature
> * Kerberos Auth Provider: Mentions that you may need it.
> We should add a note to the Message Encryption chapter that the Unlimited 
> Strength JCE is a prerequisite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (QPID-7782) [Java Broker] [AMQP1.0] NPE on connection when no default virtualhost exists

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029481#comment-16029481
 ] 

Keith Wall edited comment on QPID-7782 at 5/30/17 2:28 PM:
---

{{AMQPConnection_1_0Impl#receiveOpen}} is correctly identifying the fact that 
the virtualhost is unidentified and is organising for the {{amqp:not-found}} 
but it is not discarding frames that arrive after the open is returned but 
before the close is received {{AMQPConnection_1_0Impl.java:1081}}. I notice 
that the handling of connection state looks confused:  AWAITING_OPEN is unused, 
_closedOnOpen seems to have lost is reason for being.

I think the same problem will existing if ACL permissions for the virtualhost 
are denied.



was (Author: k-wall):
{{AMQPConnection_1_0Impl#receiveOpen}} is correctly identifying the fact that 
the virtualhost is unidentified and is organising for the {{amqp:not-found}} 
but it is not discarding frames that arrive after the open is returned but 
before the close is received {{AMQPConnection_1_0Impl.java:1081}}. I notice 
that the handling of connection state looks confused:  AWAITING_OPEN is unused, 
_closedOnOpen seems to have lost is reason for being.


> [Java Broker] [AMQP1.0] NPE on connection when no default virtualhost exists
> 
>
> Key: QPID-7782
> URL: https://issues.apache.org/jira/browse/QPID-7782
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The following NPE was encountered on connection when no default virtualhost 
> existed on the Broker and no virtualhost specified by the client.  Broker did 
> not crash.
>  
> {noformat}
> 2017-05-12 15:46:46,988 WARN  [IO-/127.0.0.1:37166] 
> (o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame
> java.lang.NullPointerException: null
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.getPrimaryDomain(Session_1_0.java:1608)
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.(Session_1_0.java:185)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveBegin(AMQPConnection_1_0Impl.java:625)
>   at 
> org.apache.qpid.server.protocol.v1_0.type.transport.Begin.invoke(Begin.java:229)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:320)
>   at 
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:176)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$9.run(AMQPConnection_1_0Impl.java:1235)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1208)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:130)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:593)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:483)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
>   at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
>   at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7782) [Java Broker] [AMQP1.0] NPE on connection when no default virtualhost exists

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029481#comment-16029481
 ] 

Keith Wall commented on QPID-7782:
--

{{AMQPConnection_1_0Impl#receiveOpen}} is correctly identifying the fact that 
the virtualhost is unidentified and is organising for the {{amqp:not-found}} 
but it is not discarding frames that arrive after the open is returned but 
before the close is received {{AMQPConnection_1_0Impl.java:1081}}. I notice 
that the handling of connection state looks confused:  AWAITING_OPEN is unused, 
_closedOnOpen seems to have lost is reason for being.


> [Java Broker] [AMQP1.0] NPE on connection when no default virtualhost exists
> 
>
> Key: QPID-7782
> URL: https://issues.apache.org/jira/browse/QPID-7782
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The following NPE was encountered on connection when no default virtualhost 
> existed on the Broker and no virtualhost specified by the client.  Broker did 
> not crash.
>  
> {noformat}
> 2017-05-12 15:46:46,988 WARN  [IO-/127.0.0.1:37166] 
> (o.a.q.s.p.v.f.FrameHandler) - Unexpected exception handling frame
> java.lang.NullPointerException: null
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.getPrimaryDomain(Session_1_0.java:1608)
>   at 
> org.apache.qpid.server.protocol.v1_0.Session_1_0.(Session_1_0.java:185)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receiveBegin(AMQPConnection_1_0Impl.java:625)
>   at 
> org.apache.qpid.server.protocol.v1_0.type.transport.Begin.invoke(Begin.java:229)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receive(AMQPConnection_1_0Impl.java:320)
>   at 
> org.apache.qpid.server.protocol.v1_0.framing.FrameHandler.parse(FrameHandler.java:176)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$9.run(AMQPConnection_1_0Impl.java:1235)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at 
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.received(AMQPConnection_1_0Impl.java:1208)
>   at 
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:130)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:593)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:483)
>   at 
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
>   at 
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
>   at 
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
>   at 
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
>   at 
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPIDJMS-295) AMQP property content-encoding cannot be retrieved via JMS_AMQP_ContentEncoding

[Leo Riguspi (JIRA)]

Leo Riguspi created QPIDJMS-295:
---

 Summary: AMQP property content-encoding cannot be retrieved via 
JMS_AMQP_ContentEncoding
 Key: QPIDJMS-295
 URL: https://issues.apache.org/jira/browse/QPIDJMS-295
 Project: Qpid JMS
  Issue Type: Bug
  Components: qpid-jms-client
Affects Versions: 0.23.0
Reporter: Leo Riguspi


The AMQP property content-encoding can be set but not retrieved:

1. Create a message and set the vendor property JMS_AMQP_ContentEncoding=gzip 
using QPid JMS
2. Send the message to an ActiveMQ broker via AMQP 1.0 with 
transport.transformer=jms (native does not work!)
3. Retrieve the message with QPid JMS: the property JMS_AMQP_ContentEncoding 
does not exist anymore in the message and there seem to be no other way of 
retrieving the content-encoding. 

Note that when consuming the same message with a python client the property 
seems to be set and accessible via the message.content_encoding field.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7724) [Java Broker] update optional BDB store to use version 7.3.7 of BDB JE

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029433#comment-16029433
 ] 

Keith Wall commented on QPID-7724:
--

Answering my own comment above, the TLS feature for HA seems to be experimental 
code.  It is annotated so that it is omitted from the documentation, so I guess 
it is not ready for the prime time.   

Separately, we could consider switching the default persistent store from Derby 
to BDB.

> [Java Broker] update optional BDB store to use version 7.3.7 of BDB JE 
> ---
>
> Key: QPID-7724
> URL: https://issues.apache.org/jira/browse/QPID-7724
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7724-Upgrade-Berkeley-DB-JE-from-5.0.14-to-7.3..patch
>
>
> Upgrade to the latest BDB JE release. With this release,  Oracle have changed 
> the licence to Apache License 2.0, so we should begin to bundle BDB in the 
> same way we already do for Derby.   
> https://docs.oracle.com/cd/E17277_02/html/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7762) Add ability to turn off flow to disk

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7762.
--
Resolution: Fixed

> Add ability to turn off flow to disk
> 
>
> Key: QPID-7762
> URL: https://issues.apache.org/jira/browse/QPID-7762
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently we don't have a way to turn off the flow to disk feature.  It is 
> useful for experimentation purposes to be able to switch it off. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7762) Add ability to turn off flow to disk

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029423#comment-16029423
 ] 

Keith Wall commented on QPID-7762:
--

Addressed by QPID-7775.

> Add ability to turn off flow to disk
> 
>
> Key: QPID-7762
> URL: https://issues.apache.org/jira/browse/QPID-7762
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently we don't have a way to turn off the flow to disk feature.  It is 
> useful for experimentation purposes to be able to switch it off. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-6653) Earlier Qpid Java client: receiver issue with multi-transfer pre-settled messages

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-6653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029408#comment-16029408
 ] 

Keith Wall commented on QPID-6653:
--

I don't think the use-case is legal.   The AMQP specification (2.6.12) says 
"The delivery-tag MUST be unique amongst all deliveries that could be 
considered unsettled by either end of the link."I can see that the Broker 
doesn't currently validate that this is the case.

> Earlier Qpid Java client: receiver issue with multi-transfer pre-settled 
> messages
> -
>
> Key: QPID-6653
> URL: https://issues.apache.org/jira/browse/QPID-6653
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.32
>Reporter: Xin Chen
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: ReceivingLinkEndpoint.java
>
>
> This issue is regarding the Qpid Java client released as part of the Qpid JMS 
> 0.32. https://qpid.apache.org/releases/qpid-0.32/index.html
> When the remote peer sends settled message with multiple transfer frames, it 
> could use the same delivery tag (e.g. an empty binary) for all messages. The 
> ReceivingLinkEndpoint class keeps track of both unsettled deliveries and 
> partially received deliveries in two maps, _unsettledIds and _unsettledMap. 
> When user acknowledges a message by calling Receiver.acknowledge(Message), 
> the state of the delivery is removed from both maps. This is causing a 
> problem if the user acknowledges a previously received message and a new 
> message is being partially received (because they share the same delivery 
> tag). The observed symptom is receiver stuck and NullPointerException from 
> connection's frame pump when decoding frame buffers.
> I attempted a fix by using a new variable to remember the last received 
> partial delivery, if any, and only putting unsettled deliveries into the two 
> maps. It worked in this particular scenario. The existing tests are passing 
> with this change but I am not completely sure if it has any side effects.
> I will attach a modified ReceivingLinkEndpoint.Java file so you can take a 
> look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7345) [Java Broker] Remove support for ACL checking based on the "immediate" flag

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-7345.
--
Resolution: Fixed

The changes look good to me

> [Java Broker] Remove support for ACL checking based on the "immediate" flag
> ---
>
> Key: QPID-7345
> URL: https://issues.apache.org/jira/browse/QPID-7345
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Rob Godfrey
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> QPID-7344 deals with deprecating the use of ACL checking on the "immediate" 
> flag in version 6.1.  For subsequent releases the feature should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7345) [Java Broker] Remove support for ACL checking based on the "immediate" flag

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029400#comment-16029400
 ] 

ASF subversion and git services commented on QPID-7345:
---

Commit 8b76ea6d5b4c872a7a017b4dfe62e5db51f9d656 in qpid-broker-j's branch 
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8b76ea6 ]

QPID-7345: [Java Broker] Remove mentioning of "immediate" flag from ACL 
documentation


> [Java Broker] Remove support for ACL checking based on the "immediate" flag
> ---
>
> Key: QPID-7345
> URL: https://issues.apache.org/jira/browse/QPID-7345
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Rob Godfrey
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> QPID-7344 deals with deprecating the use of ACL checking on the "immediate" 
> flag in version 6.1.  For subsequent releases the feature should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7751) [Java Broker] Login attempt using SimpleLDAP might result in 500

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7751.
--
Resolution: Fixed

> [Java Broker] Login attempt using SimpleLDAP might result in 500
> 
>
> Key: QPID-7751
> URL: https://issues.apache.org/jira/browse/QPID-7751
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configure SimpleLDAP on a port and attempt an invalid login in the web 
> management console results in a 500 (in HTML) being returned to the browser.
> The broker log contains the following stacktrace:
> {noformat}
> 2017-04-21 09:18:07,269 INFO  [HttpManagement-ldap-269] 
> (q.m.a.authentication_failed) - [mng:mp1XixiX(N/A@/0:0:0:0:0:0:0:1:52604)] 
> ATH-1010 : Authentication Failed : "invalid_user"
> 2017-04-21 09:18:07,270 ERROR [HttpManagement-ldap-269] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/service/sasl': 
> java.lang.IllegalStateException: null
>   at 
> org.eclipse.jetty.server.session.AbstractSession.checkValid(AbstractSession.java:109)
>   at 
> org.eclipse.jetty.server.session.HashedSession.checkValid(HashedSession.java:73)
>   at 
> org.eclipse.jetty.server.session.AbstractSession.getAttribute(AbstractSession.java:132)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.cleanup(SaslServlet.java:205)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:288)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:158)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:141)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:370)
>   at 
> 

[jira] [Resolved] (QPID-7191) AMQP 1.0 include tests that exercises topic with no subscribers

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-7191.
--
Resolution: Fixed

The implemented test looks good to me

> AMQP 1.0 include tests that exercises topic with no subscribers
> ---
>
> Key: QPID-7191
> URL: https://issues.apache.org/jira/browse/QPID-7191
> Project: Qpid
>  Issue Type: Test
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> As highlighted by the following thread, we currently have no test case that 
> exercises zero subscribers for a topic covering AMQP 1.0.
> http://qpid.2158936.n2.nabble.com/Unroutable-messages-in-Java-Qpid-Broker-6-0-0-td7641320.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7800) [Java Broker] Refactor Port classes to remove unnecessary intermediate classes/interfaces

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029377#comment-16029377
 ] 

ASF subversion and git services commented on QPID-7800:
---

Commit 9baae38e5b673c3384f7dde5072cbc6e8436e1bf in qpid-broker-j's branch 
refs/heads/master from [~godfrer]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=9baae38 ]

QPID-7800 - [Java Broker] Refactor Port classes to remove unnecessary 
intermediate classes/interfaces


> [Java Broker] Refactor Port classes to remove unnecessary intermediate 
> classes/interfaces
> -
>
> Key: QPID-7800
> URL: https://issues.apache.org/jira/browse/QPID-7800
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>
> For historical reasons (related to JMX/RMI) the Port class has sb-interfaces 
> and an abstract class hierarchy to allow for port types which do not support 
> authentication providers or TLS client auth.  Now the Broker supports only 
> AMQP and HTTP all port types support both TLS client auth (and require 
> authentication providers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7800) [Java Broker] Refactor Port classes to remove unnecessary intermediate classes/interfaces

[Rob Godfrey (JIRA)]

Rob Godfrey created QPID-7800:
-

 Summary: [Java Broker] Refactor Port classes to remove unnecessary 
intermediate classes/interfaces
 Key: QPID-7800
 URL: https://issues.apache.org/jira/browse/QPID-7800
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Rob Godfrey
Assignee: Rob Godfrey


For historical reasons (related to JMX/RMI) the Port class has sb-interfaces 
and an abstract class hierarchy to allow for port types which do not support 
authentication providers or TLS client auth.  Now the Broker supports only AMQP 
and HTTP all port types support both TLS client auth (and require 
authentication providers).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7540) [Java Broker] The broker cannot recover durable Consumers (AMQP 1.0) which leaves it in an ERRORed state

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029360#comment-16029360
 ] 

Keith Wall commented on QPID-7540:
--

Resolved by QPID-7658 and associated JIRAs.

> [Java Broker] The broker cannot recover durable Consumers (AMQP 1.0) which 
> leaves it in an ERRORed state
> 
>
> Key: QPID-7540
> URL: https://issues.apache.org/jira/browse/QPID-7540
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> When creating a durable Consumer with AMQP 1.0 it will be persisted in the 
> broker configuration.
> However, upon recovery the Session is not available to the Consumer cannot be 
> created leading to an error.
> It is unclear how we should handle durable Consumers but leaving the broker 
> in an unrecoverable state is clearly undesirable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7540) [Java Broker] The broker cannot recover durable Consumers (AMQP 1.0) which leaves it in an ERRORed state

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7540.
--
Resolution: Fixed

> [Java Broker] The broker cannot recover durable Consumers (AMQP 1.0) which 
> leaves it in an ERRORed state
> 
>
> Key: QPID-7540
> URL: https://issues.apache.org/jira/browse/QPID-7540
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> When creating a durable Consumer with AMQP 1.0 it will be persisted in the 
> broker configuration.
> However, upon recovery the Session is not available to the Consumer cannot be 
> created leading to an error.
> It is unclear how we should handle durable Consumers but leaving the broker 
> in an unrecoverable state is clearly undesirable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7750) [Java Broker] NPE in AbstractQueue#getOldestMessageArrivalTime when Queue was not opened

[Alex Rudyy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Rudyy resolved QPID-7750.
--
Resolution: Fixed

The tactical fix looks reasonable to me. Closing this JIRA

> [Java Broker] NPE in AbstractQueue#getOldestMessageArrivalTime when Queue was 
> not opened
> 
>
> Key: QPID-7750
> URL: https://issues.apache.org/jira/browse/QPID-7750
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> There is a possibility of a NullPointerException in 
> {{AbstractQueue#getOldestMessageArrivalTime}} when the queue has not been 
> opened the entry list is {{null}}:
> {noformat}
> 2017-04-18 11:11:45,817 ERROR [HttpManagement-https-124] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/api/latest/virtualhost/default/default': 
> java.lang.NullPointerException: null
>   at 
> org.apache.qpid.server.queue.AbstractQueue.getOldestMessageArrivalTime(AbstractQueue.java:1406)
>   at 
> org.apache.qpid.server.queue.AbstractQueue.getOldestMessageAge(AbstractQueue.java:1444)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
>   at 
> org.apache.qpid.server.model.ConfiguredObjectMethodStatistic.getValue(ConfiguredObjectMethodStatistic.java:26)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.getStatistics(AbstractConfiguredObject.java:3159)
>   at 
> org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getStatistics(StandardQueueImplWithAccessChecking.java:46)
>   at 
> org.apache.qpid.server.model.AbstractConfiguredObject.getStatistics(AbstractConfiguredObject.java:3146)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateStatisticsIntoMap(ConfiguredObjectToMapConverter.java:218)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:65)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:303)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:123)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:396)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> 

[jira] [Commented] (QPID-7649) [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029357#comment-16029357
 ] 

Rob Godfrey commented on QPID-7649:
---

That covers the case for an incoming attach - is there a separate JIRA for the 
case of a resumed link where the local (server side) unsettled map is too large 
to fit in a single attach frame?

> [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true
> 
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete 
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful 
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7634) [Java Broker,amqp 1.0] Broker does not respond to Flow command with drain=true if queue is empty and prefetch is 0

[Lorenz Quack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack resolved QPID-7634.

Resolution: Fixed

> [Java Broker,amqp 1.0] Broker does not respond to Flow command with 
> drain=true if queue is empty and prefetch is 0
> --
>
> Key: QPID-7634
> URL: https://issues.apache.org/jira/browse/QPID-7634
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.1, qpid-java-6.1.1, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> When AMQP 1.0 client sends the Flow command with drain=true and queue is 
> empty the Broker does not respond if prefetch is 0.
> The following snippet reproduces the issue
> {code}
> Connection connection = factory.createConnection(username, password);
> connection.start();
> Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> MessageConsumer messageConsumer = session.createConsumer(queue);
> TextMessage receivedMessage = (TextMessage) messageConsumer.receiveNoWait(); 
> // <-- times out
> {code}
> The broker logs
> {noformat}
> 2017-01-24 11:05:56,471 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=receiver,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue, global]},target=Target{}}
> 2017-01-24 11:05:56,474 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['add consumer' on 'queue' 
> with arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.m.AbstractConfiguredObject) - authorise returned DEFER, returing 
> default: ALLOWED
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Performing Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]']
> 2017-01-24 11:05:56,475 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['open' on 
> 'Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]'] performed successfully with result: null
> 2017-01-24 11:05:56,476 INFO  [VirtualHostNode-default-Config] (q.m.s.create) 
> - [con:7(admin@/127.0.0.1:51108/default)/ch:1] [sub:7(vh(/default)/qu(queue)] 
> SUB-1001 : Create
> 2017-01-24 11:05:56,476 DEBUG [VirtualHostNode-default-Config] 
> (o.a.q.s.c.u.TaskExecutorImpl) - Task['add consumer' on 'queue' with 
> arguments 
> 'target=ConsumerTarget_1_0[linkSession=[con:7(admin@/127.0.0.1:51108/default)/ch:1]
>  ], 
> consumerName=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  optionSet=[ACQUIRES, SEES_REQUEUES]'] performed successfully with result: 
> Consumer[id=164b1b27-176a-42a3-a5dc-613d97bc58b2, 
> name=7|1|qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,
>  type=Consumer]
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> SEND[/127.0.0.1:51108|1] : 
> Attach{name=qpid-jms:receiver:ID:20aa7189-d399-472d-a8ce-aa8b7a3bef75:1:1:1:queue,handle=1,role=sender,sndSettleMode=unsettled,rcvSettleMode=first,source=Source{address=queue,durable=none,expiryPolicy=link-detach,timeout=0,dynamic=false,defaultOutcome=Modified{deliveryFailed=true},outcomes=[amqp:accepted:list,
>  amqp:rejected:list, amqp:released:list, 
> amqp:modified:list],capabilities=[queue]},target=Target{},initialDeliveryCount=0,offeredCapabilities=[SHARED-SUBS],properties={}}
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Written 251 bytes
> 2017-01-24 11:05:56,477 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Read 0 byte(s)
> 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] 
> (o.a.q.s.t.NonBlockingConnection) - Read 34 byte(s)
> 2017-01-24 11:05:56,487 DEBUG [IO-/127.0.0.1:51108] (o.a.q.s.p.frame) - 
> RECV[/127.0.0.1:51108|1] : 
> 

[jira] [Resolved] (QPID-7738) [Qpid JMS AMQP 0-x Client] Migrate qpid-java svn to git

[Lorenz Quack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lorenz Quack resolved QPID-7738.

Resolution: Fixed

the repo was migrated to git and the svn repo is no longer maintained

> [Qpid JMS AMQP 0-x Client] Migrate qpid-java svn to git 
> 
>
> Key: QPID-7738
> URL: https://issues.apache.org/jira/browse/QPID-7738
> Project: Qpid
>  Issue Type: Task
>  Components: Java Client
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: qpid-java-client-0-x-6.3.0
>
>
> The Qpid Broker for Java and the 0-x Qpid JMS Client are the last two 
> components that use SVN.  We should migrate from to GIT.   This will simplify 
> the site.
> Related vote thread:
> http://qpid.2158936.n2.nabble.com/RESULT-VOTE-Migrate-Qpid-Broker-J-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7662060.html
> Release discuss thread:
> http://qpid.2158936.n2.nabble.com/DISCUSS-Migrate-Qpid-Broker-for-Java-and-Qpid-JMS-AMQP-0-x-Client-from-SVN-to-GIT-tt7661505.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7649) [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029352#comment-16029352
 ] 

Keith Wall commented on QPID-7649:
--

Given this feature is not yet utilised, for v7.0 we will simply close the 
connection which an appropriate error message if a link attach with 
{{incomplete-unsettled=true}} is received.

> [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true
> 
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete 
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful 
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Updated] (QPID-7799) Broker should be able to write a period dump of statistics

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7799:
-
Fix Version/s: qpid-java-broker-7.0.0

> Broker should be able to write a period dump of statistics
> --
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7799) Broker should be able to write a period dump of statistics

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029329#comment-16029329
 ] 

Keith Wall commented on QPID-7799:
--

Recent work on flow to disk exposed this requirement.   We have a statistic 
that tracks the quantity of messages that have been flowed to disk as a 
statistic but have no way to materialise this information to the log.   If we 
have a general mechanism that could log any stat, this would answer this need 
too.

> Broker should be able to write a period dump of statistics
> --
>
> Key: QPID-7799
> URL: https://issues.apache.org/jira/browse/QPID-7799
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> To assist those running a service, the Broker should have the ability to 
> write a periodic dump of ConiguredObject statistics to the log file.   It 
> should be possible to configure the statistics dumped at runtime and be 
> configured on a per-category or per-object instance basis.   Within a HA 
> group, the configuration applied to objects belonging to a virtualhost must 
> survive a mastership change.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7649) [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true

[Rob Godfrey (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029330#comment-16029330
 ] 

Rob Godfrey commented on QPID-7649:
---

{quote}
It is not clear to me if "Note that if this flag is set to true then the 
endpoints MUST detach and reattach at least once in order to send new 
deliveries." means that the Broker is required to send a detach after actioning 
the unsettled map.
{quote}
The quote from the spec is simply stating the implications of the definition.  
Since new deliveries can't be sent until all unsettled state has been 
exchanged, and the unsettled state could not be exchanged in a single attach 
frame, then at least one more attach frame is needed, which will require a 
detach/reattach.  As an implementation strategy having the server detach 
automatically might seem sensible, but I don't believe it is required.  Having 
said that I think the only way to implement this without having to deal with 
weird stuff like a simultaneous attempt at link stealing, would be to have the 
server simply keep sending attach-detach pairs until the point at which all the 
unsettled map has been sent, whereupon the last attach will have 
incomplete-unsettled=false


> [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true
> 
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete 
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful 
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7799) Broker should be able to write a period dump of statistics

[Keith Wall (JIRA)]

Keith Wall created QPID-7799:


 Summary: Broker should be able to write a period dump of statistics
 Key: QPID-7799
 URL: https://issues.apache.org/jira/browse/QPID-7799
 Project: Qpid
  Issue Type: Improvement
  Components: Java Broker
Reporter: Keith Wall


To assist those running a service, the Broker should have the ability to write 
a periodic dump of ConiguredObject statistics to the log file.   It should be 
possible to configure the statistics dumped at runtime and be configured on a 
per-category or per-object instance basis.   Within a HA group, the 
configuration applied to objects belonging to a virtualhost must survive a 
mastership change.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Created] (QPID-7798) [Java Broker] AMQP Management Operation throws NPE when it cannot find the target object

[Lorenz Quack (JIRA)]

Lorenz Quack created QPID-7798:
--

 Summary: [Java Broker] AMQP Management Operation throws NPE when 
it cannot find the target object
 Key: QPID-7798
 URL: https://issues.apache.org/jira/browse/QPID-7798
 Project: Qpid
  Issue Type: Bug
  Components: Java Broker
Reporter: Lorenz Quack
 Fix For: qpid-java-broker-7.0.0


If a management operation is requested on a non-existing object 
{{ManagementNode#performConfiguredObjectOperation}} throws a 
{{NullPointerException}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Comment Edited] (QPID-7649) [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029259#comment-16029259
 ] 

Keith Wall edited comment on QPID-7649 at 5/30/17 10:59 AM:


Currently, the consumer target created by the sending link does not know that 
it "MUST NOT send any new deliveries" (2.7.3 - attach), so it will violate the 
spec and the peer will be obliged to detach.   We need a way to tell the 
consumer target not to deliver anything (perhaps an additional clause 
({{ConsumerTarget_1_0#allocateCredit}}) to consider that incomplete-unsettled 
flag.

It is not clear to me if "Note that if this flag is set to true then the 
endpoints MUST detach and reattach at least once in order to send new 
deliveries."  means that the Broker is required to send a detach after 
actioning the unsettled map.

Separately, it strikes me we could defer the implementation of this part of the 
spec for a later release.  If we were to take this approach, the minimum change 
would be to fail gracefully (i.e. close the connection) if we were to encounter 
a peer that passed a {{incomplete-unsettled=true}}




was (Author: k-wall):
Currently, the consumer target created by the sending link does not know that 
it "MUST NOT send any new deliveries" (2.7.3 - attach), so it will violate the 
spec and the peer will be obliged to detach.   We need a way to tell the 
consumer target not to deliver anything (perhaps an additional clause 
({{ConsumerTarget_1_0#allocateCredit}}) to consider that incomplete-unsettled 
flag.

It is not clear to me if "Note that if this flag is set to true then the 
endpoints MUST detach and reattach at least once in order to send new 
deliveries."  means that the Broker is required to detach after actioning the 
unsettled map.



> [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true
> 
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete 
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful 
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7649) [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029259#comment-16029259
 ] 

Keith Wall commented on QPID-7649:
--

Currently, the consumer target created by the sending link does not know that 
it "MUST NOT send any new deliveries" (2.7.3 - attach), so it will violate the 
spec and the peer will be obliged to detach.   We need a way to tell the 
consumer target not to deliver anything (perhaps an additional clause 
({{ConsumerTarget_1_0#allocateCredit}}) to consider that incomplete-unsettled 
flag.

It is not clear to me if "Note that if this flag is set to true then the 
endpoints MUST detach and reattach at least once in order to send new 
deliveries."  means that the Broker is required to detach after actioning the 
unsettled map.



> [Java Broker] Support AMQP 1.0 Attach with incomplete-unsettled=true
> 
>
> Key: QPID-7649
> URL: https://issues.apache.org/jira/browse/QPID-7649
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Reporter: Lorenz Quack
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 spec (2.7.3) allows to send an Attach with an incomplete 
> {{unsettled}} map together with {{incomplete-unsettled=true}}. This is useful 
> in cases where the unsettled map is too large to fit in a single frame.
> We currently do not respect this, violating the spec.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Resolved] (QPID-7753) Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: Direct buffer memory

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7753.
--
Resolution: Fixed

> Sparsely occupied message buffers may lead to java.lang.OutOfMemoryError: 
> Direct buffer memory
> --
>
> Key: QPID-7753
> URL: https://issues.apache.org/jira/browse/QPID-7753
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: flow-to-disk-based-on-used-direct-memory-6-0-x.diff
>
>
> Some Broker usage patterns can lead to the Broker failing with a 
> "java.lang.OutOfMemoryError: Direct buffer memory" error.
> For the condition to manifest a producing application needs to use a single 
> connection for the production of messages. Some messages need to be consumed 
> quickly whilst others remain on the Broker. This pattern might result from:
> # the consuming application using message selectors to selectively consume 
> some messages whilst leaving others on the Broker.
> # the use of 'out of order' queue types (priority/sorted etc) where lower 
> priority items are left of the Broker.
> # the producing application routing messages to multiple queues and the 
> consuming application draining some queues but not others.
> The problem arises owing to the buffering strategy under the IO layer.
> {{NonBlockingConnection}} allocates a {{netInputBuffer}} from pooled direct 
> memory of size 256K.  This buffer is used for all network reads until the 
> space remaining in the buffer is less than the amount required to complete 
> the AMQP frame that is currently being read, in which case a new 
> netInputBuffer is allocated. The protocol layers identify the message 
> payload/message headers as part of AMQP frame parsing and create a 
> byte-buffer *views* onto the original input byte buffer.  This byte buffer is 
> retained by the store until the message is consumed.   In the usage pattern 
> described above, a single long lived message amongst a stream of shorted 
> lived messages causes an entire 256K buffer chunk to be retained.  Qpid 
> cannot dispose or reuse the buffer until it is entirely unoccupied.
> The flow to disk feature is designed to prevent excessive direct memory use 
> by flushing messages to disk if thresholds are breached.  Flow to disk does 
> not help the scenario described above because it considers the total payloads 
> of live messages.  Its algorithm does not consider direct memory occupancy.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[jira] [Commented] (QPID-7751) [Java Broker] Login attempt using SimpleLDAP might result in 500

[Keith Wall (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029223#comment-16029223
 ] 

Keith Wall commented on QPID-7751:
--

Accepted - I don't like the solution, but can't suggest something cleaner.

> [Java Broker] Login attempt using SimpleLDAP might result in 500
> 
>
> Key: QPID-7751
> URL: https://issues.apache.org/jira/browse/QPID-7751
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configure SimpleLDAP on a port and attempt an invalid login in the web 
> management console results in a 500 (in HTML) being returned to the browser.
> The broker log contains the following stacktrace:
> {noformat}
> 2017-04-21 09:18:07,269 INFO  [HttpManagement-ldap-269] 
> (q.m.a.authentication_failed) - [mng:mp1XixiX(N/A@/0:0:0:0:0:0:0:1:52604)] 
> ATH-1010 : Authentication Failed : "invalid_user"
> 2017-04-21 09:18:07,270 ERROR [HttpManagement-ldap-269] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/service/sasl': 
> java.lang.IllegalStateException: null
>   at 
> org.eclipse.jetty.server.session.AbstractSession.checkValid(AbstractSession.java:109)
>   at 
> org.eclipse.jetty.server.session.HashedSession.checkValid(HashedSession.java:73)
>   at 
> org.eclipse.jetty.server.session.AbstractSession.getAttribute(AbstractSession.java:132)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.cleanup(SaslServlet.java:205)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:288)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:158)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:141)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at 

[jira] [Updated] (QPID-7751) [Java Broker] Login attempt using SimpleLDAP might result in 500

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-7751:
-
Priority: Minor  (was: Major)

> [Java Broker] Login attempt using SimpleLDAP might result in 500
> 
>
> Key: QPID-7751
> URL: https://issues.apache.org/jira/browse/QPID-7751
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Lorenz Quack
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configure SimpleLDAP on a port and attempt an invalid login in the web 
> management console results in a 500 (in HTML) being returned to the browser.
> The broker log contains the following stacktrace:
> {noformat}
> 2017-04-21 09:18:07,269 INFO  [HttpManagement-ldap-269] 
> (q.m.a.authentication_failed) - [mng:mp1XixiX(N/A@/0:0:0:0:0:0:0:1:52604)] 
> ATH-1010 : Authentication Failed : "invalid_user"
> 2017-04-21 09:18:07,270 ERROR [HttpManagement-ldap-269] 
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet 
> '/service/sasl': 
> java.lang.IllegalStateException: null
>   at 
> org.eclipse.jetty.server.session.AbstractSession.checkValid(AbstractSession.java:109)
>   at 
> org.eclipse.jetty.server.session.HashedSession.checkValid(HashedSession.java:73)
>   at 
> org.eclipse.jetty.server.session.AbstractSession.getAttribute(AbstractSession.java:132)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.cleanup(SaslServlet.java:205)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.evaluateSaslResponse(SaslServlet.java:288)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.SaslServlet.doPost(SaslServlet.java:158)
>   at 
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doPost(AbstractServlet.java:141)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>   at 
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
>   at 
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
>   at 
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.doFilter(ExceptionHandlingFilter.java:59)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>   at org.eclipse.jetty.server.Server.handle(Server.java:370)
>   at 
> 

[jira] [Resolved] (QPID-7731) Upgrade to Jetty 9.4

[Keith Wall (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-7731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-7731.
--
Resolution: Fixed

Looks reasonable to me.

> Upgrade to Jetty 9.4
> 
>
> Key: QPID-7731
> URL: https://issues.apache.org/jira/browse/QPID-7731
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments: 
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, 
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch, 
> 0001-QPID-7731-HTTP-Management-Upgrade-Jetty-to-9.4.patch
>
>
> The version of Jetty used by the Java Broker is v8.1.  This is now marked as 
> EOL by the Jetty development team.  We should upgrade to Jetty v9.4 (an 
> option now we are on Java 8).   The Jetty API has changed substantially so 
> the HTTP Management is probably going to need a deep rewrite.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[GitHub] qpid-proton issue #105: Port of C++ binding to Proton Proactor

[astitcher]

Github user astitcher commented on the issue:

https://github.com/apache/qpid-proton/pull/105
  
I've now updated this with what I intend to be the final rebase before 
merging.

Everything is functionally there except for reconnect, which will be 
addressed in the 0.19 timescale.

* Multhtreaded container is now implemented
* The (still) experimental connection_driver now works.


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