Re: qpid-proton-cpp decoder.cpp - possible bug?
Hi,
Please ignore me - I think this was actually my bug - it only happens if you
attempt to stream an empty proton::message.
Before it worked - but it looks like it shouldn't have - the new behavior seems
more correct.
Thanks
Nathan
On Mon, Sep 24, 2018 at 9:42 AM Nathan mailto:n...@gmx.es]> wrote:
Hi,
I applied the bug fix below into the code for 0.24.0
It fixes that issue, but appears to have a side effect of causing open ssl to
disconnect too soon - when the fix below is in place we get "no more data"
exceptions being thrown from decoder.cpp around line 75, but when the fix below
is removed the ssl session continues no problem.
This is the throw:
decoder::pre_get() {
if (!next()) throw conversion_error("no more data");
That doesnt happen when the fix below is removed.
Wasnt sure if perhaps I need something else from 0.25 to fix that, or if the
fix below introduced this new issue?
That doesn't ring any bells, possibly this is a regression that we missed in
testing. Can you open a JIRA with the details of how to reproduce it? I'll get
on it ASAP.
Thanks,
Alan.
Thanks
Nathan
From: Alan Conway [mailto:acon...@redhat.com[mailto:acon...@redhat.com]]
Sent: 07 September 2018 16:10
To:
users@qpid.apache.org[mailto:users@qpid.apache.org][mailto:users@qpid.apache.org[mailto:users@qpid.apache.org]]
Cc: n...@gmx.es[mailto:n...@gmx.es][mailto:n...@gmx.es[mailto:n...@gmx.es]]
Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a bug I fixed recently, it should be in the latest release
proton-0.25. If you still have a problem please raise a JIRA.
Here's the fix - NULL is somewhat special but it is a valid scalar type, so I
added it to type_id_is_scalar()
https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176[https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176][https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176[https://github.com/alanconway/qpid-proton/commit/9e8edc17%23diff-d6a2b218a8187976430ae388c2a9b176]]
On Thu, Sep 6, 2018 at 7:55 AM,
mailto:n...@gmx.es][mailto:n...@gmx.es[mailto:n...@gmx.es]]> wrote:
Hi,
Around line 180, decoder.cpp has the following:
decoder& decoder::operator>>(scalar& x) {
internal::state_guard sg(*this);
type_id got = pre_get();
if (!type_id_is_scalar(got))
throw conversion_error("expected scalar, found "+type_name(got));
x.set(pn_data_get_atom(pn_object()));
sg.cancel(); // No error, no rewind
return *this;
}
When our client code is talking to a 3rd party system's broker, we find that
the scalar in argument "x" is coming through from the other party as type NULL
in some cases - which causes the throw in the above method to get triggered and
then disconnects us from the broker.
However, if we comment out the if/throw from the code in decoder.cpp,
everything then appears to be workding 100% correctly.
Is there a correct way to do this without removing the throw? - it seems that
if the check is there it must have a purpose, so by removing the check I am
probably opening myself up to some other issues further down the line?
Thanks
N
-
To unsubscribe, e-mail:
users-unsubscr...@qpid.apache.org[mailto:users-unsubscr...@qpid.apache.org]
For additional commands, e-mail:
users-h...@qpid.apache.org[mailto:users-h...@qpid.apache.org]
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid-proton-cpp decoder.cpp - possible bug?
On Mon, Sep 24, 2018 at 9:42 AM Nathan wrote:
> Hi,
>
> I applied the bug fix below into the code for 0.24.0
>
> It fixes that issue, but appears to have a side effect of causing open ssl
> to disconnect too soon - when the fix below is in place we get "no more
> data" exceptions being thrown from decoder.cpp around line 75, but when the
> fix below is removed the ssl session continues no problem.
>
> This is the throw:
>
> decoder::pre_get() {
> if (!next()) throw conversion_error("no more data");
>
> That doesnt happen when the fix below is removed.
>
> Wasnt sure if perhaps I need something else from 0.25 to fix that, or if
> the fix below introduced this new issue?
>
That doesn't ring any bells, possibly this is a regression that we missed
in testing. Can you open a JIRA with the details of how to reproduce it?
I'll get on it ASAP.
Thanks,
Alan.
> Thanks
> Nathan
>
>
>
> From: Alan Conway [mailto:acon...@redhat.com]
> Sent: 07 September 2018 16:10
> To: users@qpid.apache.org[mailto:users@qpid.apache.org]
> Cc: n...@gmx.es[mailto:n...@gmx.es]
> Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
>
> I think this is a bug I fixed recently, it should be in the latest release
> proton-0.25. If you still have a problem please raise a JIRA.
>
> Here's the fix - NULL is somewhat special but it is a valid scalar type,
> so I added it to type_id_is_scalar()
>
>
> https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176[https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176]
>
>
>
> On Thu, Sep 6, 2018 at 7:55 AM, mailto:n...@gmx.es]> wrote:
> Hi,
>
> Around line 180, decoder.cpp has the following:
>
>
> decoder& decoder::operator>>(scalar& x) {
> internal::state_guard sg(*this);
> type_id got = pre_get();
>
> if (!type_id_is_scalar(got))
> throw conversion_error("expected scalar, found "+type_name(got));
>
> x.set(pn_data_get_atom(pn_object()));
> sg.cancel(); // No error, no rewind
> return *this;
> }
>
>
> When our client code is talking to a 3rd party system's broker, we find
> that the scalar in argument "x" is coming through from the other party as
> type NULL in some cases - which causes the throw in the above method to get
> triggered and then disconnects us from the broker.
>
> However, if we comment out the if/throw from the code in decoder.cpp,
> everything then appears to be workding 100% correctly.
>
> Is there a correct way to do this without removing the throw? - it seems
> that if the check is there it must have a purpose, so by removing the check
> I am probably opening myself up to some other issues further down the line?
>
> Thanks
> N
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
Re: qpid-proton-cpp decoder.cpp - possible bug?
Hi,
I applied the bug fix below into the code for 0.24.0
It fixes that issue, but appears to have a side effect of causing open ssl to
disconnect too soon - when the fix below is in place we get "no more data"
exceptions being thrown from decoder.cpp around line 75, but when the fix below
is removed the ssl session continues no problem.
This is the throw:
decoder::pre_get() {
if (!next()) throw conversion_error("no more data");
That doesnt happen when the fix below is removed.
Wasnt sure if perhaps I need something else from 0.25 to fix that, or if the
fix below introduced this new issue?
Thanks
Nathan
From: Alan Conway [mailto:acon...@redhat.com]
Sent: 07 September 2018 16:10
To: users@qpid.apache.org[mailto:users@qpid.apache.org]
Cc: n...@gmx.es[mailto:n...@gmx.es]
Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a bug I fixed recently, it should be in the latest release
proton-0.25. If you still have a problem please raise a JIRA.
Here's the fix - NULL is somewhat special but it is a valid scalar type, so I
added it to type_id_is_scalar()
https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176[https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176]
On Thu, Sep 6, 2018 at 7:55 AM, mailto:n...@gmx.es]> wrote:
Hi,
Around line 180, decoder.cpp has the following:
decoder& decoder::operator>>(scalar& x) {
internal::state_guard sg(*this);
type_id got = pre_get();
if (!type_id_is_scalar(got))
throw conversion_error("expected scalar, found "+type_name(got));
x.set(pn_data_get_atom(pn_object()));
sg.cancel(); // No error, no rewind
return *this;
}
When our client code is talking to a 3rd party system's broker, we find that
the scalar in argument "x" is coming through from the other party as type NULL
in some cases - which causes the throw in the above method to get triggered and
then disconnects us from the broker.
However, if we comment out the if/throw from the code in decoder.cpp,
everything then appears to be workding 100% correctly.
Is there a correct way to do this without removing the throw? - it seems that
if the check is there it must have a purpose, so by removing the check I am
probably opening myself up to some other issues further down the line?
Thanks
N
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid-proton-cpp decoder.cpp - possible bug?
This is great - many thanks for the help!
From: Alan Conway [mailto:acon...@redhat.com]
Sent: 07 September 2018 16:10
To: users@qpid.apache.org
Cc: n...@gmx.es
Subject: Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a bug I fixed recently, it should be in the latest release
proton-0.25. If you still have a problem please raise a JIRA.
Here's the fix - NULL is somewhat special but it is a valid scalar type, so I
added it to type_id_is_scalar()
https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176
On Thu, Sep 6, 2018 at 7:55 AM, wrote:
Hi,
Around line 180, decoder.cpp has the following:
decoder& decoder::operator>>(scalar& x) {
internal::state_guard sg(*this);
type_id got = pre_get();
if (!type_id_is_scalar(got))
throw conversion_error("expected scalar, found "+type_name(got));
x.set(pn_data_get_atom(pn_object()));
sg.cancel();// No error, no rewind
return *this;
}
When our client code is talking to a 3rd party system's broker, we find that
the scalar in argument "x" is coming through from the other party as type NULL
in some cases - which causes the throw in the above method to get triggered and
then disconnects us from the broker.
However, if we comment out the if/throw from the code in decoder.cpp,
everything then appears to be workding 100% correctly.
Is there a correct way to do this without removing the throw? - it seems that
if the check is there it must have a purpose, so by removing the check I am
probably opening myself up to some other issues further down the line?
Thanks
N
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Re: qpid-proton-cpp decoder.cpp - possible bug?
I think this is a bug I fixed recently, it should be in the latest release
proton-0.25. If you still have a problem please raise a JIRA.
Here's the fix - NULL is somewhat special but it is a valid scalar type, so
I added it to type_id_is_scalar()
https://github.com/alanconway/qpid-proton/commit/9e8edc17#diff-d6a2b218a8187976430ae388c2a9b176
On Thu, Sep 6, 2018 at 7:55 AM, wrote:
> Hi,
>
> Around line 180, decoder.cpp has the following:
>
>
> decoder& decoder::operator>>(scalar& x) {
> internal::state_guard sg(*this);
> type_id got = pre_get();
>
> if (!type_id_is_scalar(got))
> throw conversion_error("expected scalar, found "+type_name(got));
>
> x.set(pn_data_get_atom(pn_object()));
> sg.cancel();// No error, no rewind
> return *this;
> }
>
>
> When our client code is talking to a 3rd party system's broker, we find
> that the scalar in argument "x" is coming through from the other party as
> type NULL in some cases - which causes the throw in the above method to get
> triggered and then disconnects us from the broker.
>
> However, if we comment out the if/throw from the code in decoder.cpp,
> everything then appears to be workding 100% correctly.
>
> Is there a correct way to do this without removing the throw? - it seems
> that if the check is there it must have a purpose, so by removing the check
> I am probably opening myself up to some other issues further down the line?
>
> Thanks
> N
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>
