M
mustafaml
Hi,
Currently we implement 'stick sessions' to preserve state - a users IP
address is mapped internally to an application server instance when the
initial request is served by the application server. All subsequent
requests coming from the same IP are redirected by the web server to
the application server based upon the mapping stored.
This approach has the following disadvantages:
1)If users belonging to the same organization are behind a firewall, to
the external world they will appear to have the same IP address. This
will result in ALL users of such an organization being directed to the
same application server for all requests made, rather than only one
single user being redirected to the same application server. This can
cause load imbalance.
2) We have to manually edit the WebSphere plugin regen scripts on each
appserver to point the correct webservers to the correct appservers.
The regen must then be run on each appserver and the correct plugin
must be moved to the correct webserver.
To avoid this, we are thinking of ways to turn 'sticky IP sessions'
off.
One approach we've thought of is using clones. We deploy our
applications on clones and turn off sticky IP sessions. End users will
continue to get directed to the correct app server / clone (i.e session
affinity is maintained) - but this time based on the clone id instead
of the IP.
This will get rid of both the problems.
Has anybody done anything of this sort before? Are we on the right
track? Any comments / suggestions will be welcome,
PS: We are not looking at distributed sessions because our applications
store non-serializable objects in HttpSessions and we do not want to
rework all of them.
Regards,
Mustafa Lokhandwala
Currently we implement 'stick sessions' to preserve state - a users IP
address is mapped internally to an application server instance when the
initial request is served by the application server. All subsequent
requests coming from the same IP are redirected by the web server to
the application server based upon the mapping stored.
This approach has the following disadvantages:
1)If users belonging to the same organization are behind a firewall, to
the external world they will appear to have the same IP address. This
will result in ALL users of such an organization being directed to the
same application server for all requests made, rather than only one
single user being redirected to the same application server. This can
cause load imbalance.
2) We have to manually edit the WebSphere plugin regen scripts on each
appserver to point the correct webservers to the correct appservers.
The regen must then be run on each appserver and the correct plugin
must be moved to the correct webserver.
To avoid this, we are thinking of ways to turn 'sticky IP sessions'
off.
One approach we've thought of is using clones. We deploy our
applications on clones and turn off sticky IP sessions. End users will
continue to get directed to the correct app server / clone (i.e session
affinity is maintained) - but this time based on the clone id instead
of the IP.
This will get rid of both the problems.
Has anybody done anything of this sort before? Are we on the right
track? Any comments / suggestions will be welcome,
PS: We are not looking at distributed sessions because our applications
store non-serializable objects in HttpSessions and we do not want to
rework all of them.
Regards,
Mustafa Lokhandwala