[
https://issues.apache.org/jira/browse/SYNAPSE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599325#action_12599325
]
Eric Hubert commented on SYNAPSE-325:
-------------------------------------
Ruwan, this sonds promising. I also like the idea of adding more debug-output
at some places. I had the same impression as you. Regarding the copy-past-code
I haven't seen it related to only one class. I saw same code-fragments over
different classes. Right now I'm unfortunately to busy to go over the code. I'm
sorry about that. I would like to help here as well.
When you commit the code changes, could you please reference the relevant
svn-revision(s) in this issue. I'm interested to learn more about the codebase
and understand the changes. Thanks!
> 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
> Assignee: Ruwan Linton
> 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]