[jira] [Updated] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bolz updated QPIDJMS-373: - Description: Add support for OAuth flow ("client_credentials" and "password") (-and setting of "Authorization" Header- moved into [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during WebSocket connection handshake. -Used "Authorization" Header or OAuth settings should/could be set via the "transport" parameters (TransportOptions).- (see above) As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] and have done one commit for the [add of the Authorization Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] and one commit for the [OAuth flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. Hope this feature is not only interesting for me. If yes, I will add the currently missing tests to my contribution and do a pull request. Regards, Michael was: Add support for OAuth flow ("client_credentials" and "password") and setting of "Authorization" Header during WebSocket connection handshake. Used "Authorization" Header or OAuth settings should/could be set via the "transport" parameters (TransportOptions). As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] and have done one commit for the [add of the Authorization Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] and one commit for the [OAuth flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. Hope this feature is not only interesting for me. If yes, I will add the currently missing tests to my contribution and do a pull request. Regards, Michael > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") (-and > setting of "Authorization" Header- moved into > [QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) during > WebSocket connection handshake. > -Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions).- (see above) > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427954#comment-16427954 ] Michael Bolz commented on QPIDJMS-373: -- Using some sort of callback was also an approach I had in mind but thought it would be to _clunky_ to add it in the current client architecture. But if you have ideas to do something in that way I volunteer to support you if wished. Based on our discussion and your comments we agree that adding the “Authorization” header as transport option is a valid feature. Hence I created a separate item ([QPIDJMS-375|https://issues.apache.org/jira/browse/QPIDJMS-375]) only for this (and removed that part from our current item). Hope this is okay. > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") and setting > of "Authorization" Header during WebSocket connection handshake. > Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions). > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.
[ https://issues.apache.org/jira/browse/QPIDJMS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427891#comment-16427891 ] ASF GitHub Bot commented on QPIDJMS-375: GitHub user mibo opened a pull request: https://github.com/apache/qpid-jms/pull/18 QPIDJMS-375: Added transport.ws.authorizationHeader option As described in the JIRA item: https://issues.apache.org/jira/browse/QPIDJMS-375 According tests will follow (however the {{NettyWsTransportTest}} and {{NettyEchoServer}} seems to fit not perfect for my test case). You can merge this pull request into a Git repository by running: $ git pull https://github.com/mibo/qpid-jms QPIDJMS-375 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/18.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 #18 commit 7c7703204209f2fef5cbbeda59f732a2983db7ba Author: miboDate: 2018-04-06T03:31:19Z QPIDJMS-375: Added transport.ws.authorizationHeader option > Enable setting of an "Authorization" Header during WebSocket connection > handshake. > -- > > Key: QPIDJMS-375 > URL: https://issues.apache.org/jira/browse/QPIDJMS-375 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for setting of an "Authorization" Header during WebSocket > connection handshake. > This "Authorization" Header will be passed via the "transport" parameters > (TransportOptions). > Proposed transport is {{transport.ws.authorizationHeader}}. > I will create a "Pull Request" and link it here. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.
[ https://issues.apache.org/jira/browse/QPIDJMS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bolz updated QPIDJMS-375: - Description: Add support for setting of an "Authorization" Header during WebSocket connection handshake. This "Authorization" Header will be passed via the "transport" parameters (TransportOptions). Proposed transport is {{transport.ws.authorizationHeader}}. According "[Pull Request|https://github.com/apache/qpid-jms/pull/18]; was: Add support for setting of an "Authorization" Header during WebSocket connection handshake. This "Authorization" Header will be passed via the "transport" parameters (TransportOptions). Proposed transport is {{transport.ws.authorizationHeader}}. I will create a "Pull Request" and link it here. > Enable setting of an "Authorization" Header during WebSocket connection > handshake. > -- > > Key: QPIDJMS-375 > URL: https://issues.apache.org/jira/browse/QPIDJMS-375 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for setting of an "Authorization" Header during WebSocket > connection handshake. > This "Authorization" Header will be passed via the "transport" parameters > (TransportOptions). > Proposed transport is {{transport.ws.authorizationHeader}}. > According "[Pull Request|https://github.com/apache/qpid-jms/pull/18]; -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms pull request #18: QPIDJMS-375: Added transport.ws.authorizationHead...
GitHub user mibo opened a pull request: https://github.com/apache/qpid-jms/pull/18 QPIDJMS-375: Added transport.ws.authorizationHeader option As described in the JIRA item: https://issues.apache.org/jira/browse/QPIDJMS-375 According tests will follow (however the {{NettyWsTransportTest}} and {{NettyEchoServer}} seems to fit not perfect for my test case). You can merge this pull request into a Git repository by running: $ git pull https://github.com/mibo/qpid-jms QPIDJMS-375 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/18.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 #18 commit 7c7703204209f2fef5cbbeda59f732a2983db7ba Author: miboDate: 2018-04-06T03:31:19Z QPIDJMS-375: Added transport.ws.authorizationHeader option --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-375) Enable setting of an "Authorization" Header during WebSocket connection handshake.
Michael Bolz created QPIDJMS-375: Summary: Enable setting of an "Authorization" Header during WebSocket connection handshake. Key: QPIDJMS-375 URL: https://issues.apache.org/jira/browse/QPIDJMS-375 Project: Qpid JMS Issue Type: New Feature Components: qpid-jms-client Reporter: Michael Bolz Add support for setting of an "Authorization" Header during WebSocket connection handshake. This "Authorization" Header will be passed via the "transport" parameters (TransportOptions). Proposed transport is {{transport.ws.authorizationHeader}}. I will create a "Pull Request" and link it here. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1805) [MacOS] Fuzzer issues in fuzz-connection-driver & fuzz-message-decode
[ https://issues.apache.org/jira/browse/PROTON-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427818#comment-16427818 ] Roddie Kieley commented on PROTON-1805: --- [~gemmellr] That's interesting re: the os version discrepancy and could be an issue. [~astitcher] I previously had indeed tested with FUZZ_LONG_TESTS ON but tested again tonight without it ON and do not see SegFaults but see that the fuzz tests pass. {code:java} . . . 27: Test command: /Users/rkieley/LocalProjects/apache/qp-040518-0/proton-c/src/tests/fuzz/fuzz-sniff-header 27: Test timeout computed to be: 1500 27: StandaloneFuzzTargetMain: running 0 inputs 4/4 Test #27: fuzz-sniff-header Passed 0.01 sec The following tests passed: fuzz-connection-driver fuzz-message-decode fuzz-url fuzz-sniff-header 100% tests passed, 0 tests failed out of 4 Total Test time (real) = 0.75 sec {code} Ran ctest -VV -R fuzz a few times to see if it would change but the result was consistent. > [MacOS] Fuzzer issues in fuzz-connection-driver & fuzz-message-decode > - > > Key: PROTON-1805 > URL: https://issues.apache.org/jira/browse/PROTON-1805 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Priority: Major > Labels: fuzzer, mac-os-x, osx > > Introducing the fuzz tester has shown up a couple of segvs in the MacOS port. > for fuzz-connection-driver: > {noformat} > 26: Running: > /Users/travis/build/astitcher/qpid-proton/proton-c/src/tests/fuzz/fuzz-connection-driver/corpus/7e51d07e16f84d001a8be4a1dedf556b3b16720c > 26/34 Test #26: fuzz-connection-driver ...***Exception: SegFault > 1.76 sec{noformat} > and for fuzz-message-decode: > {noformat} > 27: Running: > /Users/travis/build/astitcher/qpid-proton/proton-c/src/tests/fuzz/fuzz-message-decode/corpus/d5143aaeea6897d4264440017cd47ebc874f4440 > 27/34 Test #27: fuzz-message-decode ..***Exception: SegFault > 1.97 sec{noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid for Java 6.1.6 released
The Apache Qpid (https://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid for Java 6.1.6. This release addresses defects and enhancements in Qpid Broker-J (previously known as Qpid Broker for Java). The release is available now from our website: https://qpid.apache.org/releases/qpid-java-6.1.6/index.html Binaries are also available via Maven Central: https://qpid.apache.org/maven.html Release notes can be found at: https://qpid.apache.org/releases/qpid-java-6.1.6/release-notes.html Thanks to all involved, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Broker-J 7.0.3 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Broker-J 7.0.3. This release addresses defects and enhancements in Qpid Broker-J The release is available now from our website: https://qpid.apache.org/download.html Release notes can be found at: https://qpid.apache.org/releases/qpid-broker-j-7.0.3/release-notes.html Qpid Broker-J 7.0.3 release page can be found here: https://qpid.apache.org/releases/qpid-broker-j-7.0.3/index.html Thanks to all involved, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"
[ https://issues.apache.org/jira/browse/DISPATCH-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-952. Resolution: Fixed > qdrouterd seg fault after reporting "too many sessions" > --- > > Key: DISPATCH-952 > URL: https://issues.apache.org/jira/browse/DISPATCH-952 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Reporter: Alan Conway >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876] > > {code:java} > Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 > capsules: > Capsule 1: 3K clients > Capsule 2: 2K clients > Logs from Capsule 1: > [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/gshadow: name=qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: new group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, > home=/var/lib/qdrouterd, shell=/sbin/nologin > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: > qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 > error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000] > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > /usr/sbin/katello-service[1740]: *** status failed: qdrouterd *** > Logs from Capsule 2: > [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd > ● qdrouterd.service - Qpid Dispatch router daemon >Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor > preset: disabled) > Drop-In: /etc/systemd/system/qdrouterd.service.d >└─limits.conf >Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago > Process: 1158 ExecStart=/usr/sbin/qdrouterd -c > /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV) > Main PID: 1158 (code=killed, signal=SEGV) > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Started Qpid Dispatch router daemon. > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Starting Qpid Dispatch router daemon... > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel > within limit of 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:process error -2 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"
[ https://issues.apache.org/jira/browse/DISPATCH-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427578#comment-16427578 ] ASF GitHub Bot commented on DISPATCH-952: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/280 > qdrouterd seg fault after reporting "too many sessions" > --- > > Key: DISPATCH-952 > URL: https://issues.apache.org/jira/browse/DISPATCH-952 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Reporter: Alan Conway >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876] > > {code:java} > Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 > capsules: > Capsule 1: 3K clients > Capsule 2: 2K clients > Logs from Capsule 1: > [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/gshadow: name=qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: new group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, > home=/var/lib/qdrouterd, shell=/sbin/nologin > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: > qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 > error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000] > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > /usr/sbin/katello-service[1740]: *** status failed: qdrouterd *** > Logs from Capsule 2: > [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd > ● qdrouterd.service - Qpid Dispatch router daemon >Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor > preset: disabled) > Drop-In: /etc/systemd/system/qdrouterd.service.d >└─limits.conf >Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago > Process: 1158 ExecStart=/usr/sbin/qdrouterd -c > /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV) > Main PID: 1158 (code=killed, signal=SEGV) > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Started Qpid Dispatch router daemon. > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Starting Qpid Dispatch router daemon... > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel > within limit of 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:process error -2 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"
[ https://issues.apache.org/jira/browse/DISPATCH-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427575#comment-16427575 ] ASF subversion and git services commented on DISPATCH-952: -- Commit d37b0eb092e617c2986393022bd7b0f245547498 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=d37b0eb ] DISPATCH-952 - Outgoing links initiated by the router will share a single session > qdrouterd seg fault after reporting "too many sessions" > --- > > Key: DISPATCH-952 > URL: https://issues.apache.org/jira/browse/DISPATCH-952 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Reporter: Alan Conway >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876] > > {code:java} > Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 > capsules: > Capsule 1: 3K clients > Capsule 2: 2K clients > Logs from Capsule 1: > [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/gshadow: name=qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: new group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, > home=/var/lib/qdrouterd, shell=/sbin/nologin > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: > qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 > error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000] > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > /usr/sbin/katello-service[1740]: *** status failed: qdrouterd *** > Logs from Capsule 2: > [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd > ● qdrouterd.service - Qpid Dispatch router daemon >Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor > preset: disabled) > Drop-In: /etc/systemd/system/qdrouterd.service.d >└─limits.conf >Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago > Process: 1158 ExecStart=/usr/sbin/qdrouterd -c > /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV) > Main PID: 1158 (code=killed, signal=SEGV) > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Started Qpid Dispatch router daemon. > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Starting Qpid Dispatch router daemon... > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel > within limit of 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:process error -2 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #280: DISPATCH-952 - Outgoing links initiated by ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/280 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-374) Double encoded query parameters
[ https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-374. -- Resolution: Fixed Assignee: Timothy Bish Fix Version/s: 0.32.0 > Double encoded query parameters > --- > > Key: QPIDJMS-374 > URL: https://issues.apache.org/jira/browse/QPIDJMS-374 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Michael Bolz >Assignee: Timothy Bish >Priority: Major > Fix For: 0.32.0 > > > When query parameters are parsed in > [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51] > and > [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41] > and than further processed via > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64] > the values gets double encoded. > See also Javadoc of > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]: > {quote} > The string values in the Map will be URL Encoded by this method which means > that if an > already encoded value is passed it will be double encoded resulting in > corrupt values > in the newly created URI. > {quote} > For a fix I created a [pull > request|https://github.com/apache/qpid-jms/pull/17]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-374) Double encoded query parameters
[ https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427539#comment-16427539 ] ASF GitHub Bot commented on QPIDJMS-374: Github user asfgit closed the pull request at: https://github.com/apache/qpid-jms/pull/17 > Double encoded query parameters > --- > > Key: QPIDJMS-374 > URL: https://issues.apache.org/jira/browse/QPIDJMS-374 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Michael Bolz >Priority: Major > > When query parameters are parsed in > [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51] > and > [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41] > and than further processed via > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64] > the values gets double encoded. > See also Javadoc of > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]: > {quote} > The string values in the Map will be URL Encoded by this method which means > that if an > already encoded value is passed it will be double encoded resulting in > corrupt values > in the newly created URI. > {quote} > For a fix I created a [pull > request|https://github.com/apache/qpid-jms/pull/17]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-374) Double encoded query parameters
[ https://issues.apache.org/jira/browse/QPIDJMS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427538#comment-16427538 ] ASF subversion and git services commented on QPIDJMS-374: - Commit b96f4f2ab2ee635661c175b48e39cb3c65006b6a in qpid-jms's branch refs/heads/master from [~mirbo] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b96f4f2 ] QPIDJMS-374: Use PU.parseQuery(remoteURI) to avoid double encoding > Double encoded query parameters > --- > > Key: QPIDJMS-374 > URL: https://issues.apache.org/jira/browse/QPIDJMS-374 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.31.0 >Reporter: Michael Bolz >Priority: Major > > When query parameters are parsed in > [TransportFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/transports/TransportFactory.java#L51] > and > [AmqpProviderFactory|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpProviderFactory.java#L41] > and than further processed via > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64] > the values gets double encoded. > See also Javadoc of > [PropertyUtil#replaceQuery|https://github.com/apache/qpid-jms/blob/70fe1b882e1381b1016a10b0707f6e112d4e0598/qpid-jms-client/src/main/java/org/apache/qpid/jms/util/PropertyUtil.java#L64]: > {quote} > The string values in the Map will be URL Encoded by this method which means > that if an > already encoded value is passed it will be double encoded resulting in > corrupt values > in the newly created URI. > {quote} > For a fix I created a [pull > request|https://github.com/apache/qpid-jms/pull/17]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms pull request #17: QPIDJMS-374: Use getRawQuery to avoid double enco...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-jms/pull/17 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off
[ https://issues.apache.org/jira/browse/PROTON-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-1728. --- Resolution: Done https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=37136940e3077f25ce58c94775f48c66f666f4a8 > [proton-c] Reorganize the source tree now that Proton J is split off > > > Key: PROTON-1728 > URL: https://issues.apache.org/jira/browse/PROTON-1728 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.23.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off
[ https://issues.apache.org/jira/browse/PROTON-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427493#comment-16427493 ] ASF GitHub Bot commented on PROTON-1728: Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/132 > [proton-c] Reorganize the source tree now that Proton J is split off > > > Key: PROTON-1728 > URL: https://issues.apache.org/jira/browse/PROTON-1728 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.23.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1638) Need to improve proton-c build tree layout
[ https://issues.apache.org/jira/browse/PROTON-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427492#comment-16427492 ] ASF GitHub Bot commented on PROTON-1638: Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/140 > Need to improve proton-c build tree layout > -- > > Key: PROTON-1638 > URL: https://issues.apache.org/jira/browse/PROTON-1638 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Justin Ross >Priority: Major > > The proton-c tree layout is annoying in a number of ways: > * Since the split with proton-j there is a superfluous top level > * CMake build flags don't propagate properly because examples are not in the > correct subtree > ** Examples should be in the binding subtree that they are examples > ** Otherwise the information for a particular binding and its examples are > split into 2 different parts of the proton-c tree. > ** This means that the installation for a binding is split > ** It is unatural in CMake to split build flags like this - CMake is > hierarchical -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #132: PROTON-1728: WIP: Reorganize the source tree ...
Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/132 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #136: WIP - Remove deprecated bindings and APIs
Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/136 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #138: WIP - Remove obsolete docs and test code
Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/138 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton pull request #140: PROTON-1638, PROTON-1728: Reorganize the sour...
Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/140 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1806) Release qpid_proton gem with heartbeating implemented
[ https://issues.apache.org/jira/browse/PROTON-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427412#comment-16427412 ] Miha Plesko commented on PROTON-1806: - Thanks guys for releasing so early, we already have PR open to use it. Thanks [~aconway] for note about #schedule, fortunately we're not using it at all so all good for us. I've tested with Wireshark and heartbeating works, so 0.22.0 is just awesome for us. > Release qpid_proton gem with heartbeating implemented > - > > Key: PROTON-1806 > URL: https://issues.apache.org/jira/browse/PROTON-1806 > Project: Qpid Proton > Issue Type: Wish > Components: ruby-binding >Reporter: Miha Plesko >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.22.0 > > > We use qpid_proton gem in RedHat CloudForms to capture events from ActiveMQ > queue. Recently we discovered a blocking bug in this gem which results in > client connection being disconnected every 2-3 minutes accompanied with file > descriptor leakage bug as described here: > https://issues.apache.org/jira/browse/PROTON-1782 and > https://issues.apache.org/jira/browse/PROTON-1791 > Both issues are fixed by now and merged qpid_proton master branch, many > thanks to [~aconway], [~astitcher], [~jdanek] for amazing response time. > > I'm opening this ticket to discuss release plans for the qpid_proton gem. > CloudForms is about to be released first week in April and our initial plan > was to monkey-patch the gem to include those fixes. It turns our, however, > that changes modify gem's core to much to do the monkey-patching, hence we > decided to wait for you guys to perform the next release. > > Q: Do you happen to know specific date when releasing new gem version is > supposed to happen? I remember we mentioned "within a couple of weeks" here > https://issues.apache.org/jira/browse/PROTON-1782?focusedCommentId=16401841=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16401841 > , but we would need as good estimate as possible since we need to > communicate to customers how long they need to wait > > Thanks for your great work, looking forward to be hearing from you! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-956) Zero out the memory after calling NEW or new_*
[ https://issues.apache.org/jira/browse/DISPATCH-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427411#comment-16427411 ] Ganesh Murthy commented on DISPATCH-956: Yes, changing NEW and new_* to zero out the memory is the best solution in my view. > Zero out the memory after calling NEW or new_* > -- > > Key: DISPATCH-956 > URL: https://issues.apache.org/jira/browse/DISPATCH-956 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Call the ZERO macro after calling NEW() or new_ > > This will clear the memory and avoid pointing to some garbage. > > [~chug] found and fixed a problem like this in commit > 627aae1ec779da1f3db9ec7f5add55b300a6 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-956) Zero out the memory after calling NEW or new_*
[ https://issues.apache.org/jira/browse/DISPATCH-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427406#comment-16427406 ] Ted Ross commented on DISPATCH-956: --- Also, it's not clear what you are proposing. Are you suggesting that NEW and new_* should be changed so they internally zero out the allocation memory? > Zero out the memory after calling NEW or new_* > -- > > Key: DISPATCH-956 > URL: https://issues.apache.org/jira/browse/DISPATCH-956 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Call the ZERO macro after calling NEW() or new_ > > This will clear the memory and avoid pointing to some garbage. > > [~chug] found and fixed a problem like this in commit > 627aae1ec779da1f3db9ec7f5add55b300a6 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-956) Zero out the memory after calling NEW or new_*
[ https://issues.apache.org/jira/browse/DISPATCH-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427396#comment-16427396 ] Ted Ross commented on DISPATCH-956: --- I prefer to not blindly take the overhead of zeroing all allocated data when, in most cases, we will then re-initialize most/all of the data. > Zero out the memory after calling NEW or new_* > -- > > Key: DISPATCH-956 > URL: https://issues.apache.org/jira/browse/DISPATCH-956 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Call the ZERO macro after calling NEW() or new_ > > This will clear the memory and avoid pointing to some garbage. > > [~chug] found and fixed a problem like this in commit > 627aae1ec779da1f3db9ec7f5add55b300a6 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-956) Zero out the memory after calling NEW or new_*
[ https://issues.apache.org/jira/browse/DISPATCH-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-956: --- Fix Version/s: (was: 1.1.0) > Zero out the memory after calling NEW or new_* > -- > > Key: DISPATCH-956 > URL: https://issues.apache.org/jira/browse/DISPATCH-956 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.0.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > Call the ZERO macro after calling NEW() or new_ > > This will clear the memory and avoid pointing to some garbage. > > [~chug] found and fixed a problem like this in commit > 627aae1ec779da1f3db9ec7f5add55b300a6 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #281: NO-JIRA: Update some doc attribute names
GitHub user bhardesty opened a pull request: https://github.com/apache/qpid-dispatch/pull/281 NO-JIRA: Update some doc attribute names You can merge this pull request into a Git repository by running: $ git pull https://github.com/bhardesty/qpid-dispatch update-doc-attributes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/281.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 #281 commit f9d6b5ba1a5462372d4de1aef147b4c672bc7ce3 Author: Ben HardestyDate: 2018-04-05T18:07:52Z Update doc attributes --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #280: DISPATCH-952 - Outgoing links initiated by ...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/280 DISPATCH-952 - Outgoing links initiated by the router will share a si⦠â¦ngle session You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-952-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/280.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 #280 commit d37b0eb092e617c2986393022bd7b0f245547498 Author: Ganesh MurthyDate: 2018-04-04T20:15:31Z DISPATCH-952 - Outgoing links initiated by the router will share a single session --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-952) qdrouterd seg fault after reporting "too many sessions"
[ https://issues.apache.org/jira/browse/DISPATCH-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427330#comment-16427330 ] ASF GitHub Bot commented on DISPATCH-952: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/280 DISPATCH-952 - Outgoing links initiated by the router will share a si… …ngle session You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-952-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/280.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 #280 commit d37b0eb092e617c2986393022bd7b0f245547498 Author: Ganesh MurthyDate: 2018-04-04T20:15:31Z DISPATCH-952 - Outgoing links initiated by the router will share a single session > qdrouterd seg fault after reporting "too many sessions" > --- > > Key: DISPATCH-952 > URL: https://issues.apache.org/jira/browse/DISPATCH-952 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Reporter: Alan Conway >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > Reported at [https://bugzilla.redhat.com/show_bug.cgi?id=1561876] > > {code:java} > Currently running Satellite 6.3 with 5K clients. The clients are managed by 2 > capsules: > Capsule 1: 3K clients > Capsule 2: 2K clients > Logs from Capsule 1: > [root@c02-h10-r620-vm1 ~]# journalctl | grep qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: group added to /etc/gshadow: name=qdrouterd > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > groupadd[19140]: new group: name=qdrouterd, GID=993 > Mar 26 03:00:47 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > useradd[19145]: new user: name=qdrouterd, UID=996, GID=993, > home=/var/lib/qdrouterd, shell=/sbin/nologin > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > qdrouterd[16084]: [0x7fe3f0016aa0]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:39:06 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com kernel: > qdrouterd[16087]: segfault at 88 ip 7fe40b79d820 sp 7fe3fd5f9298 > error 6 in libqpid-proton.so.10.0.0[7fe40b77f000+4b000] > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:39:07 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service failed. > Mar 29 01:02:09 c02-h10-r620-vm1.rdu.openstack.engineering.redhat.com > /usr/sbin/katello-service[1740]: *** status failed: qdrouterd *** > Logs from Capsule 2: > [root@c02-h10-r620-vm2 ~]# systemctl status qdrouterd > ● qdrouterd.service - Qpid Dispatch router daemon >Loaded: loaded (/usr/lib/systemd/system/qdrouterd.service; enabled; vendor > preset: disabled) > Drop-In: /etc/systemd/system/qdrouterd.service.d >└─limits.conf >Active: failed (Result: signal) since Wed 2018-03-28 10:58:02 EDT; 14h ago > Process: 1158 ExecStart=/usr/sbin/qdrouterd -c > /etc/qpid-dispatch/qdrouterd.conf (code=killed, signal=SEGV) > Main PID: 1158 (code=killed, signal=SEGV) > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Started Qpid Dispatch router daemon. > Mar 28 07:38:46 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Starting Qpid Dispatch router daemon... > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:unable to find an open available channel > within limit of 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:process error -2 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > qdrouterd[1158]: [0x7f36a000a170]:pn_session: too many sessions: 32768 > channel_max is 32767 > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: qdrouterd.service: main process exited, code=killed, > status=11/SEGV > Mar 28 10:58:02 c02-h10-r620-vm2.rdu.openstack.engineering.redhat.com > systemd[1]: Unit qdrouterd.service entered failed state. > Mar 28 10:58:02
[jira] [Created] (DISPATCH-956) Zero out the memory after calling NEW or new_*
Ganesh Murthy created DISPATCH-956: -- Summary: Zero out the memory after calling NEW or new_* Key: DISPATCH-956 URL: https://issues.apache.org/jira/browse/DISPATCH-956 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 1.0.1 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Fix For: 1.1.0 Call the ZERO macro after calling NEW() or new_ This will clear the memory and avoid pointing to some garbage. [~chug] found and fixed a problem like this in commit 627aae1ec779da1f3db9ec7f5add55b300a6 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #279: Dispatch 952 1
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/279 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427263#comment-16427263 ] ASF subversion and git services commented on DISPATCH-918: -- Commit 627aae1ec779da1f3db9ec7f5add55b300a6 in qpid-dispatch's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=627aae1 ] DISPATCH-918: clear newly allocated structure to avoid segfaults > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.1.0 > > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #279: Dispatch 952 1
Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/279#discussion_r179512687 --- Diff: src/container.c --- @@ -756,8 +756,16 @@ qd_link_t *qd_link(qd_node_t *node, qd_connection_t *conn, qd_direction_t dir, c sys_mutex_lock(node->container->lock); DEQ_INSERT_TAIL(node->container->links, link); sys_mutex_unlock(node->container->lock); -link->pn_sess = pn_session(qd_connection_pn(conn)); -pn_session_set_incoming_capacity(link->pn_sess, cf->incoming_capacity); + +bool open_session = false; + +if (!conn->pn_sess) { +open_session = true; --- End diff -- Good point. I removed it. That flag is *gone* --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #279: Dispatch 952 1
Github user alanconway commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/279#discussion_r179510287 --- Diff: src/container.c --- @@ -756,8 +756,16 @@ qd_link_t *qd_link(qd_node_t *node, qd_connection_t *conn, qd_direction_t dir, c sys_mutex_lock(node->container->lock); DEQ_INSERT_TAIL(node->container->links, link); sys_mutex_unlock(node->container->lock); -link->pn_sess = pn_session(qd_connection_pn(conn)); -pn_session_set_incoming_capacity(link->pn_sess, cf->incoming_capacity); + +bool open_session = false; + +if (!conn->pn_sess) { +open_session = true; --- End diff -- Why not just do pn_session_open() directly here? I don't see anything that requires it to be delayed till the end. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #279: Dispatch 952 1
Github user alanconway commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/279#discussion_r179509985 --- Diff: src/container.c --- @@ -769,11 +777,12 @@ qd_link_t *qd_link(qd_node_t *node, qd_connection_t *conn, qd_direction_t dir, c link->node = node; link->drain_mode = pn_link_get_drain(link->pn_link); link->remote_snd_settle_mode = pn_link_remote_snd_settle_mode(link->pn_link); -link->close_sess_with_link = true; +link->close_sess_with_link = false; --- End diff -- Could delete this field entirely, it is never true --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8153) [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS handshake
[ https://issues.apache.org/jira/browse/QPID-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-8153: Assignee: Keith Wall > [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS > handshake > --- > > Key: QPID-8153 > URL: https://issues.apache.org/jira/browse/QPID-8153 > Project: Qpid > Issue Type: Improvement > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Trivial > Fix For: qpid-java-client-0-x-6.3.1 > > > Qpid JMS AMQP 0-x client does not provide SNI as part of TLS handshake. The a > client should be able to indicate which hostname it is attempting to connect > to by using SNI TLS extension. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8153) [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS handshake
[ https://issues.apache.org/jira/browse/QPID-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8153: - Status: Reviewable (was: In Progress) > [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS > handshake > --- > > Key: QPID-8153 > URL: https://issues.apache.org/jira/browse/QPID-8153 > Project: Qpid > Issue Type: Improvement > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Trivial > Fix For: qpid-java-client-0-x-6.3.1 > > > Qpid JMS AMQP 0-x client does not provide SNI as part of TLS handshake. The a > client should be able to indicate which hostname it is attempting to connect > to by using SNI TLS extension. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'war
[ https://issues.apache.org/jira/browse/QPID-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427111#comment-16427111 ] ASF subversion and git services commented on QPID-8135: --- Commit 97347f0fb0e0782398bd16a7ba2d318bbb759bd1 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=97347f0 ] QPID-8135: [Qpid JMS AMQP 0-x] Mask passwords associated with end to end encryption in the BrokerDetails#toString() > [JMS AMQP 0-x] Connection URL options for end-to-end encryption > keystore/trustore passwords can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn' > --- > > Key: QPID-8135 > URL: https://issues.apache.org/jira/browse/QPID-8135 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.1 > > > The connection URL password options can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn'. > The following cases are identified when password is logged > # when encryption keystore/trustore parameters are declared as part of > broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower > threshold and connectivity is not established, the > encryption_key_store_password or encryption_trust_store_password can be > logged with info log level as below > {noformat} > 2018-03-16 12:56:02,196 INFO [main] o.a.q.c.AMQConnection Unable to connect > to broker at > tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'_trust_store_password='password' > org.apache.qpid.transport.TransportException: Error connecting to broker > at > org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151) > ... > 2018-03-16 12:56:02,196 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Checking failoverAllowed() > 2018-03-16 12:56:02,197 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Cycle Servers: > Cycle Retries:20 > Current Cycle:20 > Server Retries:0 > Current Retry:0 > Current Broker:0 > >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'_trust_store_password='password' > {noformat} > # when encryption keystore/trustore parameters or/and SSL trust store > parameters or/and SSL client-auth parameters are declared as part of > connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or > lower threshold, the password options can be logged with DEBUG log level as > below: > {noformat} > 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection > Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'_store='/path/to/trsustore.ts'_store_password='secret'_trust_store_password='password'_store='/path/to/keystore.ks'_store_password='secret'='tcp://localhost:5672'='roundrobin?cyclecount='20'' > {noformat} > The work around for the issue would be to set debug log level to warn at > least for the following loggers: > * org.apache.qpid.client.AMQConnection > * org.apache.qpid.jms.failover.FailoverRoundRobinServers -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn'
[ https://issues.apache.org/jira/browse/QPID-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8135: - Status: Reviewable (was: In Progress) > [JMS AMQP 0-x] Connection URL options for end-to-end encryption > keystore/trustore passwords can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn' > --- > > Key: QPID-8135 > URL: https://issues.apache.org/jira/browse/QPID-8135 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-client-0-x-6.3.1 > > > The connection URL password options can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn'. > The following cases are identified when password is logged > # when encryption keystore/trustore parameters are declared as part of > broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower > threshold and connectivity is not established, the > encryption_key_store_password or encryption_trust_store_password can be > logged with info log level as below > {noformat} > 2018-03-16 12:56:02,196 INFO [main] o.a.q.c.AMQConnection Unable to connect > to broker at > tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'_trust_store_password='password' > org.apache.qpid.transport.TransportException: Error connecting to broker > at > org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151) > ... > 2018-03-16 12:56:02,196 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Checking failoverAllowed() > 2018-03-16 12:56:02,197 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Cycle Servers: > Cycle Retries:20 > Current Cycle:20 > Server Retries:0 > Current Retry:0 > Current Broker:0 > >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'_trust_store_password='password' > {noformat} > # when encryption keystore/trustore parameters or/and SSL trust store > parameters or/and SSL client-auth parameters are declared as part of > connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or > lower threshold, the password options can be logged with DEBUG log level as > below: > {noformat} > 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection > Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'_store='/path/to/trsustore.ts'_store_password='secret'_trust_store_password='password'_store='/path/to/keystore.ks'_store_password='secret'='tcp://localhost:5672'='roundrobin?cyclecount='20'' > {noformat} > The work around for the issue would be to set debug log level to warn at > least for the following loggers: > * org.apache.qpid.client.AMQConnection > * org.apache.qpid.jms.failover.FailoverRoundRobinServers -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn
[ https://issues.apache.org/jira/browse/QPID-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-8135: Assignee: Keith Wall > [JMS AMQP 0-x] Connection URL options for end-to-end encryption > keystore/trustore passwords can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn' > --- > > Key: QPID-8135 > URL: https://issues.apache.org/jira/browse/QPID-8135 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-client-0-x-6.3.1 > > > The connection URL password options can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn'. > The following cases are identified when password is logged > # when encryption keystore/trustore parameters are declared as part of > broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower > threshold and connectivity is not established, the > encryption_key_store_password or encryption_trust_store_password can be > logged with info log level as below > {noformat} > 2018-03-16 12:56:02,196 INFO [main] o.a.q.c.AMQConnection Unable to connect > to broker at > tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'_trust_store_password='password' > org.apache.qpid.transport.TransportException: Error connecting to broker > at > org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151) > ... > 2018-03-16 12:56:02,196 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Checking failoverAllowed() > 2018-03-16 12:56:02,197 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Cycle Servers: > Cycle Retries:20 > Current Cycle:20 > Server Retries:0 > Current Retry:0 > Current Broker:0 > >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'_trust_store_password='password' > {noformat} > # when encryption keystore/trustore parameters or/and SSL trust store > parameters or/and SSL client-auth parameters are declared as part of > connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or > lower threshold, the password options can be logged with DEBUG log level as > below: > {noformat} > 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection > Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'_store='/path/to/trsustore.ts'_store_password='secret'_trust_store_password='password'_store='/path/to/keystore.ks'_store_password='secret'='tcp://localhost:5672'='roundrobin?cyclecount='20'' > {noformat} > The work around for the issue would be to set debug log level to warn at > least for the following loggers: > * org.apache.qpid.client.AMQConnection > * org.apache.qpid.jms.failover.FailoverRoundRobinServers -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8153) [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS handshake
[ https://issues.apache.org/jira/browse/QPID-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427110#comment-16427110 ] ASF subversion and git services commented on QPID-8153: --- Commit 78cf85c60fbedddfc08f978262aaa23061cae2b4 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=78cf85c ] QPID-8153: [Qpid JMS AMQP 0-x] Pass host/port through to the SSLEngine so that SNI may function > [JMS AMQP 0-x] JMS AMQP 0-x should be able to send SNI as part of TLS > handshake > --- > > Key: QPID-8153 > URL: https://issues.apache.org/jira/browse/QPID-8153 > Project: Qpid > Issue Type: Improvement > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Priority: Trivial > Fix For: qpid-java-client-0-x-6.3.1 > > > Qpid JMS AMQP 0-x client does not provide SNI as part of TLS handshake. The a > client should be able to indicate which hostname it is attempting to connect > to by using SNI TLS extension. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn'
[ https://issues.apache.org/jira/browse/QPID-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8135: - Summary: [JMS AMQP 0-x] Connection URL options for end-to-end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn' (was: [JMS AMQP 0-x] Connection URL options for end to end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn') > [JMS AMQP 0-x] Connection URL options for end-to-end encryption > keystore/trustore passwords can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn' > --- > > Key: QPID-8135 > URL: https://issues.apache.org/jira/browse/QPID-8135 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.1 > > > The connection URL password options can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn'. > The following cases are identified when password is logged > # when encryption keystore/trustore parameters are declared as part of > broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower > threshold and connectivity is not established, the > encryption_key_store_password or encryption_trust_store_password can be > logged with info log level as below > {noformat} > 2018-03-16 12:56:02,196 INFO [main] o.a.q.c.AMQConnection Unable to connect > to broker at > tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'_trust_store_password='password' > org.apache.qpid.transport.TransportException: Error connecting to broker > at > org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151) > ... > 2018-03-16 12:56:02,196 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Checking failoverAllowed() > 2018-03-16 12:56:02,197 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Cycle Servers: > Cycle Retries:20 > Current Cycle:20 > Server Retries:0 > Current Retry:0 > Current Broker:0 > >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'_trust_store_password='password' > {noformat} > # when encryption keystore/trustore parameters or/and SSL trust store > parameters or/and SSL client-auth parameters are declared as part of > connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or > lower threshold, the password options can be logged with DEBUG log level as > below: > {noformat} > 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection > Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'_store='/path/to/trsustore.ts'_store_password='secret'_trust_store_password='password'_store='/path/to/keystore.ks'_store_password='secret'='tcp://localhost:5672'='roundrobin?cyclecount='20'' > {noformat} > The work around for the issue would be to set debug log level to warn at > least for the following loggers: > * org.apache.qpid.client.AMQConnection > * org.apache.qpid.jms.failover.FailoverRoundRobinServers -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8135) [JMS AMQP 0-x] Connection URL options for end to end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn'
[ https://issues.apache.org/jira/browse/QPID-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8135: - Summary: [JMS AMQP 0-x] Connection URL options for end to end encryption keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn' (was: [JMS AMQP 0-x] Connection URL options for keystore/trustore passwords can be logged when log level for 'org.apache.qpid' loggers is lower than 'warn') > [JMS AMQP 0-x] Connection URL options for end to end encryption > keystore/trustore passwords can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn' > --- > > Key: QPID-8135 > URL: https://issues.apache.org/jira/browse/QPID-8135 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.1 > > > The connection URL password options can be logged when log level for > 'org.apache.qpid' loggers is lower than 'warn'. > The following cases are identified when password is logged > # when encryption keystore/trustore parameters are declared as part of > broker URL , 'org.apache.qpid' loggers log level is set to ''info' or lower > threshold and connectivity is not established, the > encryption_key_store_password or encryption_trust_store_password can be > logged with info log level as below > {noformat} > 2018-03-16 12:56:02,196 INFO [main] o.a.q.c.AMQConnection Unable to connect > to broker at > tcp://localhost:5672?encryption_trust_store='/path/to/trustore.jks'_trust_store_password='password' > org.apache.qpid.transport.TransportException: Error connecting to broker > at > org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151) > ... > 2018-03-16 12:56:02,196 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Checking failoverAllowed() > 2018-03-16 12:56:02,197 INFO [main] o.a.q.j.f.FailoverRoundRobinServers > Cycle Servers: > Cycle Retries:20 > Current Cycle:20 > Server Retries:0 > Current Retry:0 > Current Broker:0 > >tcp://localhost:5672?encryption_trust_store='/path/to/trsutsore.jks'_trust_store_password='password' > {noformat} > # when encryption keystore/trustore parameters or/and SSL trust store > parameters or/and SSL client-auth parameters are declared as part of > connection URL and 'org.apache.qpid' loggers log level is set to 'debug' or > lower threshold, the password options can be logged with DEBUG log level as > below: > {noformat} > 2018-03-16 13:03:20,879 DEBUG [main] o.a.q.c.AMQConnection > Connection(1):amqp://admin:@consumer/?encryption_trust_store='/path/to/keystore.jks'_store='/path/to/trsustore.ts'_store_password='secret'_trust_store_password='password'_store='/path/to/keystore.ks'_store_password='secret'='tcp://localhost:5672'='roundrobin?cyclecount='20'' > {noformat} > The work around for the issue would be to set debug log level to warn at > least for the following loggers: > * org.apache.qpid.client.AMQConnection > * org.apache.qpid.jms.failover.FailoverRoundRobinServers -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1806) Release qpid_proton gem with heartbeating implemented
[ https://issues.apache.org/jira/browse/PROTON-1806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427081#comment-16427081 ] Alan Conway commented on PROTON-1806: - Please note there is a new feature Container#schedule in 0.22 that does not work. There is a small monkey patch you can apply to use this feature until the full fix in 0.23. For patch code see the description of PROTON-1820 > Release qpid_proton gem with heartbeating implemented > - > > Key: PROTON-1806 > URL: https://issues.apache.org/jira/browse/PROTON-1806 > Project: Qpid Proton > Issue Type: Wish > Components: ruby-binding >Reporter: Miha Plesko >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.22.0 > > > We use qpid_proton gem in RedHat CloudForms to capture events from ActiveMQ > queue. Recently we discovered a blocking bug in this gem which results in > client connection being disconnected every 2-3 minutes accompanied with file > descriptor leakage bug as described here: > https://issues.apache.org/jira/browse/PROTON-1782 and > https://issues.apache.org/jira/browse/PROTON-1791 > Both issues are fixed by now and merged qpid_proton master branch, many > thanks to [~aconway], [~astitcher], [~jdanek] for amazing response time. > > I'm opening this ticket to discuss release plans for the qpid_proton gem. > CloudForms is about to be released first week in April and our initial plan > was to monkey-patch the gem to include those fixes. It turns our, however, > that changes modify gem's core to much to do the monkey-patching, hence we > decided to wait for you guys to perform the next release. > > Q: Do you happen to know specific date when releasing new gem version is > supposed to happen? I remember we mentioned "within a couple of weeks" here > https://issues.apache.org/jira/browse/PROTON-1782?focusedCommentId=16401841=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16401841 > , but we would need as good estimate as possible since we need to > communicate to customers how long they need to wait > > Thanks for your great work, looking forward to be hearing from you! -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1820) [ruby] Container#schedule does not work if called from handler
[ https://issues.apache.org/jira/browse/PROTON-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1820. - Resolution: Fixed > [ruby] Container#schedule does not work if called from handler > -- > > Key: PROTON-1820 > URL: https://issues.apache.org/jira/browse/PROTON-1820 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > The Container#schedule method does not work if called from a handler function. > > WORKAROUND: The following monkey-patch can be used to work-around the bug > until the fix is released > > {code:java} > require 'qpid_proton' > # Monkey-patch to fix https://issues.apache.org/jira/browse/PROTON-1820 in > proton 0.22 > # The patch will not be needed with proton >= 0.23 > module Qpid::Proton > module ContainerFix > def run_one(task, now) > if task == :schedule > @lock.synchronize { @active -= 1; check_stop_lh } if maybe_panic { > @schedule.process now } > @lock.synchronize { @schedule_working = false } > wake > else > super > end > end > end > class Container > prepend ContainerFix > end > end > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1820) [ruby] Container#schedule does not work if called from handler
[ https://issues.apache.org/jira/browse/PROTON-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1820: Description: The Container#schedule method does not work if called from a handler function. WORKAROUND: The following monkey-patch can be used to work-around the bug until the fix is released {code:java} require 'qpid_proton' # Monkey-patch to fix https://issues.apache.org/jira/browse/PROTON-1820 in proton 0.22 # The patch will not be needed with proton >= 0.23 module Qpid::Proton module ContainerFix def run_one(task, now) if task == :schedule @lock.synchronize { @active -= 1; check_stop_lh } if maybe_panic { @schedule.process now } @lock.synchronize { @schedule_working = false } wake else super end end end class Container prepend ContainerFix end end {code} was:The Container#schedule method does not work if called from a handler function. > [ruby] Container#schedule does not work if called from handler > -- > > Key: PROTON-1820 > URL: https://issues.apache.org/jira/browse/PROTON-1820 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > The Container#schedule method does not work if called from a handler function. > > WORKAROUND: The following monkey-patch can be used to work-around the bug > until the fix is released > > {code:java} > require 'qpid_proton' > # Monkey-patch to fix https://issues.apache.org/jira/browse/PROTON-1820 in > proton 0.22 > # The patch will not be needed with proton >= 0.23 > module Qpid::Proton > module ContainerFix > def run_one(task, now) > if task == :schedule > @lock.synchronize { @active -= 1; check_stop_lh } if maybe_panic { > @schedule.process now } > @lock.synchronize { @schedule_working = false } > wake > else > super > end > end > end > class Container > prepend ContainerFix > end > end > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1820) [ruby] Container#schedule does not work if called from handler
[ https://issues.apache.org/jira/browse/PROTON-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427041#comment-16427041 ] ASF subversion and git services commented on PROTON-1820: - Commit dab607e6393e9d939847f845d4ca322705efd717 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=dab607e ] PROTON-1820: [ruby] Container#schedule does not work if called from handler > [ruby] Container#schedule does not work if called from handler > -- > > Key: PROTON-1820 > URL: https://issues.apache.org/jira/browse/PROTON-1820 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > The Container#schedule method does not work if called from a handler function. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1820) [ruby] Container#schedule does not work if called from handler
[ https://issues.apache.org/jira/browse/PROTON-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16427040#comment-16427040 ] ASF subversion and git services commented on PROTON-1820: - Commit d93459311c4d5b35f64ce7e443dbf2c161b1b1bc in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d934593 ] PROTON-1820: [ruby] Improve error handling in container > [ruby] Container#schedule does not work if called from handler > -- > > Key: PROTON-1820 > URL: https://issues.apache.org/jira/browse/PROTON-1820 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: proton-c-0.22.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.23.0 > > > The Container#schedule method does not work if called from a handler function. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426983#comment-16426983 ] Robbie Gemmell commented on QPIDJMS-373: Sounds like you are thinking of something more general than I was. Complications with that being, those things are in different areas of the client, occur at different times, run on different threads, operate on different things, and you might want to do one, or the other, or for some odd reason both for the same connection. Hmm... > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") and setting > of "Authorization" Header during WebSocket connection handshake. > Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions). > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426828#comment-16426828 ] Rob Godfrey edited comment on QPIDJMS-373 at 4/5/18 12:27 PM: -- [~gemmellr] Registering a callback would be a nice general purpose enhancement I think; it seems to me that this might be the only case where a user wants automatically invoke some action prior to initiating the connection. For example the issue being discussed here for adding the oauth bearer token into a "header" prior to establishing the connection over WebSocket could similarly apply to the case of making an XOAUTH2 TCP connection, where you want to inject the token into the password of the connection to be returned. was (Author: rgodfrey): [~gemmellr] Registering a callback would be a nice general purpose enhancement I think; it seems to me that this might be the only case where a user wants automatically invoke some action prior to initiating the connection > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") and setting > of "Authorization" Header during WebSocket connection handshake. > Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions). > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426828#comment-16426828 ] Rob Godfrey commented on QPIDJMS-373: - [~gemmellr] Registering a callback would be a nice general purpose enhancement I think; it seems to me that this might be the only case where a user wants automatically invoke some action prior to initiating the connection > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") and setting > of "Authorization" Header during WebSocket connection handshake. > Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions). > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8138) [Broker-J] Report authenticated user principals and groups as part of ACL and/or operational logging
[ https://issues.apache.org/jira/browse/QPID-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426807#comment-16426807 ] Keith Wall commented on QPID-8138: -- I am wondering if this is required required. The REST API exposes {{org.apache.qpid.server.model.Broker#getUser}} and {{org.apache.qpid.server.model.Broker#getGroups}}. Couldn't this be used? > [Broker-J] Report authenticated user principals and groups as part of ACL > and/or operational logging > > > Key: QPID-8138 > URL: https://issues.apache.org/jira/browse/QPID-8138 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > > Authenticated user principals and groups can be logged part of ACL and/or > operational in order to simplify an investigation of ACL related issues -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[ https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426753#comment-16426753 ] Robbie Gemmell commented on QPIDJMS-373: Creating your own transport factory is what I was describing, yes. You could have one that simply wrapped the existing bits and did nothing but provide/update the details for the header. Writing a delegating ConnectionFactory of your own as Rob mentioned would be quite simple I'd think. It would implement the createConnection calls, have them get a token, and then call the createConnection methods of the underlying factory accordingly. Failover is an interesting point in that case though, as if a new token was needed at every attempt then the application would need to manage that reconnection itself by using the factory, e.g as many frameworks actually do, rather than using the connections 'internal' functionality. Doing otherwise would need the wrapping factory to be notified of the reconnection and update the token used somehow. There is a listener callback on the connection impl (mostly used for testing) that notifies of such activity that could be used, though it is called asynchronously and getting the updated details where needed wouldn't currently be possible except maybe by using reflection. Registering a callback when creating the original factory is perhaps something I could live with. We previously added ability to pass through an SSLContext from the factory to use during connection, that mechanism could perhaps be generalised to carry other things for transport impls to utilise at connect, such as a way to get the auth header value to use. > Support for OAuth flow and setting of "Authorization" Header for WS upgrade > request > --- > > Key: QPIDJMS-373 > URL: https://issues.apache.org/jira/browse/QPIDJMS-373 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Michael Bolz >Priority: Major > > Add support for OAuth flow ("client_credentials" and "password") and setting > of "Authorization" Header during WebSocket connection handshake. > Used "Authorization" Header or OAuth settings should/could be set via the > "transport" parameters (TransportOptions). > > As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header] > and have done one commit for the [add of the Authorization > Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede] > and one commit for the [OAuth > flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d]. > > Hope this feature is not only interesting for me. > If yes, I will add the currently missing tests to my contribution and do a > pull request. > > Regards, Michael -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org