Tomcat, Struts og jsessionid

Hmm, jeg bruger et UrlRewriteFilter istedet for mod_rewrite i Apache: http://tuckey.org/urlrewrite/
Men det har vel ikke noget med sagen at gøre ...

arne_v, har du haft dette problem med Tomcat/Struts? Hjælp!

Jeg så godt spørgsmålet.

Men jeg er ret blank.

Jeg har ikke set noget tilsvarende.

Og jeg har heller ikke rigtigt noget godt bud på hvad som kunne forårsage det.

Du har checket session timeout.

Jeg formoder også at du har checket koden for session invalidate.

Ja, men jeg har ikke jad'et UrlRewriteFilter'et og kigget efter invalidate der ... man kan måske sætte en listener på sessionen og finde ud af hvem der kalder invalidate?

Det lyder som en mulighed

import javax.servlet.http.*;

/**************************************************************
*
* >>>>>>>> DO NOT RUN THIS CODE IN PRODUCTION <<<<<<<<
*
*************************************************************/
public class SessionWatchDog implements HttpSessionListener {
    public void sessionCreated(HttpSessionEvent se) {
    }
    public void sessionDestroyed(HttpSessionEvent se) {
        throw new RuntimeException("Der er en som invalidater");
    }
}

ser ihvertfald ud til at virke hos mig

Hmm, sessionen bliver ikke destrueret - der oprettes blot en ny til den samme bruger ... hmmm

Mon det er HttpServletRequest.getSession() der glemmer at requestet er med i sessionen...

Ja, det er mit eget UserFilter, der opretter nye sessioner midt i det hele - ved at kalde HttpServletRequest.getSession()

Uhyggeligt - dvs. getSession( false); vil returnere null

getSession() bør returnere den eksisterende session hvis en sådan eksisterer
og kun create ne ny hvis ikke.

Fra docs:

getSession

public HttpSession getSession()

    Returns the current session associated with this request, or if the request does not have a session, creates one.

    Returns:
        the HttpSession associated with this request
    See Also:
        getSession(boolean)

Ja, Arne - jeg har også læst javadoc'en. På en eller anden mystisk måde bliver sessionen de-associeret fra request'ene - den bliver ikke destrueret - og en ny session oprettes til brugerens request - sker ca. hver 4.-5. request...

Den må holde op med at sende Cookie med på et tidspunkt.

Der finde et fremragende tool i Apache Axis (som også kommer med
Borland JBuilder Enterprise): TCPMon.

Hvis du kører:

browser-------(port 8082)->TCPMon------(port 8080)->Tomcat

så kan du se hvad der bliver sendt.

Eksempel
--------

første request (ingen cookie):

GET /test/invalidate.jsp HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 127.0.0.1
Connection: Keep-Alive

første svar (med set cookie):

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=3A1E4E77B7EB8259C2F366728D74E951; Path=/test
Content-Type: text/html
Content-Length: 13
Date: Wed, 27 Oct 2004 20:48:59 GMT
Server: Apache-Coyote/1.1

Det virker.

andet request (med cookie):

GET /test/invalidate.jsp HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; .NET CLR 1.1.4322)
Host: localhost:8082
Connection: Keep-Alive
Cookie: JSESSIONID=3A1E4E77B7EB8259C2F366728D74E951

andet svar:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 13
Date: Wed, 27 Oct 2004 20:49:15 GMT
Server: Apache-Coyote/1.1

Det virker.

Det løser jo ikke noget problem.

Men du kan følge med i hvad der sker !

Pissegodt arne - jeg prøver det. Vi har faktisk axis.jar'en med i projektet, men kun for at bruge 2 klasser: Base64 og den fantastiske XMLUtils  :)

Så Arne ... TCPMon hjalp mig med at finde problemet. Der blev sendt flere sæt af mine cookies - pga. jeg ikke satte path'en til "/". I min C:\Documents and Settings\[Bruger]\Cookies kunne jeg se at flere .txt-filer blev modificeret - én for hver path og til sidst var der simpelthen ikke plads til jsessionid i HTTP Request Headeren.
Jeg har altid troet at en cookie tilhørte et domæne, og dermed slut. Det med path kom helt bag på mig ... satans cookies. Nå, men jeg håber at andre, der får dette suspekte problem finder denne diskussion.

Det med de flere sæt cookies blev først et problem efter jeg indførte UrlRewriteFilter - hvor URL'ernes request-parametre bliver lagt ind som sti-elementer istedet:
  search.do?country=DK  -> search/DK

Arne, jeg vil gerne tildele dig point'ene, for uden TCPMon havde jeg ikke fundet fejlen.

:-)

Har du ikke nogen kommentarer til mit problem? Det ligner jo faktisk lidt af en rookie-ting, nu hvor jeg kigger på det igen ... :-[

Jeg synes absolut ikke at det var en "nem sag".

Jeg havde aldrig gættet på "cookie overflow".

Bagefter er det jo altid nemt.

Det afgørende er imidlertid at man angriber problemerne systematisk og kommer
til bunds i hvad der sker, så viser en løsning sig normalt også.

Jovist, men er de fleste web-udviklere mon ikke klar over, at path-attributten eksisterer i en cookie? Ved siden af domain. Det var derfor jeg kaldte det en rookie-fejl.

Ved jeg ikke - jeg bruger aldrig eksplicitte cookies.

Men uanset hvad, så var sammenhængen mellem symptomet og årsagen ikke klar.

De fleste fejl er ret banale, når man først har identificeret fejlen.

Men det kan sommetider være meget svært at identificere fejlen.