Proton 0.12.0 release update - Beta is available
Hi, folks. The beta is now available from the following URL: https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-beta/ Maven staging repo: https://repository.apache.org/content/repositories/orgapacheqpid-1059 Test output from my machine, Fedora 23 x86-64: http://people.apache.org/~jross/qpid-releases/quirk-proton-0.12.0-beta.log Only one week remains before the release candidate. See the release page[1] for more information. Please test in your environment and report what you find. Thanks! Justin --- [1] Proton 0.12.0 release page: https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.12.0
[jira] [Commented] (PROTON-1062) proton::engine as a client example
[ https://issues.apache.org/jira/browse/PROTON-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118297#comment-15118297 ] ASF subversion and git services commented on PROTON-1062: - Commit 68f7d3cd51512a6fa33c67456337296a9c0f4657 in qpid-proton's branch refs/heads/fix from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=68f7d3c ] PROTON-1062: c++: Fix error message code in io.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 > > 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)
[jira] [Commented] (PROTON-1062) proton::engine as a client example
[ https://issues.apache.org/jira/browse/PROTON-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118298#comment-15118298 ] ASF subversion and git services commented on PROTON-1062: - Commit 9da5b56a0551d5a669a48e378b97f73aa1bdb541 in qpid-proton's branch refs/heads/fix from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9da5b56 ] PROTON-1062: c++: Simplified example test runner for connection_engine tests. > 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 > > 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)
[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH
[
https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15118021#comment-15118021
]
Andrew Stitcher commented on PROTON-1055:
-
Note for the purposes of reproducing this problem the last version of ActiveMQ
that shouldn't accept the SASL behaviour noted is 5.12.1
> 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
>
> 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)
Re: Request for inclusion in 0.12 beta
I mean request for inclusion in 0.12 - the beta has already branched! On Tue, 2016-01-26 at 15:35 -0500, Andrew Stitcher wrote: > I've now checked in the working version of the improved error work > [1] > to master, and I'd like to check it in to 0.12. > > The missing commits are: > > 80587567cc1c48e25fd69a6175667471e7c8 > fa11ada8a804c2353633965ff756b9c5991d1cc6 > 9d3e995393a918b80aca5ef60061b27a387d053d > f066bd520cb2b43524c0e836ee8e8b93e5384c7f > > Andrew > > [1] https://issues.apache.org/jira/browse/PROTON-1095 > >
[jira] [Resolved] (PROTON-1108) Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce TRANSPORT_ERROR event
[ https://issues.apache.org/jira/browse/PROTON-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1108. - Resolution: Fixed > Change DISCONNECT event to be called TRANSPORT_CLOSE, introduce > TRANSPORT_ERROR event > - > > Key: PROTON-1108 > URL: https://issues.apache.org/jira/browse/PROTON-1108 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Request for inclusion in 0.12 beta
I've now checked in the working version of the improved error work [1] to master, and I'd like to check it in to 0.12. The missing commits are: 80587567cc1c48e25fd69a6175667471e7c8 fa11ada8a804c2353633965ff756b9c5991d1cc6 9d3e995393a918b80aca5ef60061b27a387d053d f066bd520cb2b43524c0e836ee8e8b93e5384c7f Andrew [1] https://issues.apache.org/jira/browse/PROTON-1095
[jira] [Commented] (PROTON-1095) Error handling
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117927#comment-15117927 ] ASF subversion and git services commented on PROTON-1095: - Commit 80587567cc1c48e25fd69a6175667471e7c8 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8058756 ] 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 > > 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
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117929#comment-15117929 ] ASF subversion and git services commented on PROTON-1095: - Commit 9d3e995393a918b80aca5ef60061b27a387d053d in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9d3e995 ] 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 > > 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
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117928#comment-15117928 ] ASF subversion and git services commented on PROTON-1095: - Commit fa11ada8a804c2353633965ff756b9c5991d1cc6 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fa11ada ] PROTON-1095: Make the exception thrown on unhandled error be proton::error > 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 > > 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
[ https://issues.apache.org/jira/browse/PROTON-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117930#comment-15117930 ] ASF subversion and git services commented on PROTON-1095: - Commit f066bd520cb2b43524c0e836ee8e8b93e5384c7f in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f066bd5 ] 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 > > 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: cpp binding failing builds in CI (WAS: [2/2] qpid-proton git commit: PROTON-1062: c++: proton::connection_engine with client and server examples.)
On Mon, 2016-01-25 at 16:32 +, Robbie Gemmell wrote: > On 24 January 2016 at 07:19, wrote: > > > The CI builds (on ASF Jenkins, Travis, and Appveyor) all appear to > have started failing consistently with this commit, either failing > during compilation or timing out running the examples during test. Appveyor still an issue, on it...
Re: Android client / ServiceBus
On Tue, 2016-01-19 at 13:46 -0700, tourili wrote: > Thanks a lot for your input Robbie > > Robbie Gemmell wrote > > I'm afraid I don't have any real experience of using Event Hubs, > > Android, Messenger, or combinations thereof, instead mostly > > using/developing proton-j as a pure protocol engine used within > > other > > components such as the JMS client or brokers like ActiveMQ. I can > > however try to answer some of your questions. > > You are already helping me a lot > > > Robbie Gemmell wrote > > The 'AndroidProton' you referred to in your original post looks to > > be > > a wrapper of a JNI based Java binding for proton-c which existed in > > the main repo previously. That JNI binging was removed perhaps a > > couple of years ago or longer. > > You are right, it is a full JNI implementation thanks to the authors' > job > > > Robbie Gemmell wrote > > The reactive work is more developed in the other > > languages/bindings, > > but there is a Reactor impl in proton-j that could form the basis > > ... > > That sounds good. I'm complete newb in the proton project, so I have > to do a > little digging in the project. > Having android native implementation in proton sound interesting in > this > nice project. A lot of devices out there are android based, and Amqp > will be > required for a lot IoT backends (Azure in instance) on such device. > > @tourili > Possibly not relevant to Java but FYI I'm working on a "minimized" reactor the connection_engine. The idea is to break down the reactor into individual connections that can be managed by other IO/threading frameworks. The problem I'm addressing is having a C based rector dictate how IO is handled and how events are dispatched, since Java has a native reactor you may not have these problems and if you do can probably fix them directly in the java reactor. However I am building experience in breaking apart a "monolithic" reactor so if that sounds like something of interest give me a shout. Cheers, Alan.
[jira] [Commented] (PROTON-1050) 0.12.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117296#comment-15117296 ] ASF subversion and git services commented on PROTON-1050: - Commit 1f2cf345283b6fa4b19f6ff0bcd4a563c9f06851 in qpid-proton's branch refs/heads/0.12.x from [~justi9] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1f2cf34 ] PROTON-1050: Update version for 0.11.0 beta > 0.12.0 release tasks > > > Key: PROTON-1050 > URL: https://issues.apache.org/jira/browse/PROTON-1050 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Request for inclusion in 0.12.0 beta
Great, thanks Justin. Both changes are now picked onto the 0.12.x branch. Robbie On 26 January 2016 at 14:16, Justin Ross wrote: > Thanks, Robbie. Both are approved. > > > On Tue, Jan 26, 2016 at 6:10 AM, Robbie Gemmell > wrote: > >> Hi Justin, >> >> I see you have created the 0.12.x branch, but before you actually spin >> the beta, could I request the following... >> >> The latest commit on https://issues.apache.org/jira/browse/PROTON-1100 >> didnt make the branch. >> https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24 >> >> Also since its a similarly trivial if check expansion but of more real >> world use, can I separately request: >> https://issues.apache.org/jira/browse/PROTON-1110 >> >> Thanks, >> Robbie >>
[jira] [Resolved] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1110. Resolution: Fixed > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1110: --- Affects Version/s: (was: 0.12.0) Fix Version/s: (was: 0.13.0) 0.12.0 Thanks Justin, change now merged to the 0.12.x branch for inclusion in the beta. > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117262#comment-15117262 ] Robbie Gemmell commented on PROTON-1100: The last commit above on master has now been merged to the 0.12.x branch for inclusion in the 0.12.0 beta. > [proton-j] the transport should not emit other frames before the Open frame > has been sent > - > > Key: PROTON-1100 > URL: https://issues.apache.org/jira/browse/PROTON-1100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > As per PROTON-1070 description, the proton-j transport can emit other frames > without first sending the Open frame [because the Connection object wasnt > actually opened], which is erroneous behaviour and should be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117258#comment-15117258 ] ASF subversion and git services commented on PROTON-1100: - Commit 193bcebd72e0d7f6107732db7dbb2bc4704345f1 in qpid-proton's branch refs/heads/0.12.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=193bceb ] PROTON-1100: also protect against an NPE that occurs if sender link has messages on it before the Open frame is sent (cherry picked from commit 6422e2497b62b46db9e993059bc514a53a8ed643) > [proton-j] the transport should not emit other frames before the Open frame > has been sent > - > > Key: PROTON-1100 > URL: https://issues.apache.org/jira/browse/PROTON-1100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > As per PROTON-1070 description, the proton-j transport can emit other frames > without first sending the Open frame [because the Connection object wasnt > actually opened], which is erroneous behaviour and should be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117259#comment-15117259 ] ASF subversion and git services commented on PROTON-1110: - Commit 271b363638daa78a15964b1d8d1d46c187d4b7e7 in qpid-proton's branch refs/heads/0.12.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=271b363 ] PROTON-1110: add toggle for suppressing the synthetic flow events generated on sending (cherry picked from commit 5ec901323eb188b840a519df3e7aeea15523c218) > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1, 0.12.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Request for inclusion in 0.12.0 beta
Thanks, Robbie. Both are approved. On Tue, Jan 26, 2016 at 6:10 AM, Robbie Gemmell wrote: > Hi Justin, > > I see you have created the 0.12.x branch, but before you actually spin > the beta, could I request the following... > > The latest commit on https://issues.apache.org/jira/browse/PROTON-1100 > didnt make the branch. > https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24 > > Also since its a similarly trivial if check expansion but of more real > world use, can I separately request: > https://issues.apache.org/jira/browse/PROTON-1110 > > Thanks, > Robbie >
[jira] [Commented] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117251#comment-15117251 ] Justin Ross commented on PROTON-1110: - Approved for 0.12.0. > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1, 0.12.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117247#comment-15117247 ] Justin Ross commented on PROTON-1100: - The last commit arrived just before the beta was created. Approved for 0.12.0. > [proton-j] the transport should not emit other frames before the Open frame > has been sent > - > > Key: PROTON-1100 > URL: https://issues.apache.org/jira/browse/PROTON-1100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > As per PROTON-1070 description, the proton-j transport can emit other frames > without first sending the Open frame [because the Connection object wasnt > actually opened], which is erroneous behaviour and should be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Request for inclusion in 0.12.0 beta
Hi Justin, I see you have created the 0.12.x branch, but before you actually spin the beta, could I request the following... The latest commit on https://issues.apache.org/jira/browse/PROTON-1100 didnt make the branch. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24 Also since its a similarly trivial if check expansion but of more real world use, can I separately request: https://issues.apache.org/jira/browse/PROTON-1110 Thanks, Robbie
[jira] [Commented] (PROTON-1100) [proton-j] the transport should not emit other frames before the Open frame has been sent
[ https://issues.apache.org/jira/browse/PROTON-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117224#comment-15117224 ] ASF subversion and git services commented on PROTON-1100: - Commit 6422e2497b62b46db9e993059bc514a53a8ed643 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=6422e24 ] PROTON-1100: also protect against an NPE that occurs if sender link has messages on it before the Open frame is sent > [proton-j] the transport should not emit other frames before the Open frame > has been sent > - > > Key: PROTON-1100 > URL: https://issues.apache.org/jira/browse/PROTON-1100 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > As per PROTON-1070 description, the proton-j transport can emit other frames > without first sending the Open frame [because the Connection object wasnt > actually opened], which is erroneous behaviour and should be prevented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117225#comment-15117225 ] ASF subversion and git services commented on PROTON-1110: - Commit 5ec901323eb188b840a519df3e7aeea15523c218 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5ec9013 ] PROTON-1110: add toggle for suppressing the synthetic flow events generated on sending > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1, 0.12.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1050) 0.12.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117215#comment-15117215 ] ASF subversion and git services commented on PROTON-1050: - Commit 0c27d5ffbbb272902f24262f13d5c6b2985902b4 in qpid-proton's branch refs/heads/master from [~justi9] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0c27d5f ] PROTON-1050: Bump versions on master > 0.12.0 release tasks > > > Key: PROTON-1050 > URL: https://issues.apache.org/jira/browse/PROTON-1050 > Project: Qpid Proton > Issue Type: Task > Components: release >Reporter: Justin Ross >Assignee: Justin Ross > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1110: --- Affects Version/s: 0.12.0 > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1, 0.12.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
[ https://issues.apache.org/jira/browse/PROTON-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1110: --- Fix Version/s: (was: 0.12.0) 0.13.0 > [proton-j] allow suppressing the synthentic flow event when sending transfers > - > > Key: PROTON-1110 > URL: https://issues.apache.org/jira/browse/PROTON-1110 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13.0 > > > The engine emits synthetic Flow events when sending messages, in addition to > those raised when receiving a Flow frame for the link. I believe the > reasoning for this is so to treat it as a 'credit changed' indicator. > However, as there are cases where the decision to send a message has little > at all to do with the credit conditions, having these events its often > unecessary and wasteful. > A simple toggle will be added to signal the transport not to emit the flow > events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used
[ https://issues.apache.org/jira/browse/PROTON-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1107: --- Fix Version/s: (was: 0.12.0) 0.13.0 > [proton-j] only create the attachments Record on a Delivery if it actually > gets used > > > Key: PROTON-1107 > URL: https://issues.apache.org/jira/browse/PROTON-1107 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11.0, 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > We should only create the attachments Record on a Delivery if it actually > gets used. > When the Reactor bits were added in 0.10 via PROTON-881, all of the main > engine objects were made to implement the 'Extendable' interface that gave > them an 'attachments' 'Record' that can be used to store things, by default > seemingly just details relating to the Handler heirarchy as used by the > Reactor. > In the case of the Delivery objects this currently means every message sent > or received by the engine creates a RecordImpl object (which in turn holds a > HashMap). This happens regardless of whether the Reactor is even being used, > and whether there are any attachments being set/checked on the Delivery. Even > when the Reactor is being used, by default the lowest level the Handlers seem > to get looked up when process is called is at the Link level (then Session, > then Connection, etc) meaning its likely the Delivery attachments will never > be used unless by the application code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1107) [proton-j] only create the attachments Record on a Delivery if it actually gets used
[ https://issues.apache.org/jira/browse/PROTON-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-1107: --- Fix Version/s: (was: 0.13.0) 0.12.0 > [proton-j] only create the attachments Record on a Delivery if it actually > gets used > > > Key: PROTON-1107 > URL: https://issues.apache.org/jira/browse/PROTON-1107 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.10, 0.11.0, 0.11.1 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > > We should only create the attachments Record on a Delivery if it actually > gets used. > When the Reactor bits were added in 0.10 via PROTON-881, all of the main > engine objects were made to implement the 'Extendable' interface that gave > them an 'attachments' 'Record' that can be used to store things, by default > seemingly just details relating to the Handler heirarchy as used by the > Reactor. > In the case of the Delivery objects this currently means every message sent > or received by the engine creates a RecordImpl object (which in turn holds a > HashMap). This happens regardless of whether the Reactor is even being used, > and whether there are any attachments being set/checked on the Delivery. Even > when the Reactor is being used, by default the lowest level the Handlers seem > to get looked up when process is called is at the Link level (then Session, > then Connection, etc) meaning its likely the Delivery attachments will never > be used unless by the application code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1110) [proton-j] allow suppressing the synthentic flow event when sending transfers
Robbie Gemmell created PROTON-1110: -- Summary: [proton-j] allow suppressing the synthentic flow event when sending transfers Key: PROTON-1110 URL: https://issues.apache.org/jira/browse/PROTON-1110 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.11.1 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.12.0 The engine emits synthetic Flow events when sending messages, in addition to those raised when receiving a Flow frame for the link. I believe the reasoning for this is so to treat it as a 'credit changed' indicator. However, as there are cases where the decision to send a message has little at all to do with the credit conditions, having these events its often unecessary and wasteful. A simple toggle will be added to signal the transport not to emit the flow events for use in those cases. The default behaviour will be unchanged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-1104. Resolution: Fixed > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10, 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1104) reactor hangs on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117182#comment-15117182 ] ASF subversion and git services commented on PROTON-1104: - Commit 8c6c7c53198f4152472572b8fccc5ab453d9ca86 in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8c6c7c5 ] PROTON-1104: Delay releasing timer and IPC pipes until pn_reactor_stop() > reactor hangs on reconnect > -- > > Key: PROTON-1104 > URL: https://issues.apache.org/jira/browse/PROTON-1104 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10, 0.11.1 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: testcase.c > > > When the reactor's connection fails (or shuts down cleanly), and a new > connection is created on that reactor (reconnect), pn_reactor_wakeup() no > longers works properly: > pn_reactor_wakeup: : Bad file descriptor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
