Re: tomcat session id
2012/7/15 Elias Kopsiaftis : > 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
-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
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 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
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 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
André, On Jul 14, 2012, at 6:03, André Warnier 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
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
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 > >
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: Fwd: Tomcat Session Id generation Overriding!!
On 09/01/2010 11:01, Arnab Ghosh wrote: > Dear Friends, > > Tomcat is using ManagerBase generateSessionId() to generate session Id. But > I want a generation mechnism where each sessionId will be unique in whole > tomcat. Right now it is unique in a single context. But I want uniqueness > will be among all context running under the tomcat. How can I do that (In a > easieast way)?? Do you understand what the odds are of generating a duplicated session? Assuming the random number generator is a good one, if you had one million current sessions in Tomcat, the odds of the next session being a duplicate are one in 3.4E32. If you were generating a thousand new sessions every second you would see a duplicate on average every 1.1E22 years. Even if the random number generator was terrible (it isn't) any only generated 128 bits of randomness rather than 256 you would still only see a duplicate on average every 580 years. Even if my maths is off by a few orders of magnitude, I really don't think this is an issue to worry about. > Still now I have written a class which has extended the > org.apache.session.standardManager class. Then I have changed the code > slightly. But I don't know whether any sideeffect will be there or not?? It won't work in a clustered environment. Breaking scalability in this way is a much bigger issue than the very rare chance of a duplicated session. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fwd: Tomcat Session Id generation Overriding!!
Dear Friends,
Tomcat is using ManagerBase generateSessionId() to generate session Id. But
I want a generation mechnism where each sessionId will be unique in whole
tomcat. Right now it is unique in a single context. But I want uniqueness
will be among all context running under the tomcat. How can I do that (In a
easieast way)??
Still now I have written a class which has extended the
org.apache.session.standardManager class. Then I have changed the code
slightly. But I don't know whether any sideeffect will be there or not??
Please look on my
code
package com.myproject.session;
import java.util.HashSet;
import java.util.Set;
import org.apache.catalina.Session;
import org.apache.catalina.session.StandardManager;
public class MySessionManager extends StandardManager {
public static Set unquieSessionIdset = new HashSet();
@Override
public void remove(Session session) {
unquieSessionIdset.remove(session.getIdInternal());
super.remove(session);
}
@Override
protected synchronized String generateSessionId() {
byte random[] = new byte[16];
String jvmRoute = getJvmRoute();
String result = null;
// Render the result as a String of hexadecimal digits
StringBuffer buffer = new StringBuffer();
do {
int resultLenBytes = 0;
if (result != null) {
buffer = new StringBuffer();
duplicates++;
}
while (resultLenBytes < this.sessionIdLength) {
getRandomBytes(random);
random = getDigest().digest(random);
for (int j = 0;
j < random.length && resultLenBytes < this.sessionIdLength;
j++) {
byte b1 = (byte) ((random[j] & 0xf0) >> 4);
byte b2 = (byte) (random[j] & 0x0f);
if (b1 < 10)
buffer.append((char) ('0' + b1));
else
buffer.append((char) ('A' + (b1 - 10)));
if (b2 < 10)
buffer.append((char) ('0' + b2));
else
buffer.append((char) ('A' + (b2 - 10)));
resultLenBytes++;
}
}
if (jvmRoute != null) {
buffer.append('.').append(jvmRoute);
}
result = buffer.toString();
} while (sessions.containsKey(result) ||
!unquieSessionIdset.add(result));
return (result);
}
}
Can You please tell me whether it will have any other problem or not?? Or
can you give any alternative solution??
Actually I kept the existing code. With that I addeda a static set. And I am
keeping the generated session in set also. While generating Id I am trying
to add that to set. if successfully added then I will return that key.
Thanks
Arnab Ghosh
