[jira] [Updated] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request

2018-04-05 Thread Michael Bolz (JIRA)

 [ 
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

2018-04-05 Thread Michael Bolz (JIRA)

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

2018-04-05 Thread ASF GitHub Bot (JIRA)

[ 
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: mibo 
Date:   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.

2018-04-05 Thread Michael Bolz (JIRA)

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

2018-04-05 Thread mibo
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: mibo 
Date:   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.

2018-04-05 Thread Michael Bolz (JIRA)
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

2018-04-05 Thread Roddie Kieley (JIRA)

[ 
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

2018-04-05 Thread Alex Rudyy
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

2018-04-05 Thread Alex Rudyy
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"

2018-04-05 Thread Ganesh Murthy (JIRA)

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

2018-04-05 Thread ASF GitHub Bot (JIRA)

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

2018-04-05 Thread ASF subversion and git services (JIRA)

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

2018-04-05 Thread asfgit
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

2018-04-05 Thread Timothy Bish (JIRA)

 [ 
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

2018-04-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-04-05 Thread ASF subversion and git services (JIRA)

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

2018-04-05 Thread asfgit
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

2018-04-05 Thread Justin Ross (JIRA)

 [ 
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

2018-04-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-04-05 Thread ASF GitHub Bot (JIRA)

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

2018-04-05 Thread ssorj
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

2018-04-05 Thread ssorj
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

2018-04-05 Thread ssorj
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...

2018-04-05 Thread ssorj
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

2018-04-05 Thread Miha Plesko (JIRA)

[ 
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_*

2018-04-05 Thread Ganesh Murthy (JIRA)

[ 
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_*

2018-04-05 Thread Ted Ross (JIRA)

[ 
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_*

2018-04-05 Thread Ted Ross (JIRA)

[ 
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_*

2018-04-05 Thread Ganesh Murthy (JIRA)

 [ 
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

2018-04-05 Thread bhardesty
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 Hardesty 
Date:   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 ...

2018-04-05 Thread ganeshmurthy
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 Murthy 
Date:   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"

2018-04-05 Thread ASF GitHub Bot (JIRA)

[ 
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 Murthy 
Date:   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_*

2018-04-05 Thread Ganesh Murthy (JIRA)
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

2018-04-05 Thread ganeshmurthy
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

2018-04-05 Thread ASF subversion and git services (JIRA)

[ 
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

2018-04-05 Thread ganeshmurthy
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

2018-04-05 Thread alanconway
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

2018-04-05 Thread alanconway
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

2018-04-05 Thread Keith Wall (JIRA)

 [ 
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

2018-04-05 Thread Keith Wall (JIRA)

 [ 
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

2018-04-05 Thread ASF subversion and git services (JIRA)

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

2018-04-05 Thread Keith Wall (JIRA)

 [ 
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

2018-04-05 Thread Keith Wall (JIRA)

 [ 
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

2018-04-05 Thread ASF subversion and git services (JIRA)

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

2018-04-05 Thread Keith Wall (JIRA)

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

2018-04-05 Thread Keith Wall (JIRA)

 [ 
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

2018-04-05 Thread Alan Conway (JIRA)

[ 
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

2018-04-05 Thread Alan Conway (JIRA)

 [ 
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

2018-04-05 Thread Alan Conway (JIRA)

 [ 
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

2018-04-05 Thread ASF subversion and git services (JIRA)

[ 
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

2018-04-05 Thread ASF subversion and git services (JIRA)

[ 
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

2018-04-05 Thread Robbie Gemmell (JIRA)

[ 
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

2018-04-05 Thread Rob Godfrey (JIRA)

[ 
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

2018-04-05 Thread Rob Godfrey (JIRA)

[ 
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

2018-04-05 Thread Keith Wall (JIRA)

[ 
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

2018-04-05 Thread Robbie Gemmell (JIRA)

[ 
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