qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Greig" <robert.j.gr...@gmail.com>
Subject Re: General question regarding Java QPID
Date Fri, 09 May 2008 12:22:01 GMT
2008/5/9 Rajith Attapattu <rajith77@gmail.com>:

> 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.

> 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

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.


View raw message