Proton-C: How to set application properties?
Hi, I don't find a way to set the application properties of a message in Proton-C. Can someone give me a hint? Is there something like a user guide or getting started docs about Messenger? Thanks, Andreas -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: Proton-C: How to set application properties?
Am 09.01.2014 um 21:15 schrieb Rafael Schloming r...@alum.mit.edu: What we have is currently available here: http://qpid.apache.org/components/messenger/index.html It is probably a bit more developed for the python binding than for the C API itself. Certainly accessing/manipulating data is properly under-documented in C as all of that is done automatically in the python binding and so requires much less documentation. Let me know if there are particular parts you'd like to see filled out and I'll see about improving them. What would really helpful is a one-page user guide where you explain the Messenger API. I want to know e.g. how to use the different QoS exactly-once, at-most-once, at-least-once and all that stuff I can do with that API without jumping from one header file to another. Provide basic samples with snippets in the different supported language bindings. I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. This is how our client is documented: http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html That's it. Doesn't took much effort to create it. Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went frustrated away from it like one of our customers who is now using the Rabbit C 0.9.1 client with SwiftMQ. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: pn_messenger_send return code
I think the SASL error below might be caused by occasionally using an
unsupported SASL mechanism. I don't know where to set the mechanism in
Messenger. If you find how, set it to PLAIN or CRAM-MD5.
Andreas
Am 12.01.2014 um 04:34 schrieb serega sergejs.melde...@sap.com:
I didn't insert the line in the code as was suggested by Rafael
pn_messenger_set_outgoing_window(messenger, N);
With that change I get PN_STATUS_ABORTED = 6 when the link is broken.
I do have another problem though. I get the following errors sometimes..
./send -a amqp://guest:guest@127.0.0.1:5672/testqueue
[0x7fdf48700a10]:ERROR[-2] SASL header mismatch:
'\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00B\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@\xc0.\x01\xe0+\x05\xa3\x04NTLM\x05PLAIN\x09ANONYMOUS\x0aDIGEST-MD5\x08CRAM-MD5'
sergey:Debug sergey$ for i in {1..5000} ; do ./send -a
amqp://guest:guest@127.0.0.1:5672/testqueue; done
[0x7fb0c1406670]:ERROR[-2] SASL header mismatch:
'\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00B\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@\xc0.\x01\xe0+\x05\xa3\x0aDIGEST-MD5\x08CRAM-MD5\x04NTLM\x05PLAIN\x09ANONYMOUS'
The client simply hangs after reporting this error. I stepped in debugger
and found that the call doesn't return from pn_driver_wait().
--
View this message in context:
http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570p7602616.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
IIT Software GmbH
Fahrenheitstr. 13, D28359 Bremen, Germany
Tel: +49 421 330 46 088, Fax: +49 421 330 46 090
Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller
Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Disabling SASL should be an option in proton to connect to simple services that do not provide SASL or just to skip this additional step if SASL is not requires. The other problem was already reported from Sergey. I receive a SASL protocol header and a SASL Init message with mechanism PLAIN from proton. [ProtocolHeader, name=AMQP, id=3, major=1, minor=0, revision=0] [SaslInit mechanism=PLAIN, initialResponse=006775657374006775657374] Then occasionally this error is thrown: ./send -a amqp://guest:guest@127.0.0.1:5672/testqueue Test [0xbe1030:0] ERROR[-2] SASL header mismatch: '\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00=\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@\xc0)\x01\xe0\x04\xa3\x05PLAIN\x09ANONYMOUS\x0aDIGEST-MD5\x08CRAM-MD5' My first thought was that this might be caused by using an unsupported mechanisnm but this is not the case as PLAIN is used. I'm getting this with ANONYMOUS too. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.01.2014 um 15:24 schrieb Rafael Schloming r...@alum.mit.edu: Hi, Messenger will simply use anonymous if you don't specify a username and password, e.g. amqp://broker/node will result in the client forcing ANONYMOUS. If you do specify a username and password, e.g. amqp://user:pass@broker/node, then messenger will force PLAIN. There is no way to disable SASL entirely. If you're interested in stronger security than PLAIN offers, your best bet is probably to use SSL with client side certificates. --Rafael On Tue, Jan 14, 2014 at 9:05 AM, Andreas Mueller a...@iit.de wrote: Hi, I've looked through the proton-c Messenger API docs but can't find it. Can someone please tell me: 1) How to disable SASL at all to start direct with AMQP? 2) How to force a specific SASL mechanism like PLAIN? Thanks, Andreas -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912 IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Am 14.01.2014 um 16:00 schrieb Rafael Schloming r...@alum.mit.edu: The SASL header looks to start where you see the sequence ...AMQP\x03\x01 This either means that proton's internal buffers are getting messed up somehow, or there actually is garbage on the wire. Just checked with iAmqpDecode. It seems the SASL outcome message outruns the protocol header! ;-) That's a bug on my side! Threading issue ... -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Yes, very soon. Andreas Am 14.01.2014 um 18:34 schrieb serega sergejs.melde...@sap.com: Andreas, are you planning to fix the bug in the future version? Thanks, Sergejs. -- View this message in context: http://qpid.2158936.n2.nabble.com/SASL-proton-c-questions-tp7602690p7602711.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Andreas, are you planning to fix the bug in the future version? It is fixed now: http://www.swiftmq.com/products/releasenotes/v942/index.html -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
[jira] [Created] (PROTON-484) Disposition Frane: Missing DeliveryState, no default outcome
Andreas Mueller created PROTON-484: -- Summary: Disposition Frane: Missing DeliveryState, no default outcome Key: PROTON-484 URL: https://issues.apache.org/jira/browse/PROTON-484 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Andreas Mueller If a message is delivered from a broker to Proton-C by a transfer frame with settled=false, Proton sends a disposition frame with settled=true but without a delivery state. A delivery state is required because a message can be e.g. accepted or rejected through a disposition frame. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (PROTON-484) Disposition Frane: Missing DeliveryState, no default outcome
[ https://issues.apache.org/jira/browse/PROTON-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13867634#comment-13867634 ] Andreas Mueller commented on PROTON-484: This is what you send when attaching a receiver (no default outcome set in the source): [Attach name=receiver-xxx, handle=0, role=TRUE, sndSettleMode=2, rcvSettleMode=0, source=[Source address=testqueue, durable=0, expiryPolicy=session-end, timeout=0, dynamic=FALSE], target=[Target address=testqueue, durable=0, expiryPolicy=session-end, timeout=0, dynamic=FALSE], incompleteUnsettled=FALSE, initialDeliveryCount=0] This is what SwiftMQ sends you back (announcing released as default outcome for the source): [Attach name=receiver-xxx, handle=0, role=FALSE, sndSettleMode=2, rcvSettleMode=0, source=[Source address=testqueue, durable=1, expiryPolicy=link-detach, timeout=0, dynamic=FALSE, defaultOutcome=[Released ], outcomes=[amqp:accepted:list, amqp:rejected:list, amqp:released:list, amqp:modified:list]], target=[Target address=testqueue, durable=0, expiryPolicy=session-end, timeout=0, dynamic=FALSE], incompleteUnsettled=FALSE, initialDeliveryCount=0] According to your interpretation of the spec, released will be applied if you send a dispo frame without an outcome. This is what SwiftMQ does and this caused a continuous redelivery of the very same message. Keep in mind that the default outcome will be applied to all unsettled transfers in case the connection drops. If you would set it to accepted this may cause message losts. That's why SwiftMQ's default outcome is always released to cause rollback and redelivery. So the correct way for me seems to be to include the delivery state in the dispo frame. I would apply a workaround too but can't just set accepted if the delivery state is missed in the dispo frame. I have to use the default outcome. Disposition Frane: Missing DeliveryState, no default outcome Key: PROTON-484 URL: https://issues.apache.org/jira/browse/PROTON-484 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Andreas Mueller If a message is delivered from a broker to Proton-C by a transfer frame with settled=false, Proton sends a disposition frame with settled=true but without a delivery state. A delivery state is required because a message can be e.g. accepted or rejected through a disposition frame. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (PROTON-486) Create a User's Guide
Andreas Mueller created PROTON-486: -- Summary: Create a User's Guide Key: PROTON-486 URL: https://issues.apache.org/jira/browse/PROTON-486 Project: Qpid Proton Issue Type: Improvement Reporter: Andreas Mueller Priority: Critical What would really helpful is a one-page user guide where you explain the Messenger API. I want to know e.g. how to use the different QoS exactly-once, at-most-once, at-least-once and all that stuff I can do with that API without jumping from one header file to another and need to ask questions in mailing lists. Provide basic samples with snippets in the different supported language bindings. I think Messenger API is quite comparable with SwiftMQ's AMQP 1.0 Client. This is how our client is documented: http://www.swiftmq.com/products/router/swiftlets/sys_amqp/client/index.html That's it. Doesn't took much effort to create it. Proton is *the* standard AMQP 1.0 driver. It would be a shame if users went frustrated away from it because they don't understand the basic concepts. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
