Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Hi Gordon, - Original Message - From: Gordon Sim g...@redhat.com To: us...@qpid.apache.org Cc: proton@qpid.apache.org Sent: Monday, May 19, 2014 11:25:41 AM Subject: Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing) On 05/15/2014 01:44 PM, Ken Giusti wrote: I think we should develop Messenger as an alternative client API to qpid::messaging, focusing on use cases that are not necessarily well covered by the existing qpid::messaging API. I think they complement each other nicely. In what way do you think they complement each other? I think you've touched on it below - they do differ primarily in style. But I think it goes beyond that. I think of qpid::messaging as being a traditional client api. It fits best in those scenarios where the application directly manages the connections (setup and fail-over), message sending/receiving, and credit. I suspect there's a lot of existing messaging systems that expect that kind of API, and will find qpid::messaging a better fit than Messenger. Messenger, as an alternative, provides (or at least promises to provide) solutions to a lot of the issues a traditional API has left to the application implementation. Things like connection failover, message retries, credit scheduling, routing, and even client-side store are provided by Messenger. Such features would probably feel cumbersome to someone looking for a JMS-like API (and IMHO may be better off with qpid::messaging), but for those folks who may not be bound to a legacy application, Messenger offers some useful features. [...] I think we'd be much better off if we can separate the problem spaces these two client APIs attempt to address, and clearly communicate these differences so that users can find the right API for their particular use cases That sounds neat and tidy in theory. I suspect it is not so simple in practice. (example: connection oriented vs message oriented). I view that as more a question of 'style' than problem space. (I suspect it also raises almost as many questions as it answers). The existence of alternatives is not itself inherently problematic. What matters is how confident a prospective adopter feels when evaluating options for AMQP and how easily he or she would succeed if AMQP were embraced. It's not a question of eliminating choices, its a question of improving the experience. [...] I think we should take an active role in promoting this new experimental, community-led APIs that you mentioned. To be clear, I'm not advocating that we (QPID) _support_ them, but I think we should add links to them directly from our QPID web site, along side the links to Messenger and qpid::messaging. I'm not sure what taking 'an active role in promoting' would mean, but I confess it makes me nervous. For one thing the projects I linked to vary widely in license, governance and maturity. On reflection and re-reading, my post was rather rushed and confused and the list of links was perhaps a mistake. The central point I am trying to make, is that though there are a variety of different *individual* initiatives, selecting an AMQP 1.0 client one can have confidence in is still not easy and it seems to me there is no real *collective* initiative to improve this. Sadly, I have to agree. How do we (qpid) go about solving this? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- -K
Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
On 05/21/2014 02:10 PM, Ken Giusti wrote: I think of qpid::messaging as being a traditional client api. [...] Messenger, as an alternative, provides (or at least promises to provide) solutions to a lot of the issues a traditional API has left to the application implementation. Things like connection failover, message retries, Automatic failover and message retry *is* supported in qpid::messaging (it isn't yet in Messenger). credit scheduling, What is that exactly? Messenger::recv(N) essentially distributes N credits across however many incoming links there are, right? Whereas qpid::messaging allows capacity to be set per subscriber and maintains the window of credits accordingly. So is the key difference here that in one API the credit is controlled per-subscription whereas in the other it is controlled in aggregate. Where the number of receivers is larger than the number of messages the application is prepared to accept, dealing with the credit in aggregate and having it automatically (re)distributed as needed may indeed be useful. Of course the same feature could easily be built as a utility on top of something like qpid::messaging. routing, So by this we mean the fact that Messenger looks at the address 'to' field of the message, applies some optional rules to that, and then find or creates the link to send it over. This could of course also be built on top of qpid::messaging (or indeed JMS). and even client-side store are provided by Messenger. When you say 'are provided' you mean 'might be provided in the future'? Such features would probably feel cumbersome I don't think it is the 'features' that are cumbersome, it's the restrictions. to someone looking for a JMS-like API (and IMHO may be better off with qpid::messaging), but for those folks who may not be bound to a legacy application, Messenger offers some useful features. I've heard this sentiment in different ways quite a lot. I.e. qpid::messaging and JMS are 'legacy' approaches, are for people who aren't free to choose etc, whereas Messenger represents the future, the ideal if nothing holds you back etc. I don't go along with that view personally; I see nothing that really justifies it. It also seems to me to be quite counter to the notion that the APIs 'complement' each other, at least in my understanding of what that means[1]. I'm certainly not arguing that qpid::messaging is the ideal API either, or that there is only room for one API. I'm keen to see if we can improve the general situation and feel that some debate around the different visions that exist within the community would be helpful in enabling better collaboration on that goal. --Gordon. [1] complement, verb, /ˈkɒm.plɪ.ment/: to make something else seem better or more attractive when combining with it (from http://dictionary.cambridge.org)
[jira] [Resolved] (PROTON-436) pn_data_dump is broken for complex types
[ https://issues.apache.org/jira/browse/PROTON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-436. Resolution: Fixed Fix Version/s: 0.8 Assignee: Rafael H. Schloming pn_data_dump is broken for complex types Key: PROTON-436 URL: https://issues.apache.org/jira/browse/PROTON-436 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 0001-PROTON-436-pni_inspect_atom-can-do-better-than-asser.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-436) pn_data_dump is broken for complex types
[ https://issues.apache.org/jira/browse/PROTON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14004965#comment-14004965 ] Fraser Adams commented on PROTON-436: - Aha - glad I spotted this Jiira, so I'm not going mad then :-) I was trying this out last weekend and wondering was it me or was this how it was supposed to work. pn_data_dump is broken for complex types Key: PROTON-436 URL: https://issues.apache.org/jira/browse/PROTON-436 Project: Qpid Proton Issue Type: Bug Reporter: Bozo Dragojevic Assignee: Rafael H. Schloming Fix For: 0.8 Attachments: 0001-PROTON-436-pni_inspect_atom-can-do-better-than-asser.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-584) Proton-c transport reserves large buffers for brief use
Cliff Jansen created PROTON-584: --- Summary: Proton-c transport reserves large buffers for brief use Key: PROTON-584 URL: https://issues.apache.org/jira/browse/PROTON-584 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.8 Reporter: Cliff Jansen When processing transfer frames for incoming messages, Proton requires a temporary buffer holding the whole transfer frame briefly in contiguous space in the transport before moving it to the engine proper which holds the content in a separate memory area. pn_transport_capacity grows the buffer in the non-ssl case (transport-input_buf), and openssl.c largely duplicates the code (including the comment about no limit) for ssl-inbuf for ssl connections. Either way, a large message will trigger reserving a similarly large buffer for the rest of the life of the connection. Is it necessary for the transport to buffer the whole message body and hang on to that memory? -- This message was sent by Atlassian JIRA (v6.2#6252)
