Re: When does tomcat 7.0.76 determine it needs to redeploy the war file?

2021-07-14 Thread Brian Wolfe
Thx mark. that was helpful

On Mon, Jul 12, 2021 at 2:38 PM Mark Thomas  wrote:

> On 12/07/2021 19:21, Brian Wolfe wrote:
> > Hi,
> > As the subject asks, when does tomcat decide that it needs to redeploy
> the
> > war file? I know the usual one where the app folder does not exist.
> >
> > Basically I have an app where some changes were made to the webapp
> folder,
> > but were not made in the accompanied war file. Then we updated the
> web.xml
> > and restarted tomcat. some of those changes were overwritten with older
> > versions. So we think tomcat may have redeployed on startup.
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
Thanks,
Brian Wolfe
https://www.linkedin.com/in/brian-wolfe-3136425a/


Re: Internals of setMaxInactiveInterval

2021-07-14 Thread Christopher Schultz

Saurav,

On 7/12/21 23:33, Saurav Sarkar wrote:

Hi All,

I would like to understand the internals of Session~setMaxInactiveInterval
in tomcat.

I understand that if HTTP requests are not received within the said
interval then the session is cleared. All the objects belonging to the
session will be gone.

Does that also mean that the existing requests part of the session will be
terminated ?

I have a scenario for large file transfer to happen over a single request.

So if one request (A) is long running and there are no other requests sent
within the time interval.

Then will the request A will be terminated and subsequent requests even if
with valid cookie will not be part of the same session ? Or will the
ongoing request's fate is determined by other timeouts like read time out?


Requests that were related to a certain session will never be terminated 
due to a session state-change.


But, if your servlet works like this, you may have a problem:

doGet() {
  HttpSession session = request.getSession(true);

  // take 45 minutes to stream data to the client

  session.setAttribute("foo", "bar");
}

My recommendation would be to do all of your session-work "up front" 
(before the long data-stream) and not touch the session after the 
download completes.


This may not meet your requirements, but if you are doing extraordinary 
things, you may require extraordinary workarounds :)


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org