[jira] [Created] (PROTON-725) pni_parse_url does not properly handle Base64 in URL
Adam Nemcek created PROTON-725:
--
Summary: pni_parse_url does not properly handle Base64 in URL
Key: PROTON-725
URL: https://issues.apache.org/jira/browse/PROTON-725
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: Adam Nemcek
Priority: Minor
Our provisioning system provides us with a password in Base64 format, which can
actually contain a slash character(s): '/'
This breaks the ability of {{pni_parse_url()}} to handle such URLs.
Example of URL string on which the parsing fails:
{{amqps://0ABCDEF1:/ExlxtfN+UxfExRxuwxIeFxeFzXLxxg+fxPx3x8xxU=@myself.servicebus.windows.net/out/t/Subscriptions/s}}
Instead of filling up the user and password variables, it puts the actual
contents to host and port.
With the actual code it is a correct behavior - and *it is* also mentioned in
the comment right in front of the pni_parse_url() function.
Yet I would need an update to the functionality, to handle the Base64 in
password properly (anyone on Azure platform might run to this issue, soon or
later).
Note. I'm running the SVN rev 1633464 (latest trunk of 10/23/2014) version of
ProtonC (C / Linux).
Thanks for looking at this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-726) Macros to wrap malloc(), realloc(), free()
Adam Nemcek created PROTON-726:
--
Summary: Macros to wrap malloc(), realloc(), free()
Key: PROTON-726
URL: https://issues.apache.org/jira/browse/PROTON-726
Project: Qpid Proton
Issue Type: Wish
Components: proton-c
Affects Versions: 0.8
Reporter: Adam Nemcek
Priority: Trivial
As we are porting ProtonC across various platforms, we take the trunk code and
use it in a specific project. I would like to be able to take any newer version
from SVN and use it, without the need to modify it each every time, to suit the
target system specifics.
Therefore, I would like to kindly ask for an official support of macros to
replace the memory allocation functions.
Create a single global header file (or reuse some existing one, like the
platform.h), and add a three new macros to it.
Having macros in place of general malloc(), realloc() and free() calls, will
allow to keep the ported version easily update-able when new ProtonC version
comes out (there won't be no need to manually go through all the files and
replacing the calls with other calls).
For Linux (or Windows), the macros will directly link to the default functions.
For other OS(es), the developer will be able to just rewrite three lines of
code and be all set.
Example:
{{pn_buffer_t *buf = (pn_buffer_t *)malloc(sizeof(pn_buffer_t));}}
will get replaced with something like this
{{pn_buffer_t *buf = (pn_buffer_t *)MALLOC_MACRO(sizeof(pn_buffer_t));}}
where (for Linux) it will be:
{{#define MALLOC_MACRO malloc}}
or for other OS it might then be:
{{#define MALLOC_MACRO customMalloc}}
Of course, I do not care about the naming of the macros, or the actual code
style.
I will leave all this on the official developers, I just ask to get such a
functionality in.
This change should have no impact on functionality, code size or speed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-727) Add a NULL-pointer checks to malloc() and realloc() calls
German Shepherd created PROTON-727:
--
Summary: Add a NULL-pointer checks to malloc() and realloc() calls
Key: PROTON-727
URL: https://issues.apache.org/jira/browse/PROTON-727
Project: Qpid Proton
Issue Type: Wish
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd
Priority: Minor
As we are running the ProtonC project on memory constrained systems, it is
possible for malloc() or realloc() to return a NULL, when there is no more free
heap to allocate the memory from.
Obviously, we might have a specific optimizations in the ProtonC code, which
deeply minimize the amount of a total heap required, but this is not what this
ticket is referring to.
In any case where there is no more free heap, or in a case where there is any
other issue with the allocators, the memory allocation functions return NULL.
The ProtonC code at this state, does not check for such a situation, and it
always expects the malloc() and realloc() to work and to return a valid pointer.
I would like the developers to add a specific test to each place, where memory
allocation takes place, and to act upon an error properly (ideally - with a
graceful closure of the connection to broker, if possible).
Also, a proper signalization path to the user's application (which runs the
ProtonC client) would be a great addition.
If nothing fancy is planned, I would, at least, ask for adding the simple {{ if
(x == NULL) { do something }; }} tests to each every place where memory
allocation is handled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-725) pni_parse_url does not properly handle Base64 in URL
[
https://issues.apache.org/jira/browse/PROTON-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182596#comment-14182596
]
Dominic Evans commented on PROTON-725:
--
[~E528527] this is what URL encoding was designed for? :) You should replace
any reserved characters in the password before using it in the amqp:// URL
See http://en.wikipedia.org/wiki/Percent-encoding
%2F would replace the / in your password
pni_parse_url does not properly handle Base64 in URL
Key: PROTON-725
URL: https://issues.apache.org/jira/browse/PROTON-725
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd
Priority: Minor
Our provisioning system provides us with a password in Base64 format, which
can actually contain a slash character(s): '/'
This breaks the ability of {{pni_parse_url()}} to handle such URLs.
Example of URL string on which the parsing fails:
{{amqps://0ABCDEF1:/ExlxtfN+UxfExRxuwxIeFxeFzXLxxg+fxPx3x8xxU=@myself.servicebus.windows.net/out/t/Subscriptions/s}}
Instead of filling up the user and password variables, it puts the actual
contents to host and port.
With the actual code it is a correct behavior - and *it is* also mentioned in
the comment right in front of the pni_parse_url() function.
Yet I would need an update to the functionality, to handle the Base64 in
password properly (anyone on Azure platform might run to this issue, soon or
later).
Note. I'm running the SVN rev 1633464 (latest trunk of 10/23/2014) version of
ProtonC (C / Linux).
Thanks for looking at this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-725) pni_parse_url does not properly handle Base64 in URL
[
https://issues.apache.org/jira/browse/PROTON-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182604#comment-14182604
]
German Shepherd commented on PROTON-725:
Thanks for a response - you have a good point there.
To explain my situation:
the (cloud) Provisioning Service does not provide the escaped URL, but instead
it gives me the values unescaped, and this is what I've directly fed to the
pni_parse_url().
Fix is simple then - to modify our user code, and keep pni_parse_url() intact.
But then - *will the ProtonC be able to unescape the URL ?*
I'm not sure about it (I will try it, of course - but I have not seen any
unescape() or such, in ProtonC code, after the URL gets parsed).
At this moment, this issue will possibly happen only with password field, so
it is more like a question for Azure, whether it will accept escaped password
via SASL. I doubt that - I would say that SASL will want to see the very same
'password' in the very same format, as it provided to us via Provisioning.
Hmm this will not be that easy after all...
pni_parse_url does not properly handle Base64 in URL
Key: PROTON-725
URL: https://issues.apache.org/jira/browse/PROTON-725
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd
Priority: Minor
Our provisioning system provides us with a password in Base64 format, which
can actually contain a slash character(s): '/'
This breaks the ability of {{pni_parse_url()}} to handle such URLs.
Example of URL string on which the parsing fails:
{{amqps://0ABCDEF1:/ExlxtfN+UxfExRxuwxIeFxeFzXLxxg+fxPx3x8xxU=@myself.servicebus.windows.net/out/t/Subscriptions/s}}
Instead of filling up the user and password variables, it puts the actual
contents to host and port.
With the actual code it is a correct behavior - and *it is* also mentioned in
the comment right in front of the pni_parse_url() function.
Yet I would need an update to the functionality, to handle the Base64 in
password properly (anyone on Azure platform might run to this issue, soon or
later).
Note. I'm running the SVN rev 1633464 (latest trunk of 10/23/2014) version of
ProtonC (C / Linux).
Thanks for looking at this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
[ X ] Yes, release Proton 0.8 RC4 as 0.8 final. I ran the C and Java build+tests, tried out the Java binaries with the JMS client build+tests, all seemed fine. Robbie On 23 October 2014 17:21, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, I've put together RC4. This is pretty much the same as RC3 with a number of fixes to disable those SSL versions that are vulnerable to attack. The sources are available here: - http://people.apache.org/~rhs/qpid-proton-0.8rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1020/ Changes since RC3: - PROTON-724: make sure to pop any pending output in pn_transport_close_head() - PROTON-720: [Windows IO] fix format specifier to print string - added dispatch utility - fixed error message - fixed Collector.put - PROTON-719 : prevent ssl3 connections in Windows with schannel - PROTON-717: disable SSLv3 - PROTON-717: mitigate the CRIME SSL vulnerability - PROTON-716: reject connections using SSLv3 - it is insecure Please check the sources out and register your vote: [ ] Yes, release Proton 0.8 RC4 as 0.8 final. [ ] No, because... --Rafael
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
[ X ] Yes, release Proton 0.8 RC4 as 0.8 final. Tested Proton-J with ActiveMQ and the new JMS client and found no issues, On 10/23/2014 12:21 PM, Rafael Schloming wrote: Hi Everyone, I've put together RC4. This is pretty much the same as RC3 with a number of fixes to disable those SSL versions that are vulnerable to attack. The sources are available here: - http://people.apache.org/~rhs/qpid-proton-0.8rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1020/ Changes since RC3: - PROTON-724: make sure to pop any pending output in pn_transport_close_head() - PROTON-720: [Windows IO] fix format specifier to print string - added dispatch utility - fixed error message - fixed Collector.put - PROTON-719 : prevent ssl3 connections in Windows with schannel - PROTON-717: disable SSLv3 - PROTON-717: mitigate the CRIME SSL vulnerability - PROTON-716: reject connections using SSLv3 - it is insecure Please check the sources out and register your vote: [ ] Yes, release Proton 0.8 RC4 as 0.8 final. [ ] No, because... --Rafael -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
[ X ] Yes, release Proton 0.8 RC4 as 0.8 final. Compiled on Windows Server 2012, Visual Studios 2008, 2010, 2012, 2013. Ran some tests on a few kits with no issues.
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo, I used proton 0.7 and later when I had an error, proton 0.8 RC4 to build qpid-cpp-0.30. In both cases at some time qpidd aborts in proton library in the following location: #0 0x003999432635 in raise () from /lib64/libc.so.6 #1 0x003999433e15 in abort () from /lib64/libc.so.6 #2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6 #3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6 #4 0x7f130a5af37d in pn_full_settle (db=value optimized out, delivery=0x7f13001545f0) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742 #5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786 #6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0, frame=...) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65 #7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172 #8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0, bytes=0x1b75e10 , available=0) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194 #9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value optimized out, bytes=value optimized out, available=value optimized out) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145 #10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064 #11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0, size=value optimized out) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120 #12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0, bytes=0x1b2a9b6 eeded\n, available=0) at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039 #13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode (this=0x1b6c4c8, buffer=0x1b2a880 , size=310) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119 #14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode (this=0x1b6c470, buffer=value optimized out, size=310) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49 #15 0x7f130b0e9100 in qpid::sys::AsynchIOHandler::readbuff (this=0x1b29a90, buff=0x1b6a890) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/AsynchIOHandler.cpp:135 #16 0x7f130b0689e7 in operator() (this=0x1b29ad0, h=...) at /usr/include/boost/function/function_template.hpp:1013 #17 qpid::sys::posix::AsynchIO::readable (this=0x1b29ad0, h=...) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/AsynchIO.cpp:452 #18 0x7f130b0ed853 in boost::function1void, qpid::sys::DispatchHandle::operator() (this=value optimized out, a0=value optimized out) at /usr/include/boost/function/function_template.hpp:1013 #19 0x7f130b0ec991 in qpid::sys::DispatchHandle::processEvent (this=0x1b29ad8, type=qpid::sys::Poller::READABLE) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/DispatchHandle.cpp:280 #20 0x7f130b08d4f2 in process (this=0x176cc90) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/Poller.h:131 #21 qpid::sys::Poller::run (this=0x176cc90) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/epoll/EpollPoller.cpp:522 #22 0x7f130b08240a in qpid::sys::(anonymous namespace)::runRunnable (p=value optimized out) at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/Thread.cpp:35 #23 0x003999c079d1 in start_thread () from /lib64/libpthread.so.0 #24 0x0039994e886d in clone () from /lib64/libc.so.6 I have core file and probably I can try to recreate the situation. Best regards, 24.10.2014 17:05, Timothy Bish пишет: [ X ] Yes, release Proton 0.8 RC4 as 0.8 final. Tested Proton-J with ActiveMQ and the new JMS client and found no issues, On 10/23/2014 12:21 PM, Rafael Schloming wrote: Hi Everyone, I've put together RC4. This is pretty much the same as RC3 with a number of fixes to disable those SSL versions that are vulnerable to attack. The sources are available here: - http://people.apache.org/~rhs/qpid-proton-0.8rc4/ Java binaries are here: - https://repository.apache.org/content/repositories/orgapacheqpid-1020/ Changes since RC3: - PROTON-724: make sure to pop any pending output in pn_transport_close_head() - PROTON-720: [Windows IO] fix format specifier to print string - added dispatch utility - fixed error message - fixed Collector.put - PROTON-719 : prevent ssl3 connections in Windows with schannel - PROTON-717: disable SSLv3 - PROTON-717: mitigate the CRIME SSL vulnerability - PROTON-716: reject connections using SSLv3 - it is insecure Please check the sources out and register your vote: [ ] Yes, release Proton 0.8 RC4 as 0.8 final. [ ] No, because... --Rafael -- \ / | | (OvO) | Mikhail Iwanow | (^^^) |
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
From the trace, it seems like the broker is receiving a transfer whose
delivery id is out of order.
This shouldn't cause an abort - likely the result is an untested failure path,
in transport.c:781:
if (id_present id != state-id) {
int err = pn_do_error(transport, amqp:session:invalid-field,
sequencing error, expected delivery-id %u, got %u,
state-id, id);
// XXX: this will probably leave delivery buffer state messed up
pn_full_settle(incoming, delivery);
return err;
}
It doesn't explain why a transfer is sent out of order by the client, but at
least we probably should remove the attempt to pn_full_settle(), and just
return the error to fail the connection (assumed - totally untested).
-K
- Original Message -
From: Michael Ivanov iv...@logit-ag.de
To: proton@qpid.apache.org
Sent: Friday, October 24, 2014 9:38:54 AM
Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo,
I used proton 0.7 and later when I had an error, proton 0.8 RC4 to build
qpid-cpp-0.30. In both cases at some time qpidd aborts in proton library
in the following location:
#0 0x003999432635 in raise () from /lib64/libc.so.6
#1 0x003999433e15 in abort () from /lib64/libc.so.6
#2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6
#4 0x7f130a5af37d in pn_full_settle (db=value optimized out,
delivery=0x7f13001545f0)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742
#5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786
#6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0, frame=...)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65
#7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172
#8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0,
bytes=0x1b75e10 , available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194
#9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value optimized out,
bytes=value optimized out, available=value
optimized out)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145
#10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064
#11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0,
size=value optimized out)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120
#12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0,
bytes=0x1b2a9b6 eeded\n, available=0)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039
#13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode
(this=0x1b6c4c8, buffer=0x1b2a880 , size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119
#14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode (this=0x1b6c470,
buffer=value optimized out, size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49
#15 0x7f130b0e9100 in qpid::sys::AsynchIOHandler::readbuff
(this=0x1b29a90, buff=0x1b6a890)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/AsynchIOHandler.cpp:135
#16 0x7f130b0689e7 in operator() (this=0x1b29ad0, h=...) at
/usr/include/boost/function/function_template.hpp:1013
#17 qpid::sys::posix::AsynchIO::readable (this=0x1b29ad0, h=...) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/AsynchIO.cpp:452
#18 0x7f130b0ed853 in boost::function1void,
qpid::sys::DispatchHandle::operator() (this=value optimized out,
a0=value optimized out) at
/usr/include/boost/function/function_template.hpp:1013
#19 0x7f130b0ec991 in qpid::sys::DispatchHandle::processEvent
(this=0x1b29ad8, type=qpid::sys::Poller::READABLE)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/DispatchHandle.cpp:280
#20 0x7f130b08d4f2 in process (this=0x176cc90) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/Poller.h:131
#21 qpid::sys::Poller::run (this=0x176cc90) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/epoll/EpollPoller.cpp:522
#22 0x7f130b08240a in qpid::sys::(anonymous namespace)::runRunnable
(p=value optimized out)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/Thread.cpp:35
#23 0x003999c079d1 in start_thread () from /lib64/libpthread.so.0
#24 0x0039994e886d in clone () from /lib64/libc.so.6
I have core file and probably I can try to recreate the situation.
Best regards,
24.10.2014 17:05, Timothy Bish пишет:
[ X ] Yes, release Proton 0.8 RC4 as 0.8 final.
Tested Proton-J with ActiveMQ and the new JMS client and found no issues,
On 10/23/2014 12:21 PM, Rafael Schloming wrote:
Hi Everyone,
I've put together
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
I just rebuilt all client processes to use proton 0.8 (it was still 0.7 before)
Error is still the same.
Best regards,
24.10.2014 18:16, Ken Giusti пишет:
From the trace, it seems like the broker is receiving a transfer whose
delivery id is out of order.
This shouldn't cause an abort - likely the result is an untested failure
path, in transport.c:781:
if (id_present id != state-id) {
int err = pn_do_error(transport, amqp:session:invalid-field,
sequencing error, expected delivery-id %u, got
%u,
state-id, id);
// XXX: this will probably leave delivery buffer state messed up
pn_full_settle(incoming, delivery);
return err;
}
It doesn't explain why a transfer is sent out of order by the client, but at
least we probably should remove the attempt to pn_full_settle(), and just
return the error to fail the connection (assumed - totally untested).
-K
- Original Message -
From: Michael Ivanov iv...@logit-ag.de
To: proton@qpid.apache.org
Sent: Friday, October 24, 2014 9:38:54 AM
Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo,
I used proton 0.7 and later when I had an error, proton 0.8 RC4 to build
qpid-cpp-0.30. In both cases at some time qpidd aborts in proton library
in the following location:
#0 0x003999432635 in raise () from /lib64/libc.so.6
#1 0x003999433e15 in abort () from /lib64/libc.so.6
#2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6
#4 0x7f130a5af37d in pn_full_settle (db=value optimized out,
delivery=0x7f13001545f0)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742
#5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786
#6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0, frame=...)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65
#7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172
#8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0,
bytes=0x1b75e10 , available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194
#9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value optimized out,
bytes=value optimized out, available=value
optimized out)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145
#10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064
#11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0,
size=value optimized out)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120
#12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0,
bytes=0x1b2a9b6 eeded\n, available=0)
at /home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039
#13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode
(this=0x1b6c4c8, buffer=0x1b2a880 , size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119
#14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode (this=0x1b6c470,
buffer=value optimized out, size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49
#15 0x7f130b0e9100 in qpid::sys::AsynchIOHandler::readbuff
(this=0x1b29a90, buff=0x1b6a890)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/AsynchIOHandler.cpp:135
#16 0x7f130b0689e7 in operator() (this=0x1b29ad0, h=...) at
/usr/include/boost/function/function_template.hpp:1013
#17 qpid::sys::posix::AsynchIO::readable (this=0x1b29ad0, h=...) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/AsynchIO.cpp:452
#18 0x7f130b0ed853 in boost::function1void,
qpid::sys::DispatchHandle::operator() (this=value optimized out,
a0=value optimized out) at
/usr/include/boost/function/function_template.hpp:1013
#19 0x7f130b0ec991 in qpid::sys::DispatchHandle::processEvent
(this=0x1b29ad8, type=qpid::sys::Poller::READABLE)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/DispatchHandle.cpp:280
#20 0x7f130b08d4f2 in process (this=0x176cc90) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/Poller.h:131
#21 qpid::sys::Poller::run (this=0x176cc90) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/epoll/EpollPoller.cpp:522
#22 0x7f130b08240a in qpid::sys::(anonymous namespace)::runRunnable
(p=value optimized out)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/Thread.cpp:35
#23 0x003999c079d1 in start_thread () from /lib64/libpthread.so.0
#24 0x0039994e886d in clone () from /lib64/libc.so.6
I have core file and probably I can try to recreate the situation.
Best regards,
24.10.2014 17:05, Timothy Bish пишет:
[ X ] Yes, release Proton 0.8 RC4 as 0.8
[jira] [Created] (PROTON-728) transport aborts when delivery ids are out of sequence
Rafael H. Schloming created PROTON-728: -- Summary: transport aborts when delivery ids are out of sequence Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-728) transport aborts when delivery ids are out of sequence
[ https://issues.apache.org/jira/browse/PROTON-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183209#comment-14183209 ] ASF subversion and git services commented on PROTON-728: Commit 1634115 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1634115 ] PROTON-728: don't try to settle the delivery, just abort the connection transport aborts when delivery ids are out of sequence -- Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hi Michael,
I just committed the change Ken suggested to at least fix the abort. Is
there any way you could retest with trunk?
If the problem still occurs (I expect it will, just not quite so fatally)
it would be good to get the protocol trace for both the client and the
server and see if that will shed some light on what is going on.
--Rafael
On Fri, Oct 24, 2014 at 2:00 PM, Michael Ivanov iv...@logit-ag.de wrote:
I just rebuilt all client processes to use proton 0.8 (it was still 0.7
before)
Error is still the same.
Best regards,
24.10.2014 18:16, Ken Giusti пишет:
From the trace, it seems like the broker is receiving a transfer whose
delivery id is out of order.
This shouldn't cause an abort - likely the result is an untested failure
path, in transport.c:781:
if (id_present id != state-id) {
int err = pn_do_error(transport, amqp:session:invalid-field,
sequencing error, expected delivery-id %u,
got %u,
state-id, id);
// XXX: this will probably leave delivery buffer state messed up
pn_full_settle(incoming, delivery);
return err;
}
It doesn't explain why a transfer is sent out of order by the client,
but at least we probably should remove the attempt to pn_full_settle(), and
just return the error to fail the connection (assumed - totally untested).
-K
- Original Message -
From: Michael Ivanov iv...@logit-ag.de
To: proton@qpid.apache.org
Sent: Friday, October 24, 2014 9:38:54 AM
Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo,
I used proton 0.7 and later when I had an error, proton 0.8 RC4 to build
qpid-cpp-0.30. In both cases at some time qpidd aborts in proton library
in the following location:
#0 0x003999432635 in raise () from /lib64/libc.so.6
#1 0x003999433e15 in abort () from /lib64/libc.so.6
#2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6
#4 0x7f130a5af37d in pn_full_settle (db=value optimized out,
delivery=0x7f13001545f0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742
#5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786
#6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0,
frame=...)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65
#7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172
#8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0,
bytes=0x1b75e10 , available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194
#9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value optimized
out,
bytes=value optimized out, available=value
optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145
#10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064
#11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0,
size=value optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120
#12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0,
bytes=0x1b2a9b6 eeded\n, available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039
#13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode
(this=0x1b6c4c8, buffer=0x1b2a880 , size=310)
at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119
#14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode
(this=0x1b6c470,
buffer=value optimized out, size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49
#15 0x7f130b0e9100 in qpid::sys::AsynchIOHandler::readbuff
(this=0x1b29a90, buff=0x1b6a890)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/AsynchIOHandler.cpp:135
#16 0x7f130b0689e7 in operator() (this=0x1b29ad0, h=...) at
/usr/include/boost/function/function_template.hpp:1013
#17 qpid::sys::posix::AsynchIO::readable (this=0x1b29ad0, h=...) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/AsynchIO.cpp:452
#18 0x7f130b0ed853 in boost::function1void,
qpid::sys::DispatchHandle::operator() (this=value optimized out,
a0=value optimized out) at
/usr/include/boost/function/function_template.hpp:1013
#19 0x7f130b0ec991 in qpid::sys::DispatchHandle::processEvent
(this=0x1b29ad8, type=qpid::sys::Poller::READABLE)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/DispatchHandle.cpp:280
#20 0x7f130b08d4f2 in process (this=0x176cc90) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/Poller.h:131
#21 qpid::sys::Poller::run (this=0x176cc90) at
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Sorry, should I check out the trunk from the repository or can I download
the new sources tar archive from somewhere? The last version I used I have
downloaded from
http://people.apache.org/~rhs/qpid-proton-0.8rc4/qpid-proton-0.8.tar.gz
If the sources are to be checked out which url should I use?
And pls can you explain me how to turn the proitocol trace on? Or should I
just tcpdump during exchange?
Best regards,
24.10.2014 22:24, Rafael Schloming пишет:
Hi Michael,
I just committed the change Ken suggested to at least fix the abort. Is
there any way you could retest with trunk?
If the problem still occurs (I expect it will, just not quite so fatally)
it would be good to get the protocol trace for both the client and the
server and see if that will shed some light on what is going on.
--Rafael
On Fri, Oct 24, 2014 at 2:00 PM, Michael Ivanov iv...@logit-ag.de wrote:
I just rebuilt all client processes to use proton 0.8 (it was still 0.7
before)
Error is still the same.
Best regards,
24.10.2014 18:16, Ken Giusti пишет:
From the trace, it seems like the broker is receiving a transfer whose
delivery id is out of order.
This shouldn't cause an abort - likely the result is an untested failure
path, in transport.c:781:
if (id_present id != state-id) {
int err = pn_do_error(transport, amqp:session:invalid-field,
sequencing error, expected delivery-id %u,
got %u,
state-id, id);
// XXX: this will probably leave delivery buffer state messed up
pn_full_settle(incoming, delivery);
return err;
}
It doesn't explain why a transfer is sent out of order by the client,
but at least we probably should remove the attempt to pn_full_settle(), and
just return the error to fail the connection (assumed - totally untested).
-K
- Original Message -
From: Michael Ivanov iv...@logit-ag.de
To: proton@qpid.apache.org
Sent: Friday, October 24, 2014 9:38:54 AM
Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo,
I used proton 0.7 and later when I had an error, proton 0.8 RC4 to build
qpid-cpp-0.30. In both cases at some time qpidd aborts in proton library
in the following location:
#0 0x003999432635 in raise () from /lib64/libc.so.6
#1 0x003999433e15 in abort () from /lib64/libc.so.6
#2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6
#4 0x7f130a5af37d in pn_full_settle (db=value optimized out,
delivery=0x7f13001545f0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742
#5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786
#6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0,
frame=...)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65
#7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172
#8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0,
bytes=0x1b75e10 , available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194
#9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value optimized
out,
bytes=value optimized out, available=value
optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145
#10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064
#11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0,
size=value optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120
#12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0,
bytes=0x1b2a9b6 eeded\n, available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039
#13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode
(this=0x1b6c4c8, buffer=0x1b2a880 , size=310)
at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119
#14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode
(this=0x1b6c470,
buffer=value optimized out, size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49
#15 0x7f130b0e9100 in qpid::sys::AsynchIOHandler::readbuff
(this=0x1b29a90, buff=0x1b6a890)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/AsynchIOHandler.cpp:135
#16 0x7f130b0689e7 in operator() (this=0x1b29ad0, h=...) at
/usr/include/boost/function/function_template.hpp:1013
#17 qpid::sys::posix::AsynchIO::readable (this=0x1b29ad0, h=...) at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/sys/posix/AsynchIO.cpp:452
#18 0x7f130b0ed853 in boost::function1void,
qpid::sys::DispatchHandle::operator() (this=value optimized out,
a0=value optimized out) at
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
You can check out the trunk source code from here:
http://svn.apache.org/repos/asf/qpid/proton/trunk/
You should be able to turn on the protocol trace by setting the
PN_TRACE_FRM environment variable to 1, e.g.:
export PN_TRACE_FRM=1
run-client-program
You will need to do this on the server side as well in order to get the
server's version of the protocol trace.
--Rafael
On Fri, Oct 24, 2014 at 2:31 PM, Michael Ivanov iv...@logit-ag.de wrote:
Sorry, should I check out the trunk from the repository or can I download
the new sources tar archive from somewhere? The last version I used I have
downloaded from
http://people.apache.org/~rhs/qpid-proton-0.8rc4/qpid-proton-0.8.tar.gz
If the sources are to be checked out which url should I use?
And pls can you explain me how to turn the proitocol trace on? Or should I
just tcpdump during exchange?
Best regards,
24.10.2014 22:24, Rafael Schloming пишет:
Hi Michael,
I just committed the change Ken suggested to at least fix the abort. Is
there any way you could retest with trunk?
If the problem still occurs (I expect it will, just not quite so fatally)
it would be good to get the protocol trace for both the client and the
server and see if that will shed some light on what is going on.
--Rafael
On Fri, Oct 24, 2014 at 2:00 PM, Michael Ivanov iv...@logit-ag.de
wrote:
I just rebuilt all client processes to use proton 0.8 (it was still 0.7
before)
Error is still the same.
Best regards,
24.10.2014 18:16, Ken Giusti пишет:
From the trace, it seems like the broker is receiving a transfer whose
delivery id is out of order.
This shouldn't cause an abort - likely the result is an untested
failure
path, in transport.c:781:
if (id_present id != state-id) {
int err = pn_do_error(transport, amqp:session:invalid-field,
sequencing error, expected delivery-id %u,
got %u,
state-id, id);
// XXX: this will probably leave delivery buffer state messed up
pn_full_settle(incoming, delivery);
return err;
}
It doesn't explain why a transfer is sent out of order by the client,
but at least we probably should remove the attempt to pn_full_settle(),
and
just return the error to fail the connection (assumed - totally
untested).
-K
- Original Message -
From: Michael Ivanov iv...@logit-ag.de
To: proton@qpid.apache.org
Sent: Friday, October 24, 2014 9:38:54 AM
Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo,
I used proton 0.7 and later when I had an error, proton 0.8 RC4 to
build
qpid-cpp-0.30. In both cases at some time qpidd aborts in proton
library
in the following location:
#0 0x003999432635 in raise () from /lib64/libc.so.6
#1 0x003999433e15 in abort () from /lib64/libc.so.6
#2 0x00399942b75e in __assert_fail_base () from /lib64/libc.so.6
#3 0x00399942b820 in __assert_fail () from /lib64/libc.so.6
#4 0x7f130a5af37d in pn_full_settle (db=value optimized out,
delivery=0x7f13001545f0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:742
#5 0x7f130a5b0cbe in pn_do_transfer (disp=0x1b6dcf0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:786
#6 0x7f130a5a94d5 in pni_dispatch_action (disp=0x1b6dcf0,
frame=...)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:65
#7 pn_dispatch_frame (disp=0x1b6dcf0, frame=...) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:172
#8 0x7f130a5a9718 in pn_dispatcher_input (disp=0x1b6dcf0,
bytes=0x1b75e10 , available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/dispatcher/dispatcher.c:194
#9 0x7f130a5b2606 in pn_input_read_amqp (io_layer=value
optimized
out,
bytes=value optimized out, available=value
optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1145
#10 0x7f130a5ae029 in transport_consume (transport=0x1b6dab0) at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1064
#11 0x7f130a5ae198 in pn_transport_process (transport=0x1b6dab0,
size=value optimized out)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:2120
#12 0x7f130a5ae8e0 in pn_transport_input (transport=0x1b6dab0,
bytes=0x1b2a9b6 eeded\n, available=0)
at
/home/ksmgr/mq/qpid-proton-0.8/proton-c/src/transport/transport.c:1039
#13 0x7f130a81c192 in qpid::broker::amqp::Connection::decode
(this=0x1b6c4c8, buffer=0x1b2a880 , size=310)
at
/home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Connection.cpp:119
#14 0x7f130a858c99 in qpid::broker::amqp::Sasl::decode
(this=0x1b6c470,
buffer=value optimized out, size=310)
at /home/ksmgr/mq/qpid-cpp-0.30/src/qpid/broker/amqp/Sasl.cpp:49
#15 0x7f130b0e9100 in
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Ok I have some results. Now the core is not dumped but I have unusual delays during application startup. I have started qpidd up with PN_TRACE_FRM set, but do not see any trace output. Only thing I have are the following entries from syslog: Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initializing Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Security] notice SSL plugin not enabled, you must set --ssl-cert-db to enable it. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Journal TplStore: Created Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Store module initialized; store-dir=/var/spool/qpid Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] warning Message store plugin: No storage providers available. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Network] notice Listening on TCP/TCP6 port 5672 Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initialized Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 running Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39178 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39180 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [Management] error Detected two management objects with the same identifier: 0-5-1--174(org.apache.qpid.broker:incoming:aa8fef78-607a-4913-a9ba-f10972657cd7,sender-xxx) Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39182 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39184 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39186 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39188 No protocol received closing Oct 24 21:21:06 ccsfat qpidd[28477]: 2014-10-24 21:21:06 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39195 No protocol received closing With client processes it's a little better. Here's the output from one of the processes: [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :LOGIN, :PLAIN, :GSSAPI]] [0x82dd50]:0 - @sasl-outcome(68) [code=0] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=f58f77fd-6473-4cd9-8a55-7a4d1ed083b2, hostname=127.0.0.1] [0x82dd50]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [address=TPRBOX, durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1, drain=false] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=e5584c39-5ae9-4fad-ba53-2528475d71ba] [0x82dd50]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @transfer(20) [handle=0, delivery-id=0, delivery-tag=b\x00\x00\x00\x00, message-format=0, settled=false, more=false] (255) \x00Sp\xc0\x06\x04BP\x04@A\x00Ss\xd0\x00\x00\x008\x00\x00\x00\x0d@@\xa1\x15amqp://0.0.0.0/TPRBOX@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\xaf\x08\x00\x00\x00\x00\x00\x00\x00\x8c#\x00\x00\x00\x00\x00\x00!\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00apol\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00!\x00\x00\x00apol\x00\x00\x00\x005 AP\x00\x00\x00\x00\x00\x00\x00\x003\x00\x00\x0024.10.14 21:21:35 APOL _RECEIVE: Timer1 timed out.\x0a\x00%G\x01\x999\x00\x00 [0x82dd50]:0 - @flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=1, link-credit=1, drain=false] [0x82dd50]:0 - @disposition(21) [role=true, first=0, last=0, settled=true] [0x82dd50]:0 - @transfer(20) [handle=0,
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hi Michael, Sorry for misleading you. I think the way qpidd integrates proton must override the PN_TRACE_FRM configuration. I believe you should be able to get the protocol trace from the broker by using the -t option, e.g. qpidd -t. I'll take a look at the logs you posted, however I suspect the most useful one will be the broker trace, so I would appreciate any effort you can make to obtain it. Thanks, --Rafael On Fri, Oct 24, 2014 at 3:40 PM, Michael Ivanov iv...@logit-ag.de wrote: Ok I have some results. Now the core is not dumped but I have unusual delays during application startup. I have started qpidd up with PN_TRACE_FRM set, but do not see any trace output. Only thing I have are the following entries from syslog: Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initializing Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Security] notice SSL plugin not enabled, you must set --ssl-cert-db to enable it. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Journal TplStore: Created Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Store module initialized; store-dir=/var/spool/qpid Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] warning Message store plugin: No storage providers available. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Network] notice Listening on TCP/TCP6 port 5672 Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initialized Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 running Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39178 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39180 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [Management] error Detected two management objects with the same identifier: 0-5-1--174(org.apache.qpid.broker:incoming:aa8fef78-607a-4913-a9ba-f10972657cd7,sender-xxx) Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39182 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39184 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39186 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39188 No protocol received closing Oct 24 21:21:06 ccsfat qpidd[28477]: 2014-10-24 21:21:06 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39195 No protocol received closing With client processes it's a little better. Here's the output from one of the processes: [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :LOGIN, :PLAIN, :GSSAPI]] [0x82dd50]:0 - @sasl-outcome(68) [code=0] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=f58f77fd-6473-4cd9-8a55-7a4d1ed083b2, hostname=127.0.0.1] [0x82dd50]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [address=TPRBOX, durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1, drain=false] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=e5584c39-5ae9-4fad-ba53-2528475d71ba] [0x82dd50]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @transfer(20) [handle=0, delivery-id=0, delivery-tag=b\x00\x00\x00\x00, message-format=0, settled=false, more=false] (255) \x00Sp\xc0\x06\x04BP\x04@A\x00Ss\xd0\x00\x00\x008\x00\x00\x00\x0d@ @\xa1\x15amqp:// 0.0.0.0/TPRBOX@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\xaf\x08\x00\x00\x00\x00\x00\x00\x00\x8c#\x00\x00\x00\x00\x00\x00
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
Hallo Rafael, Sorry, but this time I have to attach a file :-) (I was usually trying to avoid it because sending to mailing list) But qpidd trace is uncompressed 2Mb, compressed 80Kb So compressed qpidd log is attached. Best regards, 25.10.2014 00:41, Rafael Schloming пишет: Hi Michael, Sorry for misleading you. I think the way qpidd integrates proton must override the PN_TRACE_FRM configuration. I believe you should be able to get the protocol trace from the broker by using the -t option, e.g. qpidd -t. I'll take a look at the logs you posted, however I suspect the most useful one will be the broker trace, so I would appreciate any effort you can make to obtain it. Thanks, --Rafael On Fri, Oct 24, 2014 at 3:40 PM, Michael Ivanov iv...@logit-ag.de wrote: Ok I have some results. Now the core is not dumped but I have unusual delays during application startup. I have started qpidd up with PN_TRACE_FRM set, but do not see any trace output. Only thing I have are the following entries from syslog: Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initializing Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Security] notice SSL plugin not enabled, you must set --ssl-cert-db to enable it. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Journal TplStore: Created Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Store module initialized; store-dir=/var/spool/qpid Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] warning Message store plugin: No storage providers available. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Network] notice Listening on TCP/TCP6 port 5672 Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initialized Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 running Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39178 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39180 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [Management] error Detected two management objects with the same identifier: 0-5-1--174(org.apache.qpid.broker:incoming:aa8fef78-607a-4913-a9ba-f10972657cd7,sender-xxx) Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39182 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39184 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39186 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39188 No protocol received closing Oct 24 21:21:06 ccsfat qpidd[28477]: 2014-10-24 21:21:06 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39195 No protocol received closing With client processes it's a little better. Here's the output from one of the processes: [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :LOGIN, :PLAIN, :GSSAPI]] [0x82dd50]:0 - @sasl-outcome(68) [code=0] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=f58f77fd-6473-4cd9-8a55-7a4d1ed083b2, hostname=127.0.0.1] [0x82dd50]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [address=TPRBOX, durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1, drain=false] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=e5584c39-5ae9-4fad-ba53-2528475d71ba] [0x82dd50]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @transfer(20) [handle=0, delivery-id=0, delivery-tag=b\x00\x00\x00\x00, message-format=0, settled=false, more=false] (255) \x00Sp\xc0\x06\x04BP\x04@A\x00Ss\xd0\x00\x00\x008\x00\x00\x00\x0d@ @\xa1\x15amqp://
Re: VOTE: Release Proton 0.8 RC4 as 0.8 final
The mailing list scrubs attachments so it didn't get included. You can create an issue at https://issues.apache.org/jira/secure/CreateIssue.jspa?pid=12313720issuetype=1priority=3 and post the trace there. -Chuck - Original Message - From: Michael Ivanov iv...@logit-ag.de To: proton@qpid.apache.org Sent: Friday, October 24, 2014 5:02:43 PM Subject: Re: VOTE: Release Proton 0.8 RC4 as 0.8 final Hallo Rafael, Sorry, but this time I have to attach a file :-) (I was usually trying to avoid it because sending to mailing list) But qpidd trace is uncompressed 2Mb, compressed 80Kb So compressed qpidd log is attached. Best regards, 25.10.2014 00:41, Rafael Schloming пишет: Hi Michael, Sorry for misleading you. I think the way qpidd integrates proton must override the PN_TRACE_FRM configuration. I believe you should be able to get the protocol trace from the broker by using the -t option, e.g. qpidd -t. I'll take a look at the logs you posted, however I suspect the most useful one will be the broker trace, so I would appreciate any effort you can make to obtain it. Thanks, --Rafael On Fri, Oct 24, 2014 at 3:40 PM, Michael Ivanov iv...@logit-ag.de wrote: Ok I have some results. Now the core is not dumped but I have unusual delays during application startup. I have started qpidd up with PN_TRACE_FRM set, but do not see any trace output. Only thing I have are the following entries from syslog: Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initializing Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Security] notice SSL plugin not enabled, you must set --ssl-cert-db to enable it. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Journal TplStore: Created Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] notice Store module initialized; store-dir=/var/spool/qpid Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Store] warning Message store plugin: No storage providers available. Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Network] notice Listening on TCP/TCP6 port 5672 Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 initialized Oct 24 21:17:24 ccsfat qpidd[28477]: 2014-10-24 21:17:24 [Broker] notice Broker 28477 running Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39178 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39180 No protocol received closing Oct 24 21:21:04 ccsfat qpidd[28477]: 2014-10-24 21:21:04 [Management] error Detected two management objects with the same identifier: 0-5-1--174(org.apache.qpid.broker:incoming:aa8fef78-607a-4913-a9ba-f10972657cd7,sender-xxx) Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39182 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39184 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39186 No protocol received closing Oct 24 21:21:05 ccsfat qpidd[28477]: 2014-10-24 21:21:05 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39188 No protocol received closing Oct 24 21:21:06 ccsfat qpidd[28477]: 2014-10-24 21:21:06 [System] error Connection qpid.127.0.0.1:5672-127.0.0.1:39195 No protocol received closing With client processes it's a little better. Here's the output from one of the processes: [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b] [0x82dd50]: - SASL [0x82dd50]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :LOGIN, :PLAIN, :GSSAPI]] [0x82dd50]:0 - @sasl-outcome(68) [code=0] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=f58f77fd-6473-4cd9-8a55-7a4d1ed083b2, hostname=127.0.0.1] [0x82dd50]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x82dd50]:0 - @attach(18) [name=TPRBOX, handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=TPRBOX, durable=0, timeout=0, dynamic=false], target=@target(41) [address=TPRBOX, durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x82dd50]:0 - @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0, link-credit=1, drain=false] [0x82dd50]: - AMQP [0x82dd50]:0 - @open(16) [container-id=e5584c39-5ae9-4fad-ba53-2528475d71ba] [0x82dd50]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1] [0x82dd50]:0 -
[jira] [Resolved] (PROTON-728) transport aborts when delivery ids are out of sequence
[ https://issues.apache.org/jira/browse/PROTON-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-728. Resolution: Fixed transport aborts when delivery ids are out of sequence -- Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-728) transport aborts when delivery ids are out of sequence
[ https://issues.apache.org/jira/browse/PROTON-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-728: --- Fix Version/s: 0.8 transport aborts when delivery ids are out of sequence -- Key: PROTON-728 URL: https://issues.apache.org/jira/browse/PROTON-728 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming Fix For: 0.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
