You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Elias Kopsiaftis <ye...@gmail.com> on 2012/07/13 15:39:05 UTC
tomcat session id
I am working on a program that uses two servlets, one for input from the
client, and one for output to the client. My question is, from the client
side, I will have two connections open to the server, one for input, and
one for output, 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
Re: tomcat session id
Posted by Konstantin Kolinko <kn...@gmail.com>.
2012/7/15 Elias Kopsiaftis <ye...@gmail.com>:
> thank you, and it wasnt working thats why i asked. there must be something
> else wrong in my code
Session is recognized by sessionid sent either via a "Cookie" header
in HTTP request, or as a path parameter in URL of HTTP request.
You can inspect what is actually sent to Tomcat by your "client"
either by using network traffic inspection with a tool like Wireshark,
or via configuration of an AccessLogValve in Tomcat. Some references
should be in the FAQ.
If neither info are sent by your "client" program, the session cannot
not be associated with your request and a new session will be created
if a session is needed. (When that happens, a "Set-Cookie" header will
be included in the HTTP response).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Elias,
On 7/15/12 3:52 PM, Elias Kopsiaftis wrote:
> thank you, and it wasnt working thats why i asked. there must be
> something else wrong in my code
Would you care to *post* your code? Perhaps someone with Comet
experience could give you an opinion...
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlADWMQACgkQ9CaO5/Lv0PBZUwCePZ010rYels8flsPIVmABVKb+
nF8An3CquLuIK/RqxYknymrLmf8vRMiS
=xaqS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session id
Posted by Elias Kopsiaftis <ye...@gmail.com>.
thank you, and it wasnt working thats why i asked. there must be something
else wrong in my code
On Sun, Jul 15, 2012 at 3:50 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Elias,
>
> On 7/15/12 1:37 PM, Elias Kopsiaftis wrote:
> > ok i appreciate the input, but for now i will stick with the comet
> > approach because i read that websocket for tomcat 7 is still
> > experimental and i already built a lot of logic around the comet
> > approach. does anyone know the answer to my original question?
>
> As long as one servlet was called long-enough before the second one
> that the session could be created and its id returned to the client
> *and* sessions are supported, then yes, both servlets should have
> access to the same session data.
>
> It should have been easy to test this on your own ...
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlADHvsACgkQ9CaO5/Lv0PCwaACfej2clhjZIZ+UpF2CpNCoOtIX
> HvUAniuzrjEf7AakeL6ONaIN736TImlr
> =1ZqX
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: tomcat session id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Elias,
On 7/15/12 1:37 PM, Elias Kopsiaftis wrote:
> ok i appreciate the input, but for now i will stick with the comet
> approach because i read that websocket for tomcat 7 is still
> experimental and i already built a lot of logic around the comet
> approach. does anyone know the answer to my original question?
As long as one servlet was called long-enough before the second one
that the session could be created and its id returned to the client
*and* sessions are supported, then yes, both servlets should have
access to the same session data.
It should have been easy to test this on your own ...
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlADHvsACgkQ9CaO5/Lv0PCwaACfej2clhjZIZ+UpF2CpNCoOtIX
HvUAniuzrjEf7AakeL6ONaIN736TImlr
=1ZqX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session id
Posted by Elias Kopsiaftis <ye...@gmail.com>.
ok i appreciate the input, but for now i will stick with the comet approach
because i read that websocket for tomcat 7 is still experimental and i
already built a lot of logic around the comet approach. does anyone know
the answer to my original question?
On Sat, Jul 14, 2012 at 1:07 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> André,
>
> On Jul 14, 2012, at 6:03, André Warnier <aw...@ice-sa.com> wrote:
>
> > Elias Kopsiaftis wrote:
> >> 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.
> >
> > Isn't this just the kind of thing that "websocket(s)" is supposed to be
> made for ?
>
> Comet is basically a precursor to Websocket: the ideas are vaguely the
> same and the use cases are nearly identical.
>
> Elias, if I were you, I would focus on Websocket moving forward... Comet
> is going to see less and less action (globally, not just in Tomcat) a time
> goes on.
>
> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: tomcat session id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
André,
On Jul 14, 2012, at 6:03, André Warnier <aw...@ice-sa.com> wrote:
> Elias Kopsiaftis wrote:
>> 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.
>
> Isn't this just the kind of thing that "websocket(s)" is supposed to be made for ?
Comet is basically a precursor to Websocket: the ideas are vaguely the same and the use cases are nearly identical.
Elias, if I were you, I would focus on Websocket moving forward... Comet is going to see less and less action (globally, not just in Tomcat) a time goes on.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session id
Posted by André Warnier <aw...@ice-sa.com>.
Elias Kopsiaftis wrote:
> 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.
Isn't this just the kind of thing that "websocket(s)" is supposed to be made for ?
You may want at least to look it up :
http://en.wikipedia.org/wiki/WebSocket
I also think that I remember a discussion a couple of days/weeks ago on this list about
it. You may also want to check the list archives.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: tomcat session id
Posted by Elias Kopsiaftis <ye...@gmail.com>.
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 <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAA00MACgkQ9CaO5/Lv0PDz5ACePY07/LBELtlspcvC2U+k0hoF
> oSgAnieuXC7721SMfwUzD0gWfZHaFwaB
> =T9FG
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: tomcat session id
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAA00MACgkQ9CaO5/Lv0PDz5ACePY07/LBELtlspcvC2U+k0hoF
oSgAnieuXC7721SMfwUzD0gWfZHaFwaB
=T9FG
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org