[ https://issues.apache.org/activemq/browse/SM-494?page=comments#action_36624 ] Michael Studman commented on SM-494: ------------------------------------
So here's what was going on when it wasn't working for me: JBIContainer.start { Registry.start() { A.start() { activate endpoint } B.start() { sendSync to A; activate endpoint } } Broker.start() { JMSFlow.start() { } } } So, A is started and has activated its endpoing before B calls sendSync. The sendSync fails only once it times out because there's no queue consumer for A's queue. If I change it to this it works: JBIContainer.start { Broker.start() { JMSFlow.start() } Registry.start() { A.start() { active endpoint } B.start() { sendSync to A; activate endpoint ) } } } This is because the JMSFlow listens for A's activation events and sets up a queue and a consumer for messages to/from it. > Problems with JMSFlow and sendSync in start() callbacks. > -------------------------------------------------------- > > Key: SM-494 > URL: https://issues.apache.org/activemq/browse/SM-494 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-core > Affects Versions: 3.0-M1 > Reporter: Michael Studman > Priority: Critical > > I have two simple JBI components A & B; B sends (synchronously) a message to > A in its start() method. > When using ST or SEDA flow there are no problems - the flow completes. > When I use JMS flow, however, B blocks when sending synchronously. I can see > that A is started before B is started - it just seems A never gets the > message. > Reading the code it seems JMSFlow will route a requests even before it is > started by creating a queue and placing a message on it. Because it hasn't > been started, however, it won't have a queue listener in place to respond for > that queue and so a sync message will just timeout without response. > By simply switching the order of flow.start() and registry.start() in > Broker.start() I was able to get the desired behaviour for my situation but I > think this may actually introduce other bugs (e.g. JMS flow accepting remote > messages when some or all components have not yet been started?). > The behaviour I was expecting was that sending sync to a component already > started should not block and sending sync to one not already started should > fail. I think the flows and the registry need to work together a bit better. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira