Mailing List Archive

[mod_backhand-users] About session control with Backhand
Hello. This is Keiichiro Katayama.
I have some cases of web system using Backhand.
One case is as follows.


--------------------------------------------------------
| | |
machine A machine B ......... machine M
(master) (slave) (slave)


I want to control sessions to peculiar machine using with JAVA Servlet
/JSP. When user accesses the machine X at first , the user next
access will be expected to connect the machine X until session is
closed by user.

There is two methods of session control in JAVA Servlet/JSP on JAVA
Development Environment.

One method is realized by cookie.
But this method can not use in load balancing environment.

Another method of session control is realized by URL IP redirect.
In this logic , Servlet/JSP controls the session for connecting the
same machine as first connection.

If you connect to the URL "A" and the access is redirected to the
machine X by Backhand , your next access will be connected for machine
X. If backhand redirect the access to machine Y , your next access
is connected to machine Y. It's good.

When the Backhand redirects the access to slave machine , I think
there is no problem. But If the Backhand selects themselves , your
next access is controled to master machine. For that case , master
machine will select the redirect machine at next access. It is big
problem for us.

I want to limit the subsequent accesses for session control to the
machine connected first. Do you have any solutions?
[mod_backhand-users] About session control with Backhand [ In reply to ]
On Tuesday, November 13, 2001, at 12:11 PM, Keiichiro Katayama wrote:
> There is two methods of session control in JAVA Servlet/JSP on JAVA
> Development Environment.
>
> One method is realized by cookie.
> But this method can not use in load balancing environment.

Cannot or should not? I think that sessions stickiness is an evil
thing. However, Java coders left and right "demand it." Implement
shared sessions! You have JMS after all.

Anyway, if you encode the machine name or mahcine IP address somewhere
in the cookie, the load-balancer can find it an stick the session with
that cookie to the same machine on subsequent connections -- at least
mod_backhand can.

You will need to write a custom candidacy function for this if you
cannot match he machine encoding style used by bySession.

> I want to limit the subsequent accesses for session control to the
> machine connected first. Do you have any solutions?

You can do this by writing a custom candidacy function and a little Java
glue.

I had to implement this for one of my clients -- their architecture had
some obstacles preventing them from encoding them machine IP address in
a style understood by bySession. They own the IP, so I will have to
check with them to see if I can publish it. Honestly, it closely
resembles the bySession code in builtins.c

--
Theo Schlossnagle
1024D/82844984/95FD 30F1 489E 4613 F22E 491A 7E88 364C 8284 4984
2047R/33131B65/71 F7 95 64 49 76 5D BA 3D 90 B9 9F BE 27 24 E7
[mod_backhand-users] About session control with Backhand [ In reply to ]
Dear Theo,

This is Keiichiro Katayama from Tokyo. Thank you for your nice
advice.

Theo Schlossnagle worte it! :
>Anyway, if you encode the machine name or mahcine IP address somewhere
>in the cookie, the load-balancer can find it an stick the session with
>that cookie to the same machine on subsequent connections -- at least
>mod_backhand can.
>You will need to write a custom candidacy function for this if you
>cannot match he machine encoding style used by bySession.

Since I got response from you, I have been trying to use bySession.
And tonight , I was successful. I defined a new cookie key word
"FSESSION="("F" was taken from the initial of my company name) , and I
have set the hex encorded IP address in the key word. I made a small
java beans which was used to set that IP cookie at first , and I have
set the java beans into the start of the session.

It realized wonderful power. I appreciate your support deeply. Thank
you very much.