On Fri, May 9, 2008 at 8:22 AM, Robert Greig <[EMAIL PROTECTED]> wrote:
> 2008/5/9 Rajith Attapattu <[EMAIL PROTECTED]>: > > > 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. > > This is true just now but it does not imply that you need an "AMQP > API" to do that since it does not conflict with a JMS API. You could > easily add this capability to our "extended JMS API" and that is > definitely what I would like to see if users want it. I have no strong preference either way. However I prefer Rafi's method of using Pure JMS as much as possible as opposed to an extended JMS API. > > > 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 > > Again, since this doesn't conflict with JMS it could be added to our 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. > > I think it would be interesting to see if we could add this into the > JMS API. I need to understand the flow control in 0-10 a bit more > before I could really comment however. > > > 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. > > I think whatever the API that is provided, whether it is AMQP based or > not, the above will be tricky particularly plugging in your own IO > model unless that was designed into the API implementation. Rafi has made the IO model pluggable. The AMQP layer in 0-10 code path doesn't have any dependencies on MINA byte buffers etc. So if one wants to write an alternate IO layer then there is a clear mechanism to do that. > > > RG > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
