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

Discussion in 'Java' started by marc2112@yahoo.com, Dec 5, 2006.

  1. Guest

    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!
    , Dec 5, 2006
    #1
    1. Advertising

  2. Wesley Hall Guest

    Re: best approach for updating a live servlets site without bootingoff users

    wrote:
    > 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.
    Wesley Hall, Dec 5, 2006
    #2
    1. Advertising

  3. Guest

    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?
    , Dec 6, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. amit
    Replies:
    0
    Views:
    374
  2. yogesh
    Replies:
    3
    Views:
    574
    Kenny McCormack
    Feb 12, 2006
  3. shahoo

    MBR,C++ and system booting

    shahoo, Mar 4, 2006, in forum: C++
    Replies:
    5
    Views:
    540
    Ben Pope
    Mar 5, 2006
  4. =?Utf-8?B?c3Jpa2FudGg=?=

    I have a problem in booting

    =?Utf-8?B?c3Jpa2FudGg=?=, Aug 3, 2007, in forum: ASP .Net
    Replies:
    0
    Views:
    408
    =?Utf-8?B?c3Jpa2FudGg=?=
    Aug 3, 2007
  5. Steve Simmons
    Replies:
    0
    Views:
    137
    Steve Simmons
    Feb 1, 2013
Loading...

Share This Page