Re: tomcat session id
2012/7/15 Elias Kopsiaftis yemi...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
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 ch...@christopherschultz.net wrote: André, On Jul 14, 2012, at 6:03, André Warnier a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
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 ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
André, On Jul 14, 2012, at 6:03, André Warnier a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat session id
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 ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
