Hi Singh,
Thanks for your explanations.
The polling uses the following code:
URL url = new
URL("http://139.10.69.132:8080/swam/pollingmonitor");
BufferedReader in = new BufferedReader(new
InputStreamReader(url.openStream()));
String line;
PolledServer readServer, knownServer;
while ((line = in.readLine()) != null)
{
// Construct the received server data
readServer = new PolledServer(line);
etc...........
I tested it: the applet really sends the sessionId-cookie.
What I still don't understand:
The polled servlet never calls anything of the session: it does not call
request.getSession() whatsoever.
So why is this polling "click" taken into account and stops the session from expiring?
Does the sessionAPI come into action automatically?
If yes at which stage of request processing?
What do you think of following solution:
servlet side: somehow delete the cookie with the sessionId in the request in routine
doPost(),doGet()? Or is this already too late?
applet side: somehow prevent the cookie from being sent in the request?
Doe somebody else have comments?
> -----Original Message-----
> From: Gokul Singh [SMTP:[EMAIL PROTECTED]]
> Sent: mercredi 7 mars 2001 06:12
> To: [EMAIL PROTECTED]
> Subject: Re: sessionId used by applet to poll other servlet within same JVM: d
> isturbs sessions MaxInactiveInterval
>
> ----- Original Message -----
> From: "Bartsch Axel" <[EMAIL PROTECTED]>
>
> > The strange thing now is the session never ends? It seems that this
> polling keeps the session running: the polling is interpreted as user
> action.
>
> The polling *is* a user action. Only in your case the HTTP requests are
> being generated by the applets which is no different from a user initiated
> request from the Servlet Containers view point.
>
>
> > Now why does this happen and want could be done to prevent it?
>
> The cookies are being passed back to the container to the container which
> then recognizes this request to be part of a session. So the session does
> not get timed out. To prevent the same you can turn off the cookies for
> session management (if your container supports it) and use URL rewriting for
> session management. Another way to do this would be the path to which the
> session cookies are returned, but again it is a very container specific
> thing.(iPlanet 6.0 app server supports it, Tomcat does not, iPlanet 4.1 web
> server does not......)
> I am not sure how can one do it with cookies being used for session
> management other than to establish raw socket connection for the polling or
> wrapping ones own session mgmt aroung the servlet's session API .
>
>
> > Is the sessionId cookie set within the applet??
>
> I think you are using the URLConnection to do the polling. When you use this
> class, then it uses the browser API(in applets) to make the connection and
> this results in session cookies being sent to server. I am not sure, but may
> be this behaviour can be overriden in the plugin control.
>
>
> > Why does servlet2 within the same JVM interpret this session? It was
> created for servlet1. (sometimes sessions should be shared between two
> servlets: but not here).
> > And even if servlet1 woyld be polled this should not happen!
>
> Session are *not* per servlet concept. They are a *per client* concept to
> maintain state across multiple requests from the same client as the HTTP
> protocol itself is stateless. If you are not getting what I am saying here,
> you may want to do some reading [1,2] on session management.
>
>
> Regds,
> Gokul
>
> [1] http://java.sun.com/docs/books/tutorial/servlets/client-state/index.html
> [2] I would recommend Jason Hunter's Java Servlet Programming chapter 7.
>
>
> >
> > Axel Lannion/France
> >
>
> ___________________________________________________________________________>
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
