Thanks for this Shabaz: I don’t seem to have the amqpexample subdirectory. I might have done something wrong when I uncompressed the source. I'll look around and see if I can locate it. Thanks again.
Kamran Saadatjoo Open Flow Systems, Inc. 404-247-0454 (Cell) -----Original Message----- From: Shahbaz Chaudhary [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2008 10:11 AM To: [email protected] Subject: RE: General question regarding Java QPID Kamran, I believe JMS examples have their non-jms counterparts in the following directory: qpid/java/client/example/src/main/java/org/apache/qpid/example/amqpexamp le Shahbaz Chaudhary -----Original Message----- From: Kamran Saadatjoo [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2008 8:00 AM To: [email protected] Subject: RE: General question regarding Java QPID For me, a couple of non-JMS AMQP examples would really be nice to have. I can map the C++ version to the AMQP documentation, but cannot do the same here. I'm sure a lot of my difficulties stem from my own inexperience, but if anyone can direct me to some non-JMS AMQP examples, I would be grateful. Kamran Saadatjoo -----Original Message----- From: Rajith Attapattu [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 10:13 PM To: [email protected] Subject: Re: General question regarding Java QPID On Thu, May 8, 2008 at 2:25 PM, Robert Greig <[EMAIL PROTECTED]> wrote: > 2008/5/8 Shahbaz Chaudhary <[EMAIL PROTECTED]>: > > I am interested in a non-jms api, frankly, for some silly reasons. > > Well, I don't think your reasons are silly. I have heard these things > several times, so let me give you my perspective. I second that, we have heard this from several folks. > > > > have never gotten used to Java's (J2EE's actually) InitialContext, JNDI, > > various configuration files, etc. > > The initial context is one bit that does tend to change from vendor to > vendor so I agree it can be awkward. However I would argue that Qpid's > implementation makes this as simple to use as possible - you basically > need one properties file into which you can put the configuration. Or > alternatively, of course, you do not need to use JNDI at all - you can > construct AMQConnection objects. > > I would recommend the Qpid properties file configuration personally, > since you inevitably want to put the configuration somewhere outside > of your code. > > With Qpid you do not need any external JNDI server (unless you choose > to use one of course). As Rob mentioned the Qpid properties file is a nice way to get the JNDI without having to mess up with external JNDI servers or any JEE nonsence. Some of the recent additions I did makes it possible to configure destinations with any exchange/routing key pair. I am planning to add more documentation on this aspect. > > > I also expect that the AMQP library to be faster and possibly better > > typed--so I don't deal with generic onMessage(Message) or > > onMessage(Object), etc. functions ('generic' being used here as normal > > English, not as Java's Generics) > > I don't think that an AMQP library would be faster in most cases. The > way it is implemented, JMS does not add much overhead on the client. > There are of course certain cases where it could be faster I grant you > but I'd have to think a bit about that. Maybe others can jump in if > they see any specific scenarios? For most cases JMS should be fast and good enough. The JMS consumer side will have one extra thread for dispatching which you can avoid if you write your own stuff using the AMQP API. But frankly the JMS implementation does take care of most of the grunt work for you, so you could work at a fairly abstract level. So unless you have a very compelling reason, it's good to use the JMS API. Some of the reasons for using the AMQP API directly would be, =============================================== You want to dynamically create/delete exchanges/queues/bindings as part of the application logic. The JMS API works well if you pre create your exchange/queues/bindings using the JNDI properties file. If your application needs to query for different exchanges, bindings, queues etc as part of your application logic then you would need to use the AMQP API If you want to have very fine grain flow controlling. The JMS impl deals with only message units and use window mode (however we should make the byte units configurable). If your application needs to switch between the different flow control modes and/or change byte/message credits dynamically as part of application logic then using the AMQP API makes sense. If you want fairly low level functionality. Ex If you want to write an intermediary that only looks at certain message properties or delivery properties or if you want to write some sort of intermediary that transforms messages, then it would be a lot more efficient to use the low level API. If your application is extreamly sensitive to latencies etc then you may wanna use the low level API to have a very tightly coupled implementation with your application where you can try to optimize it heavily for your use. Another reason would be if you are running on a Realtime java JVM you can use the low level API and build your functionality using Realtime constructs such as RealTimeThreads, NoHeapRealTimeThreads and using the fancy memory model for appropriately partitioning your object in importal and scope memory. You can also write your own IO model using real time constructs as it is pluggable in the current code. > > In terms of the typing, how would you like the API to look? We could > possibly integrate any good ideas you have into our extended JMS API. > > > I am a single developer here who needs to quickly set up the broker and > > start publishing/subscribing to data. All my development is new. I > > need to deal with financial data, which means as low latency as > > possible. > > I work for a tier one investment bank, in the front office - if you > want, you can search for me on linkedin.com to see what I do. So high > throughput and low latency are key requirements for me as well. > > It should be possible to get qpid running very quickly indeed - > literally unzip the broker and it should work out of the box without > any special configuration. People have been doing some work on our > docs recently (it is something getting a lot of attention) so do let > us know if anything is unclear or does not work as expected. > > Robert > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.13/1375 - Release Date: 4/12/2008 11:32 AM
