Proton-J and WebSocket support

[Clemens Vasters]

It appears that Proton-J doesn't implement the WebSocket protocol binding, yet. 
(I may also not be looking in the right places)

Is that on the backlog for some time in the nearer future?

Thank you
Clemens

Re: RFI: PROTON-1055 (SASL Plain authentication can fail on some brokers)

[Justin Ross]

Thanks, Robbie.  Approved.

On Thu, Jan 28, 2016 at 4:47 AM, Robbie Gemmell 
wrote:

> On 27 January 2016 at 21:09, Andrew Stitcher  wrote:
> > This [1] is really an interop bug, but I suspect it will be annoying to
> > anyone using earlier versions of ActiveMQ.
> >
> > The fix is pretty small and seems low risk to me.
> >
> > Andrew
> >
> > [1] https://issues.apache.org/jira/browse/PROTON-1055
>
> I gave this a look, and tested it out applied to the 0.12.0 beta using
> cyrus-casl, and all seemed well, I think including it would be good.
>
> (As an aside, I actually think of it as more than just an interop bug..)
>
> Robbie
>

[jira] [Commented] (PROTON-1095) Error handling

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1095:
-

Is there a reason for excluding my change here? By ignoring it the
error handling for the connection engine examples is inconsistent.
Since this JIRA is about consistency of error handling, I deliberately
added my change to it, rather than making it a separate JIRA, in the
interests of making it complete for 0.12.



> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1095:
-

Commit f936737c5a6ecfd31e3e3d0401442c61d6cd826a in qpid-proton's branch 
refs/heads/0.12.x from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f936737 ]

PROTON-1095: Exported missed new symbol definitions


> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1095:
-

Commit 7c080f1d22415378c1146e164e1929ffa3fbb97a in qpid-proton's branch 
refs/heads/0.12.x from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7c080f1 ]

Revert "PROTON-1095: [C++ binding] temporarily disable rasing exception on 
error"

This reverts commit 1bcfe660e44af1bfc9f6704fc20916a578d5cd25.


> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1095:
-

Commit 02251062bda86351d2ba266564a33a0d8db1edde in qpid-proton's branch 
refs/heads/0.12.x from [~astitcher]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0225106 ]

PROTON-1095: Fixup example broker not to exit at the smallest insult!


> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1055) Username sent twice during SASL AUTH

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher updated PROTON-1055:

Fix Version/s: 0.12.0

> Username sent twice during SASL AUTH
> 
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice 
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]:  -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]:  <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]:  -> AMQP
> [0x250d3b0]:0 -> @open(16) 
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="TEST-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]:  <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :"topic-prefix"="topic://", 
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0, 
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]:  -> SASL
> [0x18aa060]:  <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]:  -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs. 
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]:  -> SASL
> [0xa5d060]:  <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
>   File "./meow.py", line 12, in 
> messenger.send()
>   File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568, 
> in send
> self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
> 0.08user 0.02system 0:50.69elapsed 0%CPU (0avgtext+0avgdata 12192maxresident)k
> 0inputs+0outputs (0major+5474minor)pagefaults 0swaps
> #
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Request for inclusion in 0.12.0: PROTON-1095: c++: connection_engine error handling, get rid of exceptions.

[Alan Conway]

Request to include the following commit in 0.12.0 as part of PROTON-
1095. I thought it already was approved but lets make extra sure:

Commit 9c03b28b0e3865aa892f0fa79650bd6c25759a22 in qpid-proton's branch
refs/heads/master from Alan Conway
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9c03b28 ]

PROTON-1095: c++: connection_engine error handling, get rid of
exceptions.

Engine no longer throws any exceptions itself, all connections and
transport
errors are reported to the handler which can choose to throw or not.
This is consistent with error handling for the Container.

Added condition::empty()
Removed process_nothrow
Removed disconnect
Return pair from io_read rather than throwing on stream
close.

