[ 
https://issues.apache.org/jira/browse/SYNAPSE-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599317#action_12599317
 ] 

Ruwan Linton commented on SYNAPSE-325:
--------------------------------------

I think I got hold of the problem as well as the solution. Now I am testing 
this in detail. 

While doing the tests I found that the namespace that has been used for the 
Client-ID soap header used by the client session of SALoadbalancing is not the 
same as synapse namespace. 

It is http://ws.apache.org/namespacecs/synapse where as it should be 
http://ws.apache.org/ns/synapse 

I think we can change this as well with this fix ;-)

> 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