|
[
Permlink
| « Hide
]
Andrew Perepelytsya added a comment - 29/Mar/08 09:54 AM
As discussed yesterday, this has to get into the 2.0 GA.
It's not entirely trivial to port MultiConsumerJmsMessageReceiver to 2.0.x: in 1.4.x the SubReceiver would have the JmsConnector create an new reconnect handler for use. In 2.0.x that reconnect handler can be configured as a reference to a spring bean now. The reconnect handler is stateful, however so we have to have a means for creating copies of it now.
The solution would be to change the jms schema, requiring an object factory for the reconnect handler now. This way, the SubReciver can create new instances via the configured object factory. To clear the confusion. We are talking about redelivery handlers, not reconnection strategies. The latter is a different concept applied at a slightly different level.
That's what you get from writing comments while listening the MuleCon session.
Obviously I was talking about redelivery handlers and after some more investigation the plan is now to keep the reference to the redelivery handler as it is and only make sure in the BeanDefinitionParser that it's configured to the prototype scope. The switch has been flipped, MultiConsumer is now the default: http://fisheye.codehaus.org/changelog/mule/?cs=11596
 Updated jms topic test configs to have 1 consumer thread for correct behavior. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Critical
Replace a default jms message receiver with MultiConsumer receiver