[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH

[Justin Ross (JIRA)]

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

Justin Ross commented on PROTON-1055:
-

Reviewed by Robbie.  Approved for 0.12.0.

> Username sent twice during SASL AUTH
> 
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice 
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]:  -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]:  <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]:  -> AMQP
> [0x250d3b0]:0 -> @open(16) 
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="TEST-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]:  <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :"topic-prefix"="topic://", 
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0, 
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]:  -> SASL
> [0x18aa060]:  <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]:  -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs. 
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]:  -> SASL
> [0xa5d060]:  <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
>   File "./meow.py", line 12, in 
> messenger.send()
>   File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568, 
> in send
> self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
> 0.08user 0.02system 0:50.69elapsed 0%CPU (0avgtext+0avgdata 12192maxresident)k
> 0inputs+0outputs (0major+5474minor)pagefaults 0swaps
> #
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1095:
-

Yep, that was my intent by adding it to this JIRA. Consider it proposed.


> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher commented on PROTON-1095:
-

No specific reason - only that it hasn't gone through the review/approval 
process for 0.12.

Would you like to propose it for 0.12?

> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[Alan Conway (JIRA)]

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

Alan Conway commented on PROTON-1095:
-

The connection_engine took an ad-hoc approach to error handling because the 
handler API was inadequate. Andrew has fixed that inadequacy, so it makes sense 
to apply the fix across the board, not just for the container. It would be nice 
to provide users of 0.12 with a consistent error-handling experience. To break 
it down:

Added condition::empty() - Andrew specifically noted operator! as a discussion 
point. I added empty() as part of that discussion. All the standard "container" 
types in C++ have an empty() function to test for "nothing there". IMO the 
condition is a container of error information so this is an idiomatic way to 
test it. I'm fine with having operator! as well although it is likely to be 
more controversial :)

Removed process_nothrow: The only reason for this was to deal with the issue of 
users who prefer/dislike exceptions. Andrews changes give the user perfect 
control of this so it is unnecessary. connection_engine::process() throws if 
and only if the user handler throws, exactly like container::run()

Removed disconnect: No longer needed because simply closing the underlying 
transport will cause the handler to receive transport_error and allow it to 
decide whether or not to throw, exactly as for a container handler. Lovely!

Return pair from io_read rather than throwing on stream close. 
This is a trivial improvement to an heretofore unreleased and unused 
integration API that is exception related. It is not strictly required but 
seems like it would be good to make the change earlier rather than later. Mea 
culpa for sneaking this in, I'll have myself flogged.

Phew, I really did not expect this to be controversial!! 

> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.

[Andrew Stitcher]

On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote:
> The 0.12.x branch does not compile under c++11 (clang and gcc) with
> warnings, this fixes them
> 
> https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19ab7
> c8
> 08ad43bd39274e

Unfortunately this breaks windows builds - I'm working up a fix that
works everywhere.

Andrew

[jira] [Resolved] (PROTON-1062) proton::engine as a client example

[Alan Conway (JIRA)]

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

Alan Conway resolved PROTON-1062.
-
   Resolution: Fixed
Fix Version/s: 0.12.0

0.12 release includes C++ connection_engine with examples equivalent to the 
container examples. The proton source code also includes tests that illustrate 
how to create an in-memory transport using the connection_engine 
https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/cpp/src/engine_test.cpp


> proton::engine as a client example
> --
>
> Key: PROTON-1062
> URL: https://issues.apache.org/jira/browse/PROTON-1062
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.12.0
>Reporter: Scott Matloff
>Assignee: Alan Conway
>Priority: Minor
> Fix For: 0.12.0
>
>
> The existing example which demonstrates the proton::engine functionality is a 
> broker.  To better demonstrate the disassociation between the connection and 
> the container, I think there should be an example using memory streams.
> The example would look like:
> 1) Create some data
> 2) Encode the data using the engine 
> 3) Place the result into a memory buffer
> 4) Decode the data from the buffer using a different engine instance
> 5) Display the data



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.

[Justin Ross]

Yes, definitely.

On Thu, Jan 28, 2016 at 1:57 PM, Andrew Stitcher 
wrote:

