tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Kopsiaftis <>
Subject Re: tomcat session id
Date Sat, 14 Jul 2012 04:12:57 GMT
Well basically, For the output servlet, I am using comet to keep the
connection alive and push things out to the client when they are available.
This program is a chat program with a drawing capability, so two people can
draw on the same canvas and chat with each other.

On Fri, Jul 13, 2012 at 10:02 PM, Christopher Schultz <> wrote:

> Hash: SHA1
> Elias,
> On 7/13/12 9:39 AM, Elias Kopsiaftis wrote:
> > I am working on a program that uses two servlets, one for input
> > from the client, and one for output to the client.
> Good so far.
> > My question is, from the client side, I will have two connections
> > open to the server, one for input, and one for output
> Okay, you've lost me: what you've described is not how HTTP works. A
> client makes one (or more) connection(s), sends a request (on each
> connection) and receives a response over the same connection.
> > so, when both connect, will both connections have the same
> > sessionid even though they are accessing two different servlets?
> > both servlets will be on the same tomcat
> Well, if you are using cookies and your client manages them globally,
> then all connections should be associated with the same session. This
> is the case with most web browsers in their default configuration.
> If you are using URL re-writing to maintain session affinity, then
> you'll have to make sure that all of the URLs that you issue from the
> client to the server have the URL properly encoded. If you have
> written your webapp correctly, most of this should be taken care of by
> the container. Your client also has to be willing to include "path
> parameters" in the URLs that it passes-back to the server. This is
> also the case with most web browsers in their default configuration.
> But back to your plan to make separate "input" (to the server) and
> "output" (from the server) connections does not make any sense unless
> you have some justification for making things that complicated.
> I'm available for enlightenment, though I suspect your requirements
> are actually a lot simpler than what you describe.
> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Mozilla -
> oSgAnieuXC7721SMfwUzD0gWfZHaFwaB
> =T9FG
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message