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
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.
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.
Am I totally off base with either the requirements or the solution I have
laid out here.
Thanks again for you help and I hope these questions are not too dumb.
-Kevin
--
View this message in context:
http://www.nabble.com/jms-limiting-tp15070635s12049p15079530.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
