[
https://issues.apache.org/jira/browse/SYNAPSE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599174#action_12599174
]
Eric Hubert commented on SYNAPSE-325:
-------------------------------------
Up to now I had no time to analyze the log statements - a colleague conducted
the tests and I only reported the results. The problem seems to be related to
the fact, the name of the endpoint in DispatcherContext is null, thus the
default constant for anonymous endpoints will be used. So clustering can't
work. The question is: Why is the endpoint name null? While having a look at
the code it could I noticed the following which might be helpful:
I analyzed who sets the list of endpoints of the SALoadbalanceEndpoint (the
list of endpoints within the session affine loadbalancing group). This is done
from the SALoadbalanceEndpointFactory.createEndpoint(OMElement, boolean).
Within this method the private method getEndpoints(OMElement, Endpoint) is
called. Please have a look at the following line in the while loop:
Endpoint endpoint = EndpointFactory.getEndpointFromElement(endptElem, true);
It is always called with true. This looks strange to me. But while looking at
the code of the factories I don't understand the meaning of the parameter.
Javadoc seems to be clear, but I can't find a place where this parameter
actually matters. It seems as if it is never used. Is this observation correct?
So in our case we most likely instantiate a IndirectEndpointFactory and call
createEndpoint where the boolean parameter anonymousEndpoint is not used. I
could not find a factory where it is used for some purpose. I'm wondering how
an indirect andpoint can have a name? Isn't only the key interesting? So for
our example the name of the indirect endpoint will be null. Just from reading
the code this could be the problem. The indirect endpoints have no name. If I
get it right the resulution of the key only happens during the invocation of
the send-method of the indirect endpoint.
What do you think? Also I noticed that there is a lot of copy and paste-code.
For the next release this endpoint-code should get some cleanup.
> Clusteraware sticky loadbalancing does not work in our tests
> ------------------------------------------------------------
>
> Key: SYNAPSE-325
> URL: https://issues.apache.org/jira/browse/SYNAPSE-325
> Project: Synapse
> Issue Type: Bug
> Affects Versions: 1.2-QA-B3
> Environment: WSO2 ESB: 1.7 beta1 - deployed on 3 clustered nodes:
> Nodes running on: Linux 2.6.18-6-686-bigmem
> Java version information for each node:
> Version "1.5.0_15"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_15-b04, mixed mode)
> Endpoint configuration:
> Load Balancer Endpoint defining a group of 3 address endpoints
> Each address endpoint is hosted on a different machine.
> Application server hosting services under test:
> JBoss version 4.3.0
> Running on: Linux 2.6.18-6-686-bigmem
> Reporter: Eric Hubert
> Priority: Blocker
> Fix For: 1.2
>
> Attachments: axis2_clustering_section.xml, synapse.xml
>
>
> Test Scenario:
> -------------------
> Service under test description: the service doesn't need any parameter and
> returns a string (basic 'hello world' implementation)
> Tool used for submitting requests: soapUI
> Soap requests submitted:
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ser="http://service.jamba.de/";>
> <soapenv:Header>
> <ClientID xmlns="http://ws.apache.org/namespaces/synapse";>edp1[or
> edp2]</ClientID>
> </soapenv:Header>
> <soapenv:Body>
> <ser:helloWorld/>
> </soapenv:Body>
> </soapenv:Envelope>
> The test has been performed as follows:
> All nodes are restarted and 5 requests are sent to the clustered node as
> follows:
> - The first request is sent specifying a ClientID (edp1) value in the SOAP
> Header to Load Balancer Endpoint configured in the first node.
> - A request specifying a different ClientID (edp2) value in the SOAP Header
> is sent to each one of the three nodes, starting with the second node and
> finishing with the one which got the first request with ClientID edp1
> - Another request alike the first is sent again on the first node
> 1st call ClientID edp1 => node1
> 2nd call ClientID edp2 => node2
> 3rd call ClientID edp2 => node3
> 4th call ClientID edp2 => node1
> 5th call ClientID edp1 => node1
> Expected Results:
> 1st call ClientID edp1 => node1 -> stickying to the first available Address
> endpoint (A) configured in the LoadBalancer Endpoint
> 2nd call ClientID edp2 => node2 -> stickying to the next available Address
> endpoint (B) configured in the LoadBalancer Endpoint
> 3rd call ClientID edp2 => node3 -> routing to the same endpoint of 2nd call
> because of stickyness
> 4th call ClientID edp2 => node1 -> routing to the same endpoint of 2nd call
> because of stickyness
> 5th call ClientID edp1 => node1 -> routing to the same endpoint of 1st call
> because of stickyness
> Test Results:
> 1st call ClientID edp1 => node1 -> stickying to the first available Address
> endpoint (A) configured in the LoadBalancer Endpoint
> 2nd call ClientID edp2 => node2 -> stickying to the next available Address
> endpoint (B) configured in the LoadBalancer Endpoint
> 3rd call ClientID edp2 => node2 -> stickying to the next available Address
> endpoint (C) configured in the LoadBalancer Endpoint : FAILURE
> 4th call ClientID edp2 => node1 -> routing to the same endpoint of 3rd call
> Address endpoint (C) (because of stickyness?) : FAILURE
> 5th call ClientID edp1 => node1 -> stickying to the next available Address
> endpoint (C) configured in the LoadBalancer Endpoint : FAILURE
> We increased the loglevel of some classes to DEBUG as you can see in the logs
> to provide some help fixing the issue. We are not sure about the warning. All
> our endpoints are referenced by name. We will also attach the synapse.xml
> used as well as the relevant clustering part from the axis2.xml.
> ESB Logs (Sequence follows timestamp):
> 1st Call on Node One:
> [2008-05-21 12:01:25,206] WARN: DispatcherContext In a clustering environment
> , the endpoint name should be specified even for anonymous endpoints.
> Otherwise , the clustering would not be functioned correctly if there are
> more than one anonymous endpoints.
> [2008-05-21 12:01:25,207] DEBUG: AlgorithmContext Going to replicate the
> property with key : HelloWS_LOADBALANCER_currentEPR value : 1
> [2008-05-21 12:01:25,304] WARN: DispatcherContext In a clustering environment
> , the endpoint name should be specified even for anonymous endpoints.
> Otherwise , the clustering would not be functioned correctly if there are
> more than one anonymous endpoints.
> [2008-05-21 12:01:25,304] DEBUG: DispatcherContext Going to replicate the
> property with key : HelloWS_LOADBALANCER_session_edp1 value :
> AnonymousEndpoint
> 2nd Call on Node Two:
> [2008-05-21 12:02:29,140] WARN: DispatcherContext In a clustering environment
> , the endpoint name should be specified even for anonymous endpoints.
> Otherwise , the clustering would not be functioned correctly if there are
> more than one anonymous endpoints.
> [2008-05-21 12:02:29,276] DEBUG: AlgorithmContext Going to replicate the
> property with key : HelloWS_LOADBALANCER_currentEPR value : 2
> [2008-05-21 12:02:29,297] WARN: DispatcherContext In a clustering environment
> , the endpoint name should be specified even for anonymous endpoints.
> Otherwise , the clustering would not be functioned correctly if there are
> more than one anonymous endpoints.
> [2008-05-21 12:02:29,297 ] DEBUG: DispatcherContext Going to replicate the
> property with key : HelloWS_LOADBALANCER_session_edp2 value :
> AnonymousEndpoint
> 3rd Call on Node Three:
> [2008-05-21 12:03:11,329] WARN: DispatcherContext In a clustering
> environment , the endpoint name should be specified even for anonymous
> endpoints. Otherwise , the clustering would not be functioned correctly if
> there are more than one anonymous endpoints.
> 4th Call on Node One:
> No log for DispatcherContext or AlgorithmContext
> 5th Call on Node One:
> No log for DispatcherContext or AlgorithmContext
> During the tests we also noticed that some endpoints "unmotivated" changed
> there state from true to false, even though all service have been reachable
> for the whole period of the tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