> On Thu, 2016-01-28 at 13:29 -0500, Andrew Stitcher wrote:
> > On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote:
> > > The 0.12.x branch does not compile under c++11 (clang and gcc) with
> > > warnings, this fixes them
> > >
> > > https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19a
> > > b7
> > > c8
> > > 08ad43bd39274e
> >
> > Unfortunately this breaks windows builds - I'm working up a fix that
> > works everywhere.
>
> I'ved worked up a somewhat improved fix that works on Windows. Because
> the final result is a squach of 3 changes, but it actually simple in
> itself I've created a branch to inspect it in the apache tree.
>
> Alan, check out astitcher/0.12.x/potential-fix [simgle change] and tell
> me if you think it's good.
>
> Justin, approve if Alan doesn't dissent?
>
> Andrew
>
> >
> > Andrew
> >
>

Re: Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.

[Andrew Stitcher]

On Thu, 2016-01-28 at 13:29 -0500, Andrew Stitcher wrote:
> On Thu, 2016-01-28 at 12:43 -0500, Alan Conway wrote:
> > The 0.12.x branch does not compile under c++11 (clang and gcc) with
> > warnings, this fixes them
> > 
> > https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19a
> > b7
> > c8
> > 08ad43bd39274e
> 
> Unfortunately this breaks windows builds - I'm working up a fix that
> works everywhere.

I'ved worked up a somewhat improved fix that works on Windows. Because
the final result is a squach of 3 changes, but it actually simple in
itself I've created a branch to inspect it in the apache tree.

Alan, check out astitcher/0.12.x/potential-fix [simgle change] and tell
me if you think it's good.

Justin, approve if Alan doesn't dissent?

Andrew

> 
> Andrew
> 

[jira] [Created] (PROTON-1116) Potential infinite recursion detected by VC++14 compiler

[Andrew Stitcher (JIRA)]

Andrew Stitcher created PROTON-1116:
---

 Summary: Potential infinite recursion detected by VC++14 compiler
 Key: PROTON-1116
 URL: https://issues.apache.org/jira/browse/PROTON-1116
 Project: Qpid Proton
  Issue Type: Bug
  Components: cpp-binding
Affects Versions: 0.12.0
 Environment: Visual Studio 2015 Update 1
Reporter: Andrew Stitcher
Assignee: Alan Conway
Priority: Blocker


I get the following warning when  running the Visual Studio 2015 compiler on 
the C++ binding code
{noformat}
29>c:\users\andrew\documents\github\qpid-proton\proton-c\bindings\cpp\include\proton\value.hpp(49):
 warning C4717: 
'proton::value::value,proton::value> >': recursive on all control paths, function will cause 
runtime stack overflow
{noformat}
My guess is that we never actually try to run this code in the tests or e would 
indeed by seeing a failure, however I think we must eliminate this as a bug 
before releasing 0.12.

Either remove the code so removing the warning (as the code seems like it can't 
have been called in testing) or fix the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1116) Potential infinite recursion detected by VC++14 compiler

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher commented on PROTON-1116:
-

Also produces the warning on VC10

