[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)
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
[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=13867694#comment-13867694 ] Rafael H. Schloming commented on PROTON-484: Ah, I understand now, thanks for explaining! An immediate workaround for current and previous releases would be as follows on the receiver: set the incoming window to a positive number and explicitly call accept/reject for each incoming message, e.g.: pn_messenger_set_incoming_window(messenger, N); // any number greater than 0 will work depending on how many messages you would like to be able to process at once // ... pn_messenger_get(messenger, msg1); // ... pn_messenger_get(messenger, msg2); // retrieve up to N messages // process the messages pn_tracker_t tracker = pn_messenger_incoming_tracker(messenger); // grab the tracker for the most recent incoming message pn_messenger_accept(messenger, tracker, PN_CUMULATIVE); // accept all incoming messages // you could also do a pn_messenger_reject(...) here or reject individual messages and accept the rest, etc. The above usage pattern will ensure that messenger always puts an explicit accept or reject in the disposition frame. For the next release I will make sure that messenger sets up the default outcome properly so that the default behaviour is more intuitive. 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] [Closed] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[ https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-426. - Resolution: Duplicate [Messenger] messenger has no ability to dynamically create queues/topics on qpidd - Key: PROTON-426 URL: https://issues.apache.org/jira/browse/PROTON-426 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Fix For: 0.6 The current QPID client addressing syntax provides a way to create and delete queue/topic resource on the qpidd broker in band. For example: $ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options {protocol:amqp1.0} TestQ;{create:always,node:{type:queue}} $ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ... TestQ1 1 0 65 650 0 1 This capability is not available when using the Messenger API. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
pn_messenger_send return code
Hello. I am evaluating Qpid Proton AMQP Messenger to communicate with SwiftMQ broker. I've had issues with receiving messages, but I used suggestion here https://issues.apache.org/jira/browse/PROTON-484 and it solved the problem. The use case I am testing is broker is down. Modified send.c code: int res = pn_messenger_put(messenger, message); printf(Error %d\n, res); check(messenger); res = pn_messenger_send(messenger, -1); printf(Error %d\n, res); check(messenger); The output: __ Error 0 read: Connection refused [0x101009c00:0] ERROR[-2] SASL header mismatch: '' send: Broken pipe CONNECTION ERROR connection aborted Error 0 __ Shouldn't there be a non zero error code as documented in messenger.h ? * @return an error code or zero on success * @see error.h */ PN_EXTERN int pn_messenger_send(pn_messenger_t *messenger, int n); Thanks, Sergey. -- View this message in context: http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: pn_messenger_send return code
Hi, Welcome to the list. The put and send return codes are used for more basic errors, e.g. coding errors. Tracking the status of outgoing messages has it's own API similar to the one you've already used in your receiver. Below is a rough example. I've omitted the return code checking for brevity: pn_messenger_set_outgoing_window(messenger, N); // track the status of the last N outgoing messages pn_messenger_put(messenger, m1); pn_tracker_t t1 = pn_messenger_outgoing_tracker(messenger); // Grab the tracker for the last outgoing message (in this case m1) pn_messenger_put(messenger, m2); pn_tracker_t t2 = pn_messenger_outgoing_tracker(messenger); // Grab the tracker for the last outgoing message (in this case m2) // ... // ... if you put more than N messages without calling send, messenger won't keep the status for the older trackers // ... pn_messenger_send(messenger, -1); // now check the status for whatever messages I care about: printf(Status off M1: %d\n, pn_messenger_status(messenger, t1)); // ... Hopefully this will get you going, but please follow up if you have anymore questions. --Rafael On Fri, Jan 10, 2014 at 2:34 PM, serega sergejs.melde...@sap.com wrote: Hello. I am evaluating Qpid Proton AMQP Messenger to communicate with SwiftMQ broker. I've had issues with receiving messages, but I used suggestion here https://issues.apache.org/jira/browse/PROTON-484 and it solved the problem. The use case I am testing is broker is down. Modified send.c code: int res = pn_messenger_put(messenger, message); printf(Error %d\n, res); check(messenger); res = pn_messenger_send(messenger, -1); printf(Error %d\n, res); check(messenger); The output: __ Error 0 read: Connection refused [0x101009c00:0] ERROR[-2] SASL header mismatch: '' send: Broken pipe CONNECTION ERROR connection aborted Error 0 __ Shouldn't there be a non zero error code as documented in messenger.h ? * @return an error code or zero on success * @see error.h */ PN_EXTERN int pn_messenger_send(pn_messenger_t *messenger, int n); Thanks, Sergey. -- View this message in context: http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: pn_messenger_send return code
Thanks for your reply. I added the tracker, but with the same scenario it returns 0 which is PN_STATUS_UNKNOWN = 0. - Error 0 read: Connection refused [0x100810800:0] ERROR[-2] SASL header mismatch: '' send: Broken pipe CONNECTION ERROR connection aborted Error 0 Status off M1: 0 --- It looks like internally messenger prints error messages, but it doesn't communicate with the client about the error. The unknown status isn't very meaningful. Sergey. -- View this message in context: http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570p7602587.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.