On Jan 24, 2008 6:52 PM, Kevin k <[EMAIL PROTECTED]> wrote: > > Thanks again for your answer. > > I think I'm going to back up and you can let me know if I'm on the wrong > track or not. > > The scenario is I have a producer (http-consumer), that sends it's message > to a jms consumer which places the message on the queue. > > Then I have a jms producer (which is a servicemix endpoint) that reads the > message from the queue and forwards it on the to ultimate backend processor, > so my flow looks like this. (leaving out the jencks stuff). > > message ---> http consumer ---> jms consumer ---> jms queue <-- jms provider > ---> (final consumer) > |-------------------------- serivicemix endpoints > --------------------------------------------| > Everything is within one JVM (the servicemix jvm) > > Our main concern here is that since the final consumer is cpu/time intensive > we do not want it taking too many resources away from servicemix itself, so > we want to > a) make sure that service mix will not kick off too many of the jms > provider/final consumer tasks that will make the jvm/entire box too busy to > let service mix do what it should be doing
Well this is all a matter of configuration. Using the new endpoints for servicemix-jms allows much more configuration: http://servicemix.apache.org/servicemix-jms-new-endpoints.html These new endpoints use the message listener container from the Spring Framework which is highly configurable. Combined with the ability to configure the thread pools in ServiceMix (http://servicemix.apache.org/thread-pools.html), ServiceMIx and servicemix-jms endpoints can be highly tuned to determine the flow of messages. Furthermore, as you mention below, additional servicemix-jms endpoints can be deployed that each subscribe to the same queue and load balance across JMS consumers as James mentioned in his reply. > b) make sure we can start up other servicemix's (On other boxes that will > only have jms provider/final consumer endpoints on them and can take some of > the load off of the main service mix. > > we currently do not want to remove the jms provider/final endpoint > completely off of the main service mix, we just want to make sure it will > never overload the JVM. Well this is where the component flow above confuses me, so I can't quite respond yet. I don't quite understand what you're trying to do exactly. Maybe there's some detail left out or something but the flow above could be simplified to something like the following: external client --> http-consumer --> jms-provider <-- external jms consumer Are there additional details you're leaving out as to why the flow you showed above contains a JMS consumer between the http-consumer and the jms-provider? > We also do not want the final endpoint to be a direct jms client, we want it > to be a jbi component that waits for servicemix to call it. Again, I'm a bit confused here. Is the final client external to ServiceMix? If so, ServiceMix won't call it at all. Its an external JMS client's job to subscribe to a queue so that the underlying ActiveMQ broker will push messages to the client. Please clarify my questions so that I can elaborate further. Bruce -- perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' Apache ActiveMQ - http://activemq.org/ Apache Camel - http://activemq.org/camel/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Blog: http://bruceblog.org/
