[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_40500 ] Resigned Employee commented on SM-625: -- Please be informed that I am no longer accessible through this email address. Pls refrain from sending further messages. I will just personally contact you with my new email address. For any concerns / issues / inputs relating to your transactions with Exist, kindly forward email to [EMAIL PROTECTED] Thank you HR Dept > 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.1 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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] 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_40377 ] Guillaume Nodet commented on SM-625: Your comments are related to something that I'd like to be fixed somehow: there is no way to make the difference between an endpoint that has been shutdown for maintenance (restarting the container, updating, etc...) so that it will be up again later, and an endpoint that has been uninstalled (it won't appear again). But this is another problem... So, for the timeout, I fear that it will lead to an additional time waiting in all the other cases: for example if there is no cluster or if all nodes are up, but the endpoint does actually not exist, i'd find it odd to add a timeout in this case. The problem is that i'm not sure we can easily find a workaround. Ideas ? > 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] 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_40376 ] Resigned Employee commented on SM-625: -- Please be informed that I am no longer accessible through this email address. Pls refrain from sending further messages. I will just personally contact you with my new email address. For any concerns / issues / inputs relating to your transactions with Exist, kindly forward email to [EMAIL PROTECTED] Thank you HR Dept > 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] 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_40375 ] Oleg Zhurakousky commented on SM-625: - This is another test that doesn't do any assertions however it is pretty obvious what it is trying to do and I think I can fix it. But before. . . Here is a quick summary of what it does: Starts two containers with two flows each (JCA and JMS), defines multiple Senders and Receivers and then attempts to send a batch of 100 messages using all possible combinations of Senders and Receivers. The reason for this tests instability is because it only works if Demand Forwarding Bridge between the two containers is established. Tracing down the exception I got when I removed Thread.sleep(5000) and adding some logging in the class in question here is what I got from EndpointResolverSupport.resolveEndpoint(..) 22:57:30,484 | INFO | main | EndpointResolverSupport | resolver.EndpointResolverSupport 44 | ==> ServiceEndpoint[] size: 0 Here is the output when I did put thread back to sleep and gave both containers enough time to recognize one another's existence. 22:59:08,000 | INFO | main | EndpointResolverSupport | resolver.EndpointResolverSupport 44 | ==> ServiceEndpoint[] size: 1 22:59:08,000 | INFO | main | EndpointResolverSupport | resolver.EndpointResolverSupport 46 | ==> Endpoint: ServiceEndpoint[service=remoteReceiver,endpoint=remoteReceiver] Obviously there are several ways of fixing it, but I also suspect that it could be something bigger, since the same error will occur if Node 1 has Service A and Node 2 has Service B as destination service of Service A. If Node 2 is not up, then you gonna have error. However we have to realize that there are many reasons for Mode 2 (in this scenario) not be up. Node 2 might not be up because no one turned it "on" yet OR because it is coming up and perhaps we should give it an extra time to boot. In other words what I am trying to say is that I see the need for retry logic around this line of code in the EndpointResolverSupport with externally configurable timeout: ServiceEndpoint[] endpoints = resolveAvailableEndpoints(context, exchange); This will fix this problem, but most importantly we can provide a more explicit message about what happened once we go passed the timeout (the message is already explicit: Failed to resolve endpoint: org.apache.servicemix.jbi.NoServiceAvailableException: Cannot find an instance of the service: remoteReceiver. But we can also output a potential reason which could help end user to quickly realize the problem). What do you think? > 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.
