[jira] Commented: (SM-625) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
[
https://issues.apache.org/activemq/browse/SM-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40378
]
Oleg Zhurakousky commented on SM-625:
-
You're right; there is no way of knowing if an Endpoint exists anywhere in the
cluster. But I think the question I am raising is: Would it be a good idea to
give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
Failed unit test (servicemix-core) :
org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
-
Key: SM-625
URL: https://issues.apache.org/activemq/browse/SM-625
Project: ServiceMix
Issue Type: Sub-task
Components: servicemix-core
Affects Versions: 3.0
Reporter: Fritz Oconer
Fix For: 3.2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SM-625) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
[
https://issues.apache.org/activemq/browse/SM-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40378
]
ozhurakousky edited comment on SM-625 at 10/15/07 5:38 AM:
---
You're right; there is no way of knowing if an Endpoint exists anywhere in the
cluster. But I think the question I am raising is: Would it be a good idea to
give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
{code}
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
{/code}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
was (Author: ozhurakousky):
You're right; there is no way of knowing if an Endpoint exists anywhere in
the cluster. But I think the question I am raising is: Would it be a good idea
to give a requester a benefit of the doubt. In other words if you ask for
something and I don't see it right away, I'll make an attempt and take some
time to look for it before I give you a definitive NO.
In this situation we are at the mercy of network, its speed and configuration
(something we can't control from SM) and I think the least we could do is to
give networking components to do what it is supposed to do and either come up
with an endpoint or with message stating a potential reason why endpoint was
not found.
Here is a sample code representing what I am talking about.
int retries = 0;
while (endpoints.length 1 || retries 5){
endpoints = resolveAvailableEndpoints(context, exchange);
Thread.sleep(500);
retries++;
}
Most of the time if Endpoint is there the loop will exit right away. It will
only execute retry logic if array is empty.
P.S. I am purposely trying to be a devils advocate here. I am not sure I
completely agree with this solution and mainly doing it to facilitate the
discussion since one thing I definitely agree. . . it is a part of the bigger
issue.
Meanwhile I'll be digging. . . .
Also, as far as fixing the test, I can definitely wrap the sendMessages(..)
call in the retry logic instead of relying on Thread.sleep(..) but would it
really solve a bigger problem. . .
Failed unit test (servicemix-core) :
org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest
-
Key: SM-625
URL: https://issues.apache.org/activemq/browse/SM-625
Project: ServiceMix
Issue Type: Sub-task
Components: servicemix-core
Affects Versions: 3.0
Reporter: Fritz Oconer
Fix For: 3.2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ServiceMix Bean issues with send()
Hi I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried: - Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel - B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel What I see is that the Delivery Channel is sending the Mirror ME which is nearly the same but just has the opposite role (here consumer). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME. Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service? If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)? Thank you Andreas Schaefer CEO of Madplanet.com Inc. [EMAIL PROTECTED] PGP.sig Description: This is a digitally signed message part
[jira] Created: (SM-1107) Deploy endpoints and listeners through the lwcontainer
Deploy endpoints and listeners through the lwcontainer -- Key: SM-1107 URL: https://issues.apache.org/activemq/browse/SM-1107 Project: ServiceMix Issue Type: New Feature Components: servicemix-lwcontainer Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix Bean issues with send()
On 10/16/07, Andreas Schaefer (2) [EMAIL PROTECTED] wrote: Hi I try to figure out what is going wrong with the ServiceMix Bean component when used with an asynchronous message exchange (send()). There is a good chance to I do not understand how the message exchange should work. This is what I tried: - Bean SU 1 sends an In-Out ME to another Bean SU 2 with send() on the Delivery Channel - B SU 2 handles the message and puts in an Out normalized message and then sends the ME back with send() on its Delivery Channel What I see is that the Delivery Channel is sending the Mirror ME which is nearly the same but just has the opposite role (here consumer). This means that the message is sent back to the Consumer Bean Endpoint because that is the address set in the Mirror ME. Yeah. The thing is that in JBI, an exchange is sent from a component to an endpoint. In an InOut mep, the provider will send the exchange with the out message inside, the nmr will route it to the consumer component, which will dispatch it to the consumer endpoint. The endpoint processes the response and need to send back the exchange with a DONE status. The mirror stuff is used internally. Is my assumption right that when a message is read from the NMR that it goes through the Provider endpoint and when the message is sent back that it then goes first through the Consumer endpoint of the same service or should it go to the Consumer endpoint of the calling service? I don't understand what is the difference you make between Consumer endpoint of the same service and Consumer endpoint of the calling service ? Do you mean the POJO instance ? If the consumer endpoint of he SAME service is called then who is responsible on sending the message back to the calling service (B SU 1) and is there a way to do this automatically (meaning with having to code anything in the Bean SUs)? If you don't implement MessageExchangeListener and you want to use InOut asynchronously, then you need to use the @Callback annotation and the Destination. Else, I think the problem is that the component does not track that a given endpoint acts as a consumer and send an exchange, so that it can not route it back to the endpoint. This would require wrapping the DeliveryChannel or simply overriding the sendConsumerExchange method from the component. All exchanges sent from endpoints could be tracked, but we still don't have any way to call the bean, unless it has a @Callback. Can you post your beans, because servicemix-bean has different ways of writing a bean, so... Thank you Andreas Schaefer CEO of Madplanet.com Inc. [EMAIL PROTECTED] -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (SM-1097) Remote shell console based on GShell
[ https://issues.apache.org/activemq/browse/SM-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40388 ] Guillaume Nodet commented on SM-1097: - GShell integration has been moved to ServiceMix 4.0 branch. https://svn.apache.org/repos/asf/incubator/servicemix/branches/servicemix-4.0/gshell Remote shell console based on GShell Key: SM-1097 URL: https://issues.apache.org/activemq/browse/SM-1097 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Fix For: 4.0 Work is in progress at http://svn.apache.org/repos/asf/incubator/servicemix/branches/osgi/gshell/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
