Ok, I'll provide you with that information (logs of apache, tomcat) and
look into it myself.
 
Since the difference between tomcat and  apache is the HTTP protocol
(1.0 vs 1.1) isn't the problem possibly due to the fact that we're using
special
pragmas for IE 6 to disable the caching which are different for both
protocols.
 
we use for each page, pushed from the server to the client:
 
   // Set to expire far in the past.
    httpServletResponse.setHeader("Expires", "Sat, 6 May 1995 12:00:00
GMT");
 
   // Set standard HTTP/1.1 no-cache headers.
    httpServletResponse.setHeader("Cache-Control","no-store, no-cache,
must-revalidate");
 
    // Set IE extended HTTP/1.1 no-cache headers (use addHeader).
    httpServletResponse.addHeader("Cache-Control", "post-check=0,
pre-check=0");
 
    // Set standard HTTP/1.0 no-cache header.
    httpServletResponse.setHeader("Pragma", "no-cache");

 
the special pragmas for http 1.1 could they be causing the "freezing"
effect of the browser using Apache?
 
thanks
Dirk

        -----Oorspronkelijk bericht----- 
        Van: Bill Barker 
        Verzonden: za 22/05/2004 23:50 
        Aan: [EMAIL PROTECTED] 
        CC: 
        Onderwerp: Re: apache -tomcat problem
        
        

        I think that this is the first time I've ever heard that the
3.3.1a
        stand-alone connector worked better than the AJP13 connector
;-).
        
        There is a session race-condition bug in 3.3.1a (BZ #15894) that
is fixed in
        3.3.2.  It is possible that this is the real problem you are
seeing, and it
        is only showing up with the AJP13 connector because you are
hitting Tomcat
        harder in that configuration.  However, I'm just guessing here
:).
        
        Otherwise, you'll need to provide more information for anyone to
have a shot
        at figuring out the problem.  This would include things like:
        1) are the broken requests reaching Apache? (from the Apache
access logs)
        2) are the broken requests reaching Tomcat? (enable the acces
log on Tomcat,
        mod_jk logs).
        3) is the session cookie reaching Tomcat (set 'debug="1"' on the
SessionID
        element in server.xml).
        
        
        "Dirk Slootmaekers" <[EMAIL PROTECTED]> wrote in message
        
news:[EMAIL PROTECTED]
        > hello All,
        >
        > We've developped a J2EE web based application, using Tomcat as
a
        > application container.
        > When we only work on tomcat, the application works fine. If we
add the
        > apache web server, for performance improvement, the
application becomes
        > unstable.
        > After a while the session is apparently thrown away, so what
ever action
        > you do in the browser it is ignored ea not excuted. It is not
that all
        > the users suffer from this at once, but some of the users
(after a while
        > working with the application) are not responding anymore.
        >
        > We're using tomcat 3.3.1a, with Apache 2.0.46 (with the mod_jk
dll for
        > 2.0.46)
        >
        > with the following settings in the httpd.conf
        > MaxKeepAliveRequest = 0
        > KeepAliveTimeOut = 100
        > ThreadsPerChild = 1024
        > MaxRequestsPerChild = 0
        >
        >
        > we also use pushlets to realtime publish events to our
toolbar.
        >
        > can somebody assist us in this issue? since we really have no
clue why
        > the application is working perfectly with tomcat standalone,
but when we
        > add the apache webserver it freezes sessions after a while?
        >
        > is it possible that this has anything to do with the
window.open command
        > getting fired to often?
        >
        > if somebody could help me?
        >
        > thanks
        > Dirk
        >
        >
        
        
        
        
        
---------------------------------------------------------------------
        To unsubscribe, e-mail:
[EMAIL PROTECTED]
        For additional commands, e-mail:
[EMAIL PROTECTED]
        
        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to