So, suppose, if I provide a API for my users to access Qpid, and allow them to dequeue data and I send the data back over the network to them. Now unless, they acknowledge that they have processed the data, I may receieve thousand such requests (or more). I want to keep the data around, but would not be able to maintain the track of session object for each such dequeue request.
I dont want my users to worry about using qpid, so I give them very simple API abstracting the details of connection, connection factory and all this. I think this is not a very rare use-case, and I would like to know, if there is any work around for acknowledgment in such situations. Thanks, Vivek On Mon, Aug 16, 2010 at 9:08 PM, Rajith Attapattu <[email protected]>wrote: > On Mon, Aug 16, 2010 at 6:23 AM, vivek agarwal <[email protected]> > wrote: > > Hi, > > > > Do we have a API for direct AMQP over Apache Qpid, instead of going > through > > JMS? > > We have through experience found out that most use cases can be met > with pure JMS + configuration. > The new addressing syntax give the JMS user a lot of flexibility in > leveraging the AMQP features. > Another benefit is that you could easily switch to another AMQP > version or another vendor that supports JMS without having to change > code. > The C++ and Python clients have also started to support a high level > messaging API instead of something very close to the protocol. > It allows a developer to think more in high level messaging concepts > instead of worrying about every detail of the protocol. > > If you are unsure, please feel free to discuss your use cases and we > are happy to help you in figuring out the configuration etc. > > > Also, I wanted to enquire if its implements AMQP .10 fully. > > Yes, the Qpid JMS client implements the 0-10 version. > > > I have a very specific use-case, where a consumer may consume a message, > and > > acknowledge it after a long processing. So can it be done without keeping > > the Session object ( through which I received the message) open? > > You can use the client ack mode in JMS for this. > But whether you use JMS or an API closer to the protocol, you still > need to keep the session object open as the message delivery was done > within the context of that session. > May I know what your concern is in keeping the session object around? > > > Thanks, > > Vivek > > > > > > On Wed, Aug 11, 2010 at 8:21 PM, Gordon Sim <[email protected]> wrote: > > > >> On 08/11/2010 03:27 PM, Rajith Attapattu wrote: > >> > >>> On Wed, Aug 11, 2010 at 9:57 AM, vivek agarwal<[email protected] > > > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Thanks for the reply. > >>>> We are planning to use a Java broker as most of our applications are > in > >>>> Java. Will this affect performance? > >>>> > >>> > >>> As Gordon mentioned, please try both the Java and C++ broker and see > >>> what fits your needs. > >>> > >> > >> Actually I just said try out the Java broker (as that was your preferred > >> option) to confirm it meets your needs (I believe it will). > >> > >> Not that I'd want to put you off trying the c++ broker out as well of > >> course if you have the interest :-) > >> > >> > >> --------------------------------------------------------------------- > >> Apache Qpid - AMQP Messaging Implementation > >> Project: http://qpid.apache.org > >> Use/Interact: mailto:[email protected] > >> > >> > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