> Potential infinite recursion detected by VC++14 compiler
> 
>
> Key: PROTON-1116
> URL: https://issues.apache.org/jira/browse/PROTON-1116
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.12.0
> Environment: Visual Studio 2015 Update 1, Visual Studio 2010
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>Priority: Blocker
>
> I get the following warning when  running the Visual Studio 2015 compiler on 
> the C++ binding code
> {noformat}
> 29>c:\users\andrew\documents\github\qpid-proton\proton-c\bindings\cpp\include\proton\value.hpp(49):
>  warning C4717: 
> 'proton::value::value  >,proton::value> >': recursive on all control paths, function will cause 
> runtime stack overflow
> {noformat}
> My guess is that we never actually try to run this code in the tests or e 
> would indeed by seeing a failure, however I think we must eliminate this as a 
> bug before releasing 0.12.
> Either remove the code so removing the warning (as the code seems like it 
> can't have been called in testing) or fix the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PROTON-1116) Potential infinite recursion detected by VC++14 compiler

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher updated PROTON-1116:

Environment: Visual Studio 2015 Update 1, Visual Studio 2010  (was: Visual 
Studio 2015 Update 1)

> Potential infinite recursion detected by VC++14 compiler
> 
>
> Key: PROTON-1116
> URL: https://issues.apache.org/jira/browse/PROTON-1116
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: cpp-binding
>Affects Versions: 0.12.0
> Environment: Visual Studio 2015 Update 1, Visual Studio 2010
>Reporter: Andrew Stitcher
>Assignee: Alan Conway
>Priority: Blocker
>
> I get the following warning when  running the Visual Studio 2015 compiler on 
> the C++ binding code
> {noformat}
> 29>c:\users\andrew\documents\github\qpid-proton\proton-c\bindings\cpp\include\proton\value.hpp(49):
>  warning C4717: 
> 'proton::value::value  >,proton::value> >': recursive on all control paths, function will cause 
> runtime stack overflow
> {noformat}
> My guess is that we never actually try to run this code in the tests or e 
> would indeed by seeing a failure, however I think we must eliminate this as a 
> bug before releasing 0.12.
> Either remove the code so removing the warning (as the code seems like it 
> can't have been called in testing) or fix the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Proton 0.12.0 release notes and docs preview

[Justin Ross]

Hi, everyone.  Please take a look at the proposed landing page content and
release notes for 0.12.0.


http://people.apache.org/~jross/qpid-site/head/releases/qpid-proton-0.12.0/index.html


http://people.apache.org/~jross/qpid-site/head/releases/qpid-proton-0.12.0/release-notes.html

There is still time to change the release note content by updating issues
in jira.  I'll get the new content when I regenerate everything after the
release vote.

Also, please add a comment about any special release notes you'd like to
the release jira.

https://issues.apache.org/jira/browse/PROTON-1050

Thanks!
Justin

Re: RFI: PROTON-1055 (SASL Plain authentication can fail on some brokers)

[Robbie Gemmell]

On 27 January 2016 at 21:09, Andrew Stitcher  wrote:
> This [1] is really an interop bug, but I suspect it will be annoying to
> anyone using earlier versions of ActiveMQ.
>
> The fix is pretty small and seems low risk to me.
>
> Andrew
>
> [1] https://issues.apache.org/jira/browse/PROTON-1055

I gave this a look, and tested it out applied to the 0.12.0 beta using
cyrus-casl, and all seemed well, I think including it would be good.

(As an aside, I actually think of it as more than just an interop bug..)

Robbie

[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell commented on PROTON-1055:


The change looks good to me, and I think it should be included in the 0.12.0 
release.

I tested this out (using cyrus SASL) against ActiveMQ 5.12.1 ( what this issue 
was reported using, and the last release before AMQ-6055 was resolved) by 
configuring the SimpleAuthenitcationPlugin with a username:password (which must 
not be equal, to show the bug) as follows:

{noformat}

  

  

  

{noformat}

I then tried to log in using the 0.12.0-beta python bindings, which as shown 
below failed:
{noformat}
[0xf61cb0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"user1\x00user1\x00pass1"]
[0xf61cb0]:0 <- @sasl-outcome(68) [code=1]
{noformat}
I then applied this change to the beta and tried again, which due to not 
setting the authzid then succeeded:
{noformat}
[0x208c510]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
initial-response=b"\x00user1\x00pass1"]
[0x208c510]:0 <- @sasl-outcome(68) [code=0]
{noformat}

> Username sent twice during SASL AUTH
> 
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
>  Issue Type: Bug
>  Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Assignee: Andrew Stitcher
> Fix For: 0.13.0
>
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice 
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]:  -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]:  <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]:  -> AMQP
> [0x250d3b0]:0 -> @open(16) 
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, 
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue", durable=0, timeout=0, dynamic=false], 
> target=@target(41) [address="TEST-queue", durable=0, timeout=0, 
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]:  <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="", 
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, 
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], 
> properties={:product="ActiveMQ", :"topic-prefix"="topic://", 
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, 
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true, 
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) 
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, 
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0, 
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0, 
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0, 
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]:  -> SASL
> [0x18aa060]:  <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]:  -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs. 
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]:  -> SASL
> [0xa5d060]:  <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN, 
> initial-response=b"the_username\x00the_username\x00the_password"]
> 

