[jira] Issue Comment Edited: (SM-625) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.MultipleFlowsTest

["Oleg Zhurakousky (JIRA)" <ji...@apache.org>]

    [ 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.