I guess middleware vendors may have pull/push/buffering/all sorts of implementation specifics. JMS API shields camel from that specifics.
So I agree with the comment that putting together a simple yet production-like test would be a good idea. And with "production-like" i mean - Same JMS provider - Same/similar environment and messaging setup - Same/similar processing logic on client/camel side - Same/similar message size and structure - Same/similar load pattern - e.g. avg messages per second + load spikes. Then you can roughly measure how you solution performs and scales with different jms options / concurrency setup / number of nodes. Thanks, Pavel On Thu, Apr 7, 2011 at 6:21 PM, fridlyos <albert.friedl...@citi.com> wrote: > Hello.... > > I'm fairly new to Camel, and hoping I can get some insights into this... > > I'm need to design and system, which has as low latency as I can. I still > would like to leverage Camel, but not sure > > 1. How camel rout is initialized, that is - now frequently it's checking > for > messages? > 2. Using JMS - is this a poll, or the route is triggered immediately once > the message is posted on the initial JMS Queue (THIS IS THE MAIN CONCERN - > I > understand SEDA vs DIRECT further down the route). > > I guess, this is mainly related to JMS component. Also, this is not a > total > throughput issue, which can be addressed with different caching strategies. > > > Has anyone had to do something similar or researched similar issues? > > > I'd greatly appreciate any suggestions.... > > > Thanks.... > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Low-Latency-tp4288799p4288799.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