Request for inclusion in 0.12.0

[Robbie Gemmell]

Hi Justin,

I'd like to request the following for inclusion in 0.12.0:

Stop the proton-j transport from erroneously emitting various frame
types after a Close was sent.
https://issues.apache.org/jira/browse/PROTON-1114
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bcd08cc

Some minor readme/pom changes around describing running the python tests.
https://issues.apache.org/jira/browse/PROTON-1113
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f11723c

Thanks,
Robbie

Request for 0.12.0: NO-JIRA: c++: fix C++11 compile errors.

[Alan Conway]

The 0.12.x branch does not compile under c++11 (clang and gcc) with
warnings, this fixes them

https://github.com/apache/qpid-proton/commit/05502ad56f5a3860d5d19ab7c8
08ad43bd39274e

Cheers,
Alan.

[jira] [Created] (PROTON-1117) Add link.detach method to C++ binding

[Cliff Jansen (JIRA)]

Cliff Jansen created PROTON-1117:


 Summary: Add link.detach method to C++ binding
 Key: PROTON-1117
 URL: https://issues.apache.org/jira/browse/PROTON-1117
 Project: Qpid Proton
  Issue Type: Improvement
  Components: cpp-binding
Affects Versions: 0.11.1
Reporter: Cliff Jansen
Assignee: Cliff Jansen
 Fix For: 0.13.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Android client / ServiceBus

[tourili]

Thanks Alan for feed back, for sure I'll be interested in any way I could get
this stuff OK

But TBH, could you develop more your input, or PM if you prefere

Thanks



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Android-client-ServiceBus-tp7636619p7637435.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.

[jira] [Comment Edited] (PROTON-1095) Error handling

[Andrew Stitcher (JIRA)]

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

Andrew Stitcher edited comment on PROTON-1095 at 1/28/16 3:36 PM:
--

Currently some of this change is in 0.12, but all is in 0.13. Hopefully the 
balance of the change will be approved for 0.12

*Update* All of this change is now in 0.12 (except for the related 
connection_engine change from Alan)



was (Author: astitcher):
Currently some of this change is in 0.12, but all is in 0.13. Hopefully the 
balance of the change will be approved for 0.12

> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1095) Error handling

[Justin Ross (JIRA)]

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

Justin Ross commented on PROTON-1095:
-

I don't get it.  This change looks like it's beyond what Andrew's
change would require.  Proton is in Beta.  This looks like you're
bringing in the newest API thinking.



> Error handling
> --
>
> Key: PROTON-1095
> URL: https://issues.apache.org/jira/browse/PROTON-1095
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
> Fix For: 0.12.0, 0.13.0
>
>
> The C++ binding needs a disciplined and effective way to handle protocol (and 
> transport) errors.
> Currently the API has some error events, however if they are not handled the 
> program will just hang - it would be better in this case to throw an 
> exception so that the program doesn't just hang.
> Another issue is creating error states (attaching a condition) when closing a 
> connection/session/link - there should be some straightforward way to 
> indicate the error to your peer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PROTON-1117) Add link.detach method to C++ binding

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on PROTON-1117:
-

Commit f1b9d008a81d97504d07bbeb5a36238a1e90c372 in qpid-proton's branch 
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f1b9d00 ]

PROTON-1117: Add link.detach method to C++ binding


> Add link.detach method to C++ binding
> -
>
> Key: PROTON-1117
> URL: https://issues.apache.org/jira/browse/PROTON-1117
> Project: Qpid Proton
>  Issue Type: Improvement
>  Components: cpp-binding
>Affects Versions: 0.11.1
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
> Fix For: 0.13.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)