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: Critical
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]
