APAR status
Closed as program error.
Error description
For some internal reasons, the customer wanted to
accomplish so that some URIs are always being handled
only by one AppServer, some URIs will be handled by
other AppServer, and the rest by both AppServers in
the Cluster. It looked like an unsolvable task, but the
customer solved it. Customer created "virtual"
ServerClusters, Route & URIGroup definitions that
should accomplish it. It is not typical, but
technically it should work, if those "virtual"
Clusters, URIGroup & Transport definitions are added
properly into the plugin-cfg.xml file. Customer did it,
but it was not working. Later he re-aranged the
sequence of the "virtual" server clusters & it started
to work. So the main issue now is, that the customer
has two sets of plugin-cfg.xml, where he added manually
two "virtual" clusters with the same corresponding
Route & URIGroup statements and one plugin-cfg.xml is
working & the other is not working. Customer provided
full plugin trace from both scenarios - working &
non working. Verified, that both plugin cfg files
contain the same directives with the same values, only
a sequence of some directives is different. I think
that it should not matter.
.
When I reviewed full plugin trace from the working
plugin cfg file, I saw this information there:
STATS: ws_server_group: serverGroupCheckServerStatus:
Checking status of ethan_CMWASdeve01ethan,
ignoreWeights 0, markedDown 0, retryNow 0,
wlbAllows 1 reachedMaxConnectionsLimit 0
TRACE: ws_server_group: lockedServerGroupUseServer:
Server ethan_CMWASdeve01ethan picked, weight 0.
.
In the full plugin trace of the non working plugin
cfg file I see the following:
STATS: ws_server_group: serverGroupCheckServerStatus:
Checking status of ethan_CMWASdeve01ethan,
ignoreWeights 0, markedDown 0, retryNow 0,
wlbAllows 0 reachedMaxConnectionsLimit 0
TRACE: ws_server_group: serverGroupCheckServerStatus:
Server ethan_CMWASdeve01ethan is marked up and
not selected; current weight 0
TRACE: ws_server_group: serverGroupGetNextPrimaryServer:
getting the the next primary server
STATS: ws_server_group: serverGroupCheckServerStatus:
Checking status of ripley_CMWASdeve01ripley,
ignoreWeights 0, markedDown 0, retryNow 0,
wlbAllows 0 reachedMaxConnectionsLimit 0
TRACE: ws_server_group: serverGroupCheckServerStatus:
Server ripley_CMWASdeve01ripley is marked up
and not selected; current weight 0
ERROR: ws_server_group: serverGroupNextRoundRobinServer:
Failed to find a server; all could be down or
have reached the maximimum connections limit
.
So the qustion is, why in the second case the
"wlbAllows 0" is logged by plugin in the trace, because
I belive that this caused this issue.
.
LoadBalanceWeight="5"is set for all cluster members.
The interesting thing is, that the request is in both
cases being handled by the original URIGroup/ServerGroup
that was not being added manualy in the plugin-cfg.xml,
in one case it works but in other case it does not.
.
This problem very likely occurs in also in WebSphere 5.1 plugin,
probably does not occur in WebSphere 4.0 plugin (But I do not
know for sure).
Local fix
Manually re-aranging ServerGroup directives in the plugin cfg
file but I do not know what pattern would work for sure. So
I can say that we do not have a reasonable workaround.
Problem summary
****************************************************************
* USERS AFFECTED: Users of Websphere 5.0 plug-in that use *
* the same server as primary or backup server *
* of different server groups. *
****************************************************************
* PROBLEM DESCRIPTION: When the same server was used as *
* primary server for multiple server *
* groups, the load balance weight from a *
* different server group could be used, *
* thus causing the load balance failure. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
Plug-in did not resolve the primary and the backup server
names correctly.
Problem conclusion
When a server works as primary or backup server for multiple
server groups, load balance weight is maintaied for each server
group. The load balance weight value associated with the
server group will be used when doing the load balance within
that server group.
Temporary fix Comments
APAR information |
APAR number |
PQ83264 |
Reported component name |
WAS NETWRK DEPL |
Reported component ID |
5630A3601 |
Reported release |
00S |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2004-01-14 |
Closed date |
2004-01-23 |
Last modified date |
2004-01-23 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R103 PSY |
UP |
R10A PSY |
UP |
R10H PSY |
UP |
R10I PSY |
UP |
R10P PSY |
UP |
R10S PSY |
UP |
R10W PSY |
UP |
|