You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Michael Studman (JIRA)" <ji...@apache.org> on 2006/07/24 12:05:23 UTC
[jira] Created: (SM-494) Problems with JMSFlow and sendSync in
start() callbacks.
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
[jira] Resolved: (SM-494) Problems with JMSFlow and sendSync in
start() callbacks.
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-494?page=all ]
Guillaume Nodet resolved SM-494.
--------------------------------
Fix Version/s: 3.1
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Tue Sep 26 06:07:14 2006
New Revision: 450039
URL: http://svn.apache.org/viewvc?view=rev&rev=450039
Log:
SM-494: Problems with JMSFlow and sendSync in start() callbacks
Modified:
incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/container/JBIContainer.java
> 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
> Assigned To: Guillaume Nodet
> Priority: Critical
> Fix For: 3.1
>
>
> 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
[jira] Commented: (SM-494) Problems with JMSFlow and sendSync in
start() callbacks.
Posted by "Guillaume Nodet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-494?page=comments#action_36623 ]
Guillaume Nodet commented on SM-494:
------------------------------------
If you send an exchange to another component which is not started, no endpoint should be activated by this component, so the send / sendSync should fail.
How did you do that ?
> 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
[jira] Commented: (SM-494) Problems with JMSFlow and sendSync in
start() callbacks.
Posted by "Michael Studman (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (SM-494) Problems with JMSFlow and sendSync in
start() callbacks.
Posted by "Michael Studman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-494?page=comments#action_36625 ]
Michael Studman commented on SM-494:
------------------------------------
Oh, and in the first scenario, B sending a message to A does actually hit JMSFlow.doRouting before it is started (which causes the queue without a consumer in the first place). I imagine doRouting should fail (silently like onInternalEndpointRegistered?) if it is not started.
That means, though, that routing probably should be started before the registry.
> 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