Ashwin... So you are basically saying that in high-volume scenarios, Camel shouldn't use JBI components because there is a higher overhead associated with these requests? I'm seeing similar performance issues using Camel and am tempted to move all my JBI services into Camel components to eliminate as much overhead as possible.
If I do this, then why do I need SMX at all. Camel supports all the binding components (activemq, http, file, etc) that SMX does and seems to be add more flexibility with routing and exception handling. What is SMX providing otherwise? I'm starting to feel that Camel and SMX are competing technologies that happen to work together (using servicemix-camel binding). Can someone please elaborate on why I need SMX if Camel components seem to do everything... thanks in advance... Ashwin Karpe wrote: > > Hi, > > Based on your example, the following will happen in JBI. > > 1> Camel SA1 invoking the JBI service myService will cause the following > additional work to take place.It will cause the running thread in the > servicemix-camel component to create an In-only Message exchange, copy the > message from the processor to the exchange. The exchange will be sent to > the NMR to locate and forward to myService. > 2> Now myService though in another SA is also a servicemix-camel endpoint > registered with the NMR and will cause the exchange to be picked up by > another servicemix-camel thread and processed. The payload will be pulled > out of the JBI Message exchange and moved into a Camel Exchange that is > forwarded to the second processor. The JBI Message exchange is now set to > Done and pushed back and sent to the original thread for Camel-SA1 for > further processing and cleanup (due to JBI MEP processing rules). > 3> The exchnage cleanup has to be done by the servicemix container after > the servicemix-camel thread SA1 does nothing further with the exchange. > > The trouble you run into when it is all running in the same > servicemix-camel container is that the code becomes re-entrant, more and > more time is spent in exchange creation and management within > servicemix-camel, exchanges start to pile up pretty quickly, thereby > driving down the overall processing speed. Also, this activity chews up > threads pretty quickly in a high volume scenario. > > Note that this does not happen in the pure JMS situation. The > servicemix-camel component does not have to create any fresh JBI exchanges > and manage them since it has no NMR involved. The camel routing scenario > can entirely executed in a running thread that can grab a message from the > Broker managing the Topic, process and and send it to another Topic. > Another thread then picks up from the second Topic and processes the > message. There is no need to create and manage JBI exchanges. I guess the > difference is the difference between a routing and a bridging scenario. > Hence the much better performance. > > Hope this helps. The only thing that surprised me was how much the cost > differential was. You might try to increase the number of threads for the > Camel component via configuration (servicemix.properties in the conf > directory) and see if that makes a difference. I bet increasing the thread > pool will improve performance, however the performance of the pure-JMS > solution should improve as well :). > > Cheers, > > Ashwin... > > ----- Ben O'Day Vektrel - Senior Consultant -- View this message in context: http://www.nabble.com/JBI-performance-tp21615804p24629079.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
