2009/1/2 bwtaylor <bryan_w_tay...@yahoo.com>: > > Since I posted this message, we haven't had a recurrence, though we haven't > done much yet and are probably just lucky. > > I'm pondering moving all of our camel routes out of the embedded broker > configuration we have now to a separate JVM. If we do this, and we configure > the brokerURL as you suggest: > brokerURL="failover:tcp://master:61616,tcp://slave:61616" > then what would happen if one of the routes lost it's consumer? What I would > want would be for it to failover the entire broker, not just the one > consumer.
Each route has a pool of possible consumers you can enable; if you use the defaults it will be sharing a JMS connection across all consumers & producers for the same ActiveMQ component and all its endpoints. Failover happens at the connection level; so when the master fails the connection fails over to the slave - and all producers/consumers will be resumed > We are also considering keeping camel embedded, but using > brokerURL="failover:vm://radar-broker,vm://radar-broker" Failover is kinda pointless using the vm transport - as the vm transport never fails :) Only sockets/remote brokers do > Another idea we have is to move all our single threaded consumers to a SEDA > model. Is the thread pool management within the SEDA component rich enough > to respond to a vanishing thread by spawning a new one eventually? What I'd > like is to set an "at least" thread count to say 4, and an "up to" thread > count to say 10. Can it do this? Hopefully in this case the lost consumer > would simply be recreated later. I'm not terribly concerned about an > occasional lost message. Yeah - you should be able to configure whatever Executor you like with a minimum/maximum number of threads etc -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
