best approach for updating a live servlets site without booting off users

[marc2112]

Hi all-

Does anyone have any great ideas or experiences they could share
regarding pushing new code out to a live website? I have two load
balanced machines running my application. There is some important
state in the HttpSession.

I'm currently running Jetty 5 but would consider switching to another
open-source container if it made the most sense for this need.

Some approaches I'm considering:
- Session replication - replicate sessions among all web servers such
that it doesn't matter which web server the user goes to. If I take
one down, the load balancer will just send existing connections to the
other machine.

- Use the load balancer - have all new sessions go to one host. When
all of the sessions on the other host log off, upgrade that machine.
Then, have all new sessions go to the updated host and wait to update
the other

- Manufacture a session id guid and use that to reconstruct state from
the database if the session doesn't exist. Some concerns I have with
this relate to session hijacking issues.

I'm sure there are much better and/or proven strategies that you all
have used. If you could share your thoughts and experiences, I'd be
much obliged.

Thanks!

 

[Wesley Hall]

Hi all-

Does anyone have any great ideas or experiences they could share
regarding pushing new code out to a live website? I have two load
balanced machines running my application. There is some important
state in the HttpSession.

I'm currently running Jetty 5 but would consider switching to another
open-source container if it made the most sense for this need.

Some approaches I'm considering:
- Session replication - replicate sessions among all web servers such
that it doesn't matter which web server the user goes to. If I take
one down, the load balancer will just send existing connections to the
other machine.

- Use the load balancer - have all new sessions go to one host. When
all of the sessions on the other host log off, upgrade that machine.
Then, have all new sessions go to the updated host and wait to update
the other

- Manufacture a session id guid and use that to reconstruct state from
the database if the session doesn't exist. Some concerns I have with
this relate to session hijacking issues.

I'm sure there are much better and/or proven strategies that you all
have used. If you could share your thoughts and experiences, I'd be
much obliged.

Thanks!

Interesting problem.

The issue with using session replication and per request load balancing
is that your app has to handle a situation where two requests from the
same user may hit two different versions of the application (if one
server has been upgraded and not the other). This could be problematic.

I dont really understand the session hijacking problem with the DB
solution, essentially you are just changing the storage location from
the web tier to the database. A session id is used in both cases and is
subject to the exact same security considerations. This is a workable
solution I think, but there are some architecture issues with pushing
web state to the database. You also may have some problems if the
session data changes between application version.

To me, the most robust solution would be 'sticky sessions', which is
basically what you have suggested as your second solution. What happens
here is that users are balanced between servers until they do something
that results in the creation of session state. At this point their
session is 'tied' to this server and all requests are forwarded to the
correct server by your load balancer. When you want to upgrade a server
you configure your balancer to stop accepting new connections to the
server you want to update, only let it handle request from users that
currently have a session on that server. Eventually you will have no
sessions on the server and you are free to upgrade. Then you just bring
the server back up and have it forward requests again.

The big advantage here is that you could completely change the format of
the session state. It is always created by the version of the
application that uses it.

 

[marc2112]

Thanks. It makes sense what you said about session hijacking risks
being the same either way.

What I was hoping to hear was that there was some Jetty API or
something where I could effectively deploy a new version of my war and
have new contexts be directed there. Basically, just binding new
sessions to a different application context and not starting any new
sessions against the old application contexts.

Does JBoss or Jetty have any capabilities like that?