Re: Error detection/handling
Hi Gordon,
thanks a lot for help. Condition gives exactly what I needs.
Here is an output from the broker when trace+ is enabled on protocol level.
Scenario:
send 1 message with incorrect subject and afterwards send 3 messages with
correct subject.
3 messages will get delivered to the queue.
-
2015-09-17 09:28:14 [Network] info Set TCP_NODELAY on connection to
172.16.81.5:61576
2015-09-17 09:28:14 [Broker] info Using AMQP 1.0 (with SASL layer)
2015-09-17 09:28:14 [Security] info SASL: Mechanism list: PLAIN DIGEST-MD5
CRAM-MD5
2015-09-17 09:28:14 [Protocol] debug
qpid.172.16.153.10:2-172.16.81.5:61576 Sent SASL-MECHANISMS(PLAIN
DIGEST-MD5 CRAM-MD5) 50
2015-09-17 09:28:14 [Protocol] debug
qpid.172.16.153.10:2-172.16.81.5:61576 writing protocol header: 1-0
2015-09-17 09:28:14 [Protocol] debug
qpid.172.16.153.10:2-172.16.81.5:61576 Received SASL-INIT(PLAIN,
amqpsrv\x00amqpsrv\x00amqpsrv)
2015-09-17 09:28:14 [Security] info SASL: Starting authentication with
mechanism: PLAIN
2015-09-17 09:28:14 [Protocol] debug
qpid.172.16.153.10:2-172.16.81.5:61576 Sent SASL-OUTCOME(0) 16
2015-09-17 09:28:14 [Security] info
qpid.172.16.153.10:2-172.16.81.5:61576 Authenticated as amqpsrv@QPID
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: -> AMQP
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: <- AMQP
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 <- @open(16)
[container-id="reactor", hostname="172.16.153.10:2",
max-frame-size=512, channel-max=32767, idle-time-out=500]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 <- @begin(17)
[next-outgoing-id=0, incoming-window=2048, outgoing-window=2147483647]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 <- @attach(18)
[name="broadcast", handle=0, role=false, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40) [address="broadcast", durable=0,
timeout=0, dynamic=false], target=@target(41) [address="broadcast",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
2015-09-17 09:28:14 [Protocol] debug
qpid.172.16.153.10:2-172.16.81.5:61576 link 0x2636830 attached on
0x26998b0
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 -> @open(16)
[container-id="a11b7eb6-efbb-4883-915d-bbe792589e51", idle-time-out=500,
properties={:product="qpid-cpp", :version="0.34", :platform="Linux", :host="
cbgd03.xeop.de"}]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 -> @begin(17)
[remote-channel=0, next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 -> @attach(18)
[name="broadcast", handle=0, role=true, snd-settle-mode=2,
rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="broadcast", durable=0,
timeout=0, dynamic=false], initial-delivery-count=0]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 -> @flow(19)
[next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=0,
outgoing-window=0, handle=0, delivery-count=0, link-credit=500, drain=false]
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 -> (EMPTY FRAME)
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 <- (EMPTY FRAME)
2015-09-17 09:28:14 [Protocol] trace
[qpid.172.16.153.10:2-172.16.81.5:61576]: 0 <- @transfer(20) [handle=0,
delivery-id=0, delivery-tag=b"\x01\x00\x00\x00\x00\x00\x00\x00",
message-format=0, settled=true, more=false] (353)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR
\x00\x00Ss\xd0\x00\x00\x00B\x00\x00\x00\x0d@
@\xa1\x09broadcast\xa1\x14ppp-broadcast.Public@S\x01@
@\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x01O\xda4$\xde@R\x00@\x00Sw\xa0\xffHello
1\x00\x10\x00\x00\x00\x80k\xa3z\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xe8V\x85z\x01\x00\x00\x00\x00\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00$\x00\x00\x00\x00\x00\x00\x0e\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfd\x07\x00\x00\xf0V\x85z\x00\x00\x00\x00\x90\xdf\x0f\x00\xff\xff\xff\xff!\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x98W\x85z\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xa0W\x85z\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x86E\x00\x00\x00\x00\x00\x00\x1a\x00\x00\x00\x00\x00\x00\x00>\x00\x01\x00\x00\x00\x00\x005\x00\x00\x00\x00\x00\x00\x00>\x00\x01\x00\x00\x00\x00\x00\x09\x82
\x08\x82 \x08\x82"... (truncated)
2015-09-17 09:28:14 [Protocol] trace
Re: [jira] [Commented] (PROTON-992) Proton's use of Cyrus SASL is not thread-safe.
Thanks! I wondered about that (briefly) but thought there was nothing to be done. If you have a sketch, I would be happy to see it! - Original Message - [ https://issues.apache.org/jira/browse/PROTON-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802937#comment-14802937 ] Andrew Stitcher commented on PROTON-992: Upon a few days reflection I've realised that you cannot fix this problem with a global init for proton: This is because there are a couple of parameters of the Cyrus library that *must* be set before calling either sasl_server_init() or sasl_client_init(). These are the configuration file directory and the server name. Currently if you want to customise these you must set them before the first usage of SASL and this works as SASL is initialised lazily. However in the proposed API there is literally no place to set them: Since the usage pattern has to be documented that you must initialise the library before using it the Cyrus Sasl ibrary will be initialised before you are allowed to use the APIs that set the path or name. So I think the only workable solution is to have an atomic count of use of the library and initialise on the going from 0->1 then finalise on going from 1->0. Obviously also keeping track of how many uses the library has as well so that we can finalise in the correct place. An important point here is to make the count atomic so that we can be sure to avoid any re-entrance into the initialisation or finalisation code (this is doable using gcc/clang builtins - we don't really support Cyrus on Win32 so Visual Studio isn't too important, but it has atomic primitives too) I would note that really we should alos be using atomic counts like this in the OpenSSL code too,. > Proton's use of Cyrus SASL is not thread-safe. > -- > > Key: PROTON-992 > URL: https://issues.apache.org/jira/browse/PROTON-992 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: michael goulish >Assignee: michael goulish >Priority: Critical > > Documentation for the Cyrus SASL library says that the library is believed to > be thread-safe only if the code that uses it meets several requirements. > The requirements are: > * you supply mutex functions (see sasl_set_mutex()) > * you make no libsasl calls until sasl_client/server_init() completes > * no libsasl calls are made after sasl_done() is begun > * when using GSSAPI, you use a thread-safe GSS / Kerberos 5 library. > It says explicitly that that sasl_set* calls are not thread safe, since they > set global state. > The proton library makes calls to sasl_set* functions in : > pni_init_client() > pni_init_server(), and > pni_process_init() > Since those are internal functions, there is no way for code that uses Proton > to lock around those calls. > I think proton needs a new API call to let applications call > sasl_set_mutex(). Or something. > We probably also need other protections to meet the other requirements > specified in the Cyrus documentation (and quoted above). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Error detection/handling
On 09/17/2015 08:37 AM, Tomáš Šoltys wrote: Here is an output from the broker when trace+ is enabled on protocol level. Thanks! This looks like the same root cause as https://issues.apache.org/jira/browse/QPID-6660, which is now fixed on trunk (but didn't make it into the 0.34 release) Scenario: send 1 message with incorrect subject and afterwards send 3 messages with correct subject. 3 messages will get delivered to the queue. I've confirmed that on trunk, the messages after the one barred by acl do *not* get enqueued.
[jira] [Commented] (PROTON-992) Proton's use of Cyrus SASL is not thread-safe.
[ https://issues.apache.org/jira/browse/PROTON-992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14802937#comment-14802937 ] Andrew Stitcher commented on PROTON-992: Upon a few days reflection I've realised that you cannot fix this problem with a global init for proton: This is because there are a couple of parameters of the Cyrus library that *must* be set before calling either sasl_server_init() or sasl_client_init(). These are the configuration file directory and the server name. Currently if you want to customise these you must set them before the first usage of SASL and this works as SASL is initialised lazily. However in the proposed API there is literally no place to set them: Since the usage pattern has to be documented that you must initialise the library before using it the Cyrus Sasl ibrary will be initialised before you are allowed to use the APIs that set the path or name. So I think the only workable solution is to have an atomic count of use of the library and initialise on the going from 0->1 then finalise on going from 1->0. Obviously also keeping track of how many uses the library has as well so that we can finalise in the correct place. An important point here is to make the count atomic so that we can be sure to avoid any re-entrance into the initialisation or finalisation code (this is doable using gcc/clang builtins - we don't really support Cyrus on Win32 so Visual Studio isn't too important, but it has atomic primitives too) I would note that really we should alos be using atomic counts like this in the OpenSSL code too,. > Proton's use of Cyrus SASL is not thread-safe. > -- > > Key: PROTON-992 > URL: https://issues.apache.org/jira/browse/PROTON-992 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: michael goulish >Assignee: michael goulish >Priority: Critical > > Documentation for the Cyrus SASL library says that the library is believed to > be thread-safe only if the code that uses it meets several requirements. > The requirements are: > * you supply mutex functions (see sasl_set_mutex()) > * you make no libsasl calls until sasl_client/server_init() completes > * no libsasl calls are made after sasl_done() is begun > * when using GSSAPI, you use a thread-safe GSS / Kerberos 5 library. > It says explicitly that that sasl_set* calls are not thread safe, since they > set global state. > The proton library makes calls to sasl_set* functions in : > pni_init_client() > pni_init_server(), and > pni_process_init() > Since those are internal functions, there is no way for code that uses Proton > to lock around those calls. > I think proton needs a new API call to let applications call > sasl_set_mutex(). Or something. > We probably also need other protections to meet the other requirements > specified in the Cyrus documentation (and quoted above). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-999) Docs: pn_messenger_subscribe(): "source" is undocumented
[ https://issues.apache.org/jira/browse/PROTON-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Leggett updated PROTON-999: -- Description: The pn_messenger_subscribe() function is documented to take a const char * as a "source": https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6 The definition of a "source" isn't specified, nor is the acceptable source format specified. In addition, it isn't specified in the docs whether this function must be called once, or whether it can be called multiple times. Reverse engineering the source seems to indicate that it should be called just once, and if you call it multiple times the underlying event loop will be corrupted. was: The pn_messenger_subscribe() function is documented to take a const char * as a "source": https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6 The definition of a "source" isn't specified, nor is the acceptable source format specified. > Docs: pn_messenger_subscribe(): "source" is undocumented > > > Key: PROTON-999 > URL: https://issues.apache.org/jira/browse/PROTON-999 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Graham Leggett > Labels: documentation > > The pn_messenger_subscribe() function is documented to take a const char * as > a "source": > https://qpid.apache.org/releases/qpid-proton-0.10/proton/c/api/group__messenger.html#gaf1f1bfe4894d971f0b8d679bcab5cae6 > The definition of a "source" isn't specified, nor is the acceptable source > format specified. > In addition, it isn't specified in the docs whether this function must be > called once, or whether it can be called multiple times. Reverse engineering > the source seems to indicate that it should be called just once, and if you > call it multiple times the underlying event loop will be corrupted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-996) Allow Messenger API to set the allowed auth mechs
[ https://issues.apache.org/jira/browse/PROTON-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-996: -- Assignee: Andrew Stitcher > Allow Messenger API to set the allowed auth mechs > - > > Key: PROTON-996 > URL: https://issues.apache.org/jira/browse/PROTON-996 > Project: Qpid Proton > Issue Type: New Feature > Components: python-binding >Affects Versions: 0.10 >Reporter: Javier Ruere >Assignee: Andrew Stitcher >Priority: Minor > > If the allowed authentication mechanisms have to be explicitly set, the > Messenger API is unusable. Can this be fixed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
