[jira] [Created] (PROTON-835) strncmp in pn_data_lookup doesn't work in some cases
Sergejs Melderis created PROTON-835:
---
Summary: strncmp in pn_data_lookup doesn't work in some cases
Key: PROTON-835
URL: https://issues.apache.org/jira/browse/PROTON-835
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: Sergejs Melderis
Priority: Critical
pn_data_lookup in codec.c doesn't always work correctly when a message has two
properties in which one property is a prefix for another. In my particular use
case the properties were 'msc_gt' and 'msc_gt_service'. and the pn_data_lookup
was returning a pointer to 'msc_gt' when was called with 'msc_gt_service'.
I fixed it by comparing the length of pn_bytes_t and the length of the property
name as so:
size_t namelen = strlen(name);
pn_bytes_t bytes = pn_data_get_bytes(data);
if (namelen == bytes.size && !strncmp(name, bytes.start, bytes.size)) {
return pn_data_next(data);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: 0.9 release schedule
On Mon, 2015-03-02 at 20:46 -0500, Andrew Stitcher wrote: > On Mon, 2015-03-02 at 20:00 +, Gordon Sim wrote: > > On 03/02/2015 07:07 PM, Rafael Schloming wrote: > > > Hi Everyone, > > > > > > I'd like to propose spinning the first beta (or possibly just RC) for 0.9 > > > sometime next week. We've been using alphas to get some early eyes on some > > > of the new APIs in this release. I think when Andrew's SASL work lands > > > there will be no remaining work for 0.9 in the category of major API > > > changes/improvements. That should hopefully put us in a position to > > > quickly > > > test and stabilize things and get 0.9 out the door. > > > > The 0.9 release was originally scheduled for the end of 2014. We've had > > three alphas already. To me, its already too late in the cycle for > > 'major API changes/improvements'. > > > > As mentioned on the other thread, in my opinion it would be better to > > land Andrew's work during 0.10 allowing for less rushed review, > > evaluation and testing. > > I'm happy to let the new API work be more carefully reviewed. The only > reason to me to get it in 0.9 is that 0.9 was intended to be a point for > API stability from then on. And the transport API is a significant > change in the engine API. Pushing it off means allowing 0.10 to break > API compatibility. I'm inclined to vote with Gordon. I know 0.9 was "supposed to be" API stable, but if we are not there already (and it seems we are not) then I think we are better off getting a release out there so users that are desperately waiting for the reactive API (e.g. dispatch) can stop juggling pre-alphas. Having a 0.9 soon that is not fully API stable, followed shortly by an 0.10 that has a well tested transport API, is IMO much better than stumbling along with no release at all for an extended period and then releasing a rushed transport API that we may have to change again anyway.
[jira] [Resolved] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-833. --- Resolution: Fixed > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.9 > > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-833: -- Fix Version/s: 0.9 > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.9 > > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349120#comment-14349120 ] Robbie Gemmell commented on PROTON-833: --- Added some bounding checks that the local channel is still set in order to stop the cases I observed, which appeared to be what proton-c is doing. There may still be other cases in there. > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349117#comment-14349117 ] ASF subversion and git services commented on PROTON-833: Commit 8f810c3757c21ef32589b1bdd276e83d21659eb3 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=8f810c3 ] PROTON-833: check the local channel is still set > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned PROTON-833: - Assignee: Robbie Gemmell > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-833: -- Description: The transport can emit frames with an invalid channel number after a local session close is performed. A side effect of calling close on the session is that the channel number is unmapped when the end frame is sent, and the associated field set to the value -1. The transport can subsequently send frames which then use this -1 value, treating it as channel 65535 when sent to represent the unsigned channel number. For example, if a local link close(+detach?) call is performed in response to a remote detach after a local session close is performed, a detach frame can be emitted with channel 65535. Similarly, I have noticed disposition frames being sent with channel 65535. Proton-C appears to protect against thse situations by inspecting whether the channel number has been set as >= 0. was: The transport can emit detach frames with an invalid channel number if a local link close(+detach?) call is performed (in response to a remote detach) after a local session close is performed. When a session is locally closed by a client with open links on it, if the 'broker' sends detach frames for any of those links then the application might then do a local close on them in response. The client transport then emits detach 'response' frames as a result of this, after the session end frame has been sent. A side effect of calling close on the session is that the channel number is unmapped when the end frame is sent, and the relevant variable set to the value -1. When the transport sends the detaches outlined above it then uses the -1 value, which is treated as channel 65535 when sent as the unsigned channel number. > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell > > The transport can emit frames with an invalid channel number after a local > session close is performed. > A side effect of calling close on the session is that the channel number is > unmapped when the end frame is sent, and the associated field set to the > value -1. The transport can subsequently send frames which then use this -1 > value, treating it as channel 65535 when sent to represent the unsigned > channel number. For example, if a local link close(+detach?) call is > performed in response to a remote detach after a local session close is > performed, a detach frame can be emitted with channel 65535. Similarly, I > have noticed disposition frames being sent with channel 65535. > Proton-C appears to protect against thse situations by inspecting whether the > channel number has been set as >= 0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-833) transport can emit frames with an invalid channel number after local session close
[ https://issues.apache.org/jira/browse/PROTON-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-833: -- Summary: transport can emit frames with an invalid channel number after local session close (was: transport can emit detach frames with an invalid channel number after session end) > transport can emit frames with an invalid channel number after local session > close > -- > > Key: PROTON-833 > URL: https://issues.apache.org/jira/browse/PROTON-833 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Robbie Gemmell > > The transport can emit detach frames with an invalid channel number if a > local link close(+detach?) call is performed (in response to a remote detach) > after a local session close is performed. > When a session is locally closed by a client with open links on it, if the > 'broker' sends detach frames for any of those links then the application > might then do a local close on them in response. The client transport then > emits detach 'response' frames as a result of this, after the session end > frame has been sent. A side effect of calling close on the session is that > the channel number is unmapped when the end frame is sent, and the relevant > variable set to the value -1. When the transport sends the detaches outlined > above it then uses the -1 value, which is treated as channel 65535 when sent > as the unsigned channel number. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-834. -- Resolution: Fixed Pushed c65e897 > proton-j: UTF-8 encoder reporting some three byte characters as invalid > surrogates > -- > > Key: PROTON-834 > URL: https://issues.apache.org/jira/browse/PROTON-834 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Dominic Evans > Fix For: 0.9 > > > Following on from the fixes made under PROTON-576, some UTF-8 characters were > getting incorrectly reported as invalid surrogates, when they were valid > 3-byte encodings. > e.g., > ！！！ > (╯°□°)╯︵ ┻━┻ > etc. > This is an issue when streaming variable content such as Twitter messages > which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348396#comment-14348396 ] ASF subversion and git services commented on PROTON-834: Commit c65e89730f67cd3a8aa31c0d0de491b20810c99f in qpid-proton's branch refs/heads/master from [~dnwe] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c65e897 ] PROTON-834: modified UTF-8 encoder fixes Commit 5069bb6 applied a modified version of a patch I submitted, to ensure that the UTF-8 encoder (and UTF-8 byte length calculator) would cope with surrogate pairs. This commit fixes an issue with three byte characters in the <= 0x range being incorrectly detected as invalid four byte surrogates. Closes #10 > proton-j: UTF-8 encoder reporting some three byte characters as invalid > surrogates > -- > > Key: PROTON-834 > URL: https://issues.apache.org/jira/browse/PROTON-834 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Dominic Evans > Fix For: 0.9 > > > Following on from the fixes made under PROTON-576, some UTF-8 characters were > getting incorrectly reported as invalid surrogates, when they were valid > 3-byte encodings. > e.g., > ！！！ > (╯°□°)╯︵ ┻━┻ > etc. > This is an issue when streaming variable content such as Twitter messages > which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-834: modified UTF-8 encoder fixes
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/10 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348397#comment-14348397 ] ASF GitHub Bot commented on PROTON-834: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/10 > proton-j: UTF-8 encoder reporting some three byte characters as invalid > surrogates > -- > > Key: PROTON-834 > URL: https://issues.apache.org/jira/browse/PROTON-834 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.8 >Reporter: Dominic Evans > Fix For: 0.9 > > > Following on from the fixes made under PROTON-576, some UTF-8 characters were > getting incorrectly reported as invalid surrogates, when they were valid > 3-byte encodings. > e.g., > ！！！ > (╯°□°)╯︵ ┻━┻ > etc. > This is an issue when streaming variable content such as Twitter messages > which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
Dominic Evans created PROTON-834: Summary: proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates Key: PROTON-834 URL: https://issues.apache.org/jira/browse/PROTON-834 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans Fix For: 0.9 Following on from the fixes made under PROTON-576, some UTF-8 characters were getting incorrectly reported as invalid surrogates, when they were valid 3-byte encodings. e.g., ！！！ (╯°□°)╯︵ ┻━┻ etc. This is an issue when streaming variable content such as Twitter messages which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
