synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SYNAPSE-325) Clusteraware sticky loadbalancing does not work in our tests
Date Fri, 23 May 2008 10:47:55 GMT

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

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

I found there isn't enough debug logs and hence I will add some logs before I commit the code.

> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message