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

Reply via email to