How to resolve 403 forbidden error in Tomcat level

[jagadish sahu]

Hi Team,

We have tested our application in Apache tomcat 9.0.14. It is working as
expected, After upgrading from 9.0.14 to the latest versions it is not
working.

  When we leave the session for 30 mins, we will get some warning like due
to an inactive session, you can click on Ok to continue the session, after
clicking Ok we are getting a 403 error message (attached screenshot for
your reference).

The correct functionality is it should not get any error message, after
clicking waring message it should redirect to login page again, but in the
latest version of tomcat its not working, so we are contacting you people.

Please provide a solution/ workaround for this issue.

Thanks,
Jagadish

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

Re: How to resolve 403 forbidden error in Tomcat level

[Christopher Schultz]

Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
We have tested our application in Apache tomcat 9.0.14. It is working as 
expected, After upgrading from 9.0.14 to the latest versions it is not 
working.


   When we leave the session for 30 mins, we will get some warning like 
due to an inactive session, you can click on Ok to continue the session, 
after clicking Ok we are getting a 403 error message (attached 
screenshot for your reference).


Your screenshot has been stripped from the list. Is this an 
application-generated 403 or one from Tomcat?


The correct functionality is it should not get any error message, after 
clicking waring message it should redirect to login page again, but in 
the latest version of tomcat its not working, so we are contacting you 
people.


Please provide a solution/ workaround for this issue.


What kind of authentication are you using? What kind of login mechanism 
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?


Can you post the relevant parts of your web.xml?

-chris

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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

[Christopher Schultz]

Isaac,

On 8/26/24 13:24, Isaac Klickstein wrote:

What is the "Tomcat Native Client"?


I am using the Tomcat Native software (maybe "client" was wrong) available here 
to build the OpenSSLImplementation:
https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's setenv.sh 
script.


Aah, okay. You are just using libtcnative on the server side. curl is 
the client.



How do you trigger this behavior? Just any request like "curl


I have been using the manager app, something like

curl --cacert  --url 'https://:/manager/text/list' --user robot:robotpw

but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR and the 
sslImplementationName JSSE/OpenSSL

NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good


That's interesting. When using APR+OpenSSL, the Tomcat code is entirely 
responsible for the connection management (e.g. socket, buffers, etc.) 
and the crypto (using OpenSSL, of course).


When using NIO+OpenSSL, Java is responsible for the connection 
management AND the orchestration of the use of the cryptographic module. 
The use of OpenSSL versus some other cryptographic module (e.g. built-in 
JSSE) should not affect whether a close_notify is sent. :/



I have TCP dumps for each of these configurations saved and could upload them 
as well as the configuration of the connectors.


Is a TCP dump required to observe this behavior, or will e.g. curl -vvv 
show it as well?


Is this causing any actual issues in your environment, or are you more 
reporting a spec violation that needs to be cleaned-up. It seems to be 
that if the client asks the server to close the connection, if the 
connection is closed then it's closed whether or not this particular 
message is transmitted before termination of the connection.


-chris


On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz 
 wrote:


Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:


Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8



What is the "Tomcat Native Client"?


I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation sslImplementationName 
using TLSv1.2

When I tcpdump any request to this connector, Tomcat is not returning a 
"close_notify" in response to a client's close_notify, and I cannot figure out 
how to force Tomcat to return a close_notify. This seems to be a violation of the TLS 
protocol which demands both sides issue a close_notify.



Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.


Recreating this situation, as far as I can tell, only requires combining the 
Http11NioProtocol with the OpenSSLImplementation (Tomcat9 or Tomcat10, TLSv1.2 
or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, all exhibit this behavior).



How do you trigger this behavior? Just any request like "curl
https://example.com/"; ?


Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a close_notify 
by the server in response to the client's close_notify.

Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a close_notify 
in response to a client's close_notify.

I have run out of ideas, googling this behavior has turned up nothing related 
to Tomcat (although there does appear to be a similar behavior noticed in Netty 
also using the OpenSSLEngine https://github.com/netty/netty/issues/6167)

Any help would be greatly appreciated, I am happy to send along any other 
information that would be informational for diagnostics



So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

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


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



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

Understanding ResorceLink property inheritance

[Marcelo de Sena Lacerda]

Understanding ResorceLink property inheritance

My scenario is this, I have several applications running on a tomcat, all of 
them access the same database I want them to be inside the same pool so the 
number of connections oppened can be sensibly managed using the same 
parameters. All of that works as of now.

Additionally I also want them to connect to the database using different users 
so that's easier to identify which application is running which processes in 
the database.

My understanding is that I could do that with setting a Resource in my 
server.xml with all the pool configuration parameters set and a ResourceLink in 
the context.xml of the application with only the username and password set.

That more or less works. Indeed if setup the scenario described in the above 
paragraph I can set a different username and password for the Resource in the  
ResourceLink, however it seems that tomcat "forgets" every other parameter of 
the Resource driverClass,url, and, more importantly maxActive, maxIdle, 
initialSize all gets "forgotten" by tomcat.

Why is that happening?


I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.

This is the ResourceLink that inherits all parameters from server.xml:



And this is one that forgets all parent parameters:

Re: Tomcat takes over 1 minute to stop

[Mark Thomas]

On 27/08/2024 21:41, Christopher Schultz wrote:

Quoc,

On 8/27/24 14:58, Quoc Nguyen wrote:

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used    Time Taken to stop

Apache Tomcat/8.5.66    ~ 9 seconds
Apache Tomcat/9.0.1    ~ 9 seconds
Apache Tomcat/9.0.10    ~ 9 seconds
Apache Tomcat/9.0.13    ~ 9 seconds
Apache Tomcat/9.0.14    ~ 1 min 3 secs
Apache Tomcat/9.0.16    ~ 1 min 3 secs
Apache Tomcat/9.0.20    ~ 1 min 3 secs
Apache Tomcat/9.0.30    ~ 1 min 3 secs
Apache Tomcat/9.0.40    ~ 1 min 3 secs
Apache Tomcat/9.0.44    ~ 1 min 3 secs
Apache Tomcat/9.0.46    ~ 1 min 3 secs
Apache Tomcat/9.0.75    ~ 1 min 3 secs
Apache Tomcat/9.0.89    ~ 1 min 3 secs
Apache Tomcat/9.0.90    ~ 1 min 3 secs
Apache Tomcat/9.0.93    ~ 1 min 3 secs

 From Tomcat changelog 
(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): Version 9.0.14 "Add a scheduled executor to the Server, which can be used to process periodic utility tasks. The utility threads are non daemon by default. (remm)", which has the default timeout of 60s for procrun.


Workaround: to reduce the default timeout of 60s, I can supply it via 
Tomcat Monitor (Tomcat9w.exe) or while creating the Windows service.


This workaround has worked up to version 9.0.89 and has stopped for 
version 9.0.90 and above. The difference is version 9.0.89 and lower 
uses Apache Commons Daemon procrun (1.3.x.0 64-bit)  whereas version 
9.0.90 and above uses Apache Commons Daemon procrun (1.4.0.0 64-bit).


Questions:

1) Am I on the right rack with this procrun timeout?


No.



2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun 
(1.3.x.0 64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) 
cause the supplied timeout to be ignored so that the default of 60s is 
always in effect?


2) If #2 is yes, is there a workaround while waiting for a fix or must 
wait for a fix?


Since this symptom lasts for more than a minute and (I assume) is 
trivially reproducible, you should take a thread dump to find out what 
Tomcat is doing during that time.


It is unlikely to be Tomcat. A clean Tomcat 9.0.93 install stops in 
around 1 second. It will be something the application is doing. Probably 
with a non-daemon thread or maybe a long running request.


+1 to the thread dump suggestion.

Mark

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

Re: Understanding ResorceLink property inheritance

[Mark Thomas]

On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:

Understanding ResorceLink property inheritance

My scenario is this, I have several applications running on a tomcat, all of 
them access the same database I want them to be inside the same pool so the 
number of connections oppened can be sensibly managed using the same 
parameters. All of that works as of now.

Additionally I also want them to connect to the database using different users 
so that's easier to identify which application is running which processes in 
the database.

My understanding is that I could do that with setting a Resource in my 
server.xml with all the pool configuration parameters set and a ResourceLink in 
the context.xml of the application with only the username and password set.


Yes, but only under specific circumstances.

https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links


That more or less works. Indeed if setup the scenario described in the above paragraph I can set a 
different username and password for the Resource in the  ResourceLink, however it seems that tomcat 
"forgets" every other parameter of the Resource driverClass,url, and, more importantly 
maxActive, maxIdle, initialSize all gets "forgotten" by tomcat.

Why is that happening?


We need to see the resource definition in server.xml as there may be 
changes required there as well.



I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.

This is the ResourceLink that inherits all parameters from server.xml:



And this is one that forgets all parent parameters:




Wrong factory.
driverClassName is not a valid attribute for a ResourceLink
url is not a valid attribute for a ResourceLink

Mark


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

Re: mod_jk retry continuing existing stream?

[Mark Thomas]

On 12/08/2024 19:54, Holle, Jess wrote:

I have mod_jk load balancing over several back-end Java processes which embed 
Tomcat.

When I Ctrl-C one of those processes, a server-sent-event response stream 
(which has already sent a number of events) does not end from a client 
perspective.  Rather the original request is retried against the next server 
and its response is simply added to the original stream from the client's 
perspective.

That is just plain weird - and doesn't make sense to me at all in terms of 
retry handling.


What have you got set for recovery_options on those workers?

If it is the default 0, you probably want to set it to 2.

I see what you mean in term so of the default behaviour being weird. I 
can see how the default makes sense for relatively quick GET requests. 
SSE is different. Hopefully, switching to 2 from the default should fix it.


Mark

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

Re: Suggestion: Maven repository for Tomcat native library

[Mark Thomas]

On 27/08/2024 18:41, Mark Thomas wrote:

Please open a Bugzilla issue for this request so that it does not get lost.


https://bz.apache.org/bugzilla/show_bug.cgi?id=69299

Mark


On 09/08/2024 10:56, Harri Pesonen wrote:
Hello, currently Tomcat native library needs to be downloaded manually 
from here:


https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we 
could upgrade the version easier using Maven scripts.

Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is 
possible to upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and 
native .dll in separate artifact:


https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?

-Harri



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



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

RE: Understanding ResorceLink property inheritance

[Marcelo de Sena Lacerda]

The resource definition in server.xml

...
  
...

...


  *
Wrong factory.
  *
driverClassName is not a valid attribute for a ResourceLink
  *
url is not a valid attribute for a ResourceLink

>From reading the documentation that was also my initial thought, however if I 
>write my ResourceLink like this:




I get the following error:

javax.naming.NamingException: Unexpected exception resolving reference [Root 
exception is java.sql.SQLException: The url cannot be null

When my code tries to obtain the DataSource from the context:

DataSource ds = (DataSource)envContext.lookup("jdbc/mydatabase");

De: Mark Thomas 
Enviado: quinta-feira, 29 de agosto de 2024 10:30
Para: users@tomcat.apache.org 
Assunto: Re: Understanding ResorceLink property inheritance

On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:
> Understanding ResorceLink property inheritance
>
> My scenario is this, I have several applications running on a tomcat, all of 
> them access the same database I want them to be inside the same pool so the 
> number of connections oppened can be sensibly managed using the same 
> parameters. All of that works as of now.
>
> Additionally I also want them to connect to the database using different 
> users so that's easier to identify which application is running which 
> processes in the database.
>
> My understanding is that I could do that with setting a Resource in my 
> server.xml with all the pool configuration parameters set and a ResourceLink 
> in the context.xml of the application with only the username and password set.

Yes, but only under specific circumstances.

https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links

> That more or less works. Indeed if setup the scenario described in the above 
> paragraph I can set a different username and password for the Resource in the 
>  ResourceLink, however it seems that tomcat "forgets" every other parameter 
> of the Resource driverClass,url, and, more importantly maxActive, maxIdle, 
> initialSize all gets "forgotten" by tomcat.
>
> Why is that happening?

We need to see the resource definition in server.xml as there may be
changes required there as well.

> I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.
>
> This is the ResourceLink that inherits all parameters from server.xml:
>
>   name="jdbc/mydatabase"
>  global="jdbc/mydatabase"
>  type="javax.sql.DataSource"
> />
>
> And this is one that forgets all parent parameters:
>
>   name="jdbc/mydatabase"
>  global="jdbc/mydatabase"
>  type="javax.sql.DataSource"
>  driverClassName="..."
>  url="..."
>  username="..."
>  password="..."
>  factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> />

Wrong factory.
driverClassName is not a valid attribute for a ResourceLink
url is not a valid attribute for a ResourceLink

Mark


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

Re: How to resolve 403 forbidden error in Tomcat level

[jagadish sahu]

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is working
as expected in Tomcat 9.0.14.

After upgrading to latest version Tomcat,we have been facing this
issue(Error communicating with web server status:403)

Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish



On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Jagdesh,
>
> On 8/29/24 06:29, jagadish sahu wrote:
> > We have tested our application in Apache tomcat 9.0.14. It is working as
> > expected, After upgrading from 9.0.14 to the latest versions it is not
> > working.
> >
> >When we leave the session for 30 mins, we will get some warning like
> > due to an inactive session, you can click on Ok to continue the session,
> > after clicking Ok we are getting a 403 error message (attached
> > screenshot for your reference).
>
> Your screenshot has been stripped from the list. Is this an
> application-generated 403 or one from Tomcat?
>
> > The correct functionality is it should not get any error message, after
> > clicking waring message it should redirect to login page again, but in
> > the latest version of tomcat its not working, so we are contacting you
> > people.
> >
> > Please provide a solution/ workaround for this issue.
>
> What kind of authentication are you using? What kind of login mechanism
> are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>
> Can you post the relevant parts of your web.xml?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

AW: How to resolve 403 forbidden error in Tomcat level

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Jagadish,

> Von: jagadish sahu  
> Gesendet: Donnerstag, 29. August 2024 17:02
> An: Tomcat Users List ; Christopher Schultz 
> 
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
>
> Hi Team and Christopher,
>
> We have attached a 403 error screenshot with full information.
> The error seems to be generated from Tomcat level.
>
> We don't have any changes in the java code and our application is working as 
> expected in Tomcat 9.0.14.
>
> After upgrading to latest version Tomcat,we have been facing this issue(Error 
> communicating with web server status:403)
>
> Please find attached screenshot for authentication and web.xml.
>
> It would be great help if you provide a solution for this.
>
> Thanks,
> Jagadish

Without internal information how the application works it is probably hard to 
tell.
Can you use the developer console (F12) and track the requests?
Which Urls are called, and which responses do you get?

How does the web.xml look like regarding authentication as Chris requested?


> On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
>  wrote:
> Jagdesh,

> On 8/29/24 06:29, jagadish sahu wrote:
> > We have tested our application in Apache tomcat 9.0.14. It is working as 
> > expected, After upgrading from 9.0.14 to the latest versions it is not 
> > working.
> > 
> >    When we leave the session for 30 mins, we will get some warning like 
> > due to an inactive session, you can click on Ok to continue the session, 
> > after clicking Ok we are getting a 403 error message (attached 
> > screenshot for your reference).
>
> Your screenshot has been stripped from the list. Is this an 
> application-generated 403 or one from Tomcat?
>
> > The correct functionality is it should not get any error message, after 
> > clicking waring message it should redirect to login page again, but in 
> > the latest version of tomcat its not working, so we are contacting you 
> > people.
> > 
> > Please provide a solution/ workaround for this issue.
>
> What kind of authentication are you using? What kind of login mechanism 
> are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>
> Can you post the relevant parts of your web.xml?
>
> -chris
>
> -
> To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:users-h...@tomcat.apache.org

Re: Understanding ResorceLink property inheritance

[Mark Thomas]

On 29/08/2024 15:52, Marcelo de Sena Lacerda wrote:

The resource definition in server.xml

...
   
...
 


OK. The global resource looks good.


...


   *
Wrong factory.
   *
driverClassName is not a valid attribute for a ResourceLink
   *
url is not a valid attribute for a ResourceLink

 From reading the documentation that was also my initial thought, however if I 
write my ResourceLink like this:





The factory should be org.apache.naming.factory.DataSourceLinkFactory in 
the ResoucreLink. Otherwise the above looks OK to me.


(Note: I'm basing this off reading the documentation - I haven't tested 
that it actually works).


Mark




I get the following error:

javax.naming.NamingException: Unexpected exception resolving reference [Root 
exception is java.sql.SQLException: The url cannot be null

When my code tries to obtain the DataSource from the context:

DataSource ds = (DataSource)envContext.lookup("jdbc/mydatabase");

De: Mark Thomas 
Enviado: quinta-feira, 29 de agosto de 2024 10:30
Para: users@tomcat.apache.org 
Assunto: Re: Understanding ResorceLink property inheritance

On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:

Understanding ResorceLink property inheritance

My scenario is this, I have several applications running on a tomcat, all of 
them access the same database I want them to be inside the same pool so the 
number of connections oppened can be sensibly managed using the same 
parameters. All of that works as of now.

Additionally I also want them to connect to the database using different users 
so that's easier to identify which application is running which processes in 
the database.

My understanding is that I could do that with setting a Resource in my 
server.xml with all the pool configuration parameters set and a ResourceLink in 
the context.xml of the application with only the username and password set.


Yes, but only under specific circumstances.

https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links


That more or less works. Indeed if setup the scenario described in the above paragraph I can set a 
different username and password for the Resource in the  ResourceLink, however it seems that tomcat 
"forgets" every other parameter of the Resource driverClass,url, and, more importantly 
maxActive, maxIdle, initialSize all gets "forgotten" by tomcat.

Why is that happening?


We need to see the resource definition in server.xml as there may be
changes required there as well.


I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.

This is the ResourceLink that inherits all parameters from server.xml:



And this is one that forgets all parent parameters:




Wrong factory.
driverClassName is not a valid attribute for a ResourceLink
url is not a valid attribute for a ResourceLink

Mark


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




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

Re: Tomcat takes over 1 minute to stop

[Quoc Nguyen]

Thank you Mr. Thomas !!!

Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x 
versions) stops around 1s. I believe that it is so because it has no managed 
web apps/resources. Just Tomcat itself. I could be wrong.

Yes, I noticed that there are warnings of non-daemon threads that weren't 
stopped in catalina.log.  I read somewhere that they're just warnings; thus 
don't affect this process.

There are no requests running at all while stopping Tomcat. Essentially, 
install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set 
of non-changing web apps and stop Tomcat via Windows service and record the 
stop times.

Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
"DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
signal (maybe after it's done stopping its main stuff), was running for 60s.

That said, there're no explanations for what happened:

a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled 
executor to the Server..", which has default wait time of 60s and forces a 
Timeout in Tomcat9w.exe to get Tomcat stop under 60s.
b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon 
procrun to version 1.4.0.0, which has a default pause of 60s.

More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
(where I noticed the change) in two different boxes.

For version 9.0.90 box: started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.4.0.0 64-bit)
* exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe

[2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
64-bit) started.
[2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
[2024-08-29 13:41:58] [info]  [ 9148] Starting service...
[2024-08-29 13:41:58] [error] [12380] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
[2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 13:42:40] [info]  [11996] Stopping service...
[2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
[2024-08-29 13:44:06] [info]  [13472] Run service finished.
[2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.


For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
Started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.3.4.0 64-bit)
* stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of the 
box)
* the last two log lines of "out of the box" don't appear in the log for 
Timeout being set to 5. Speculation: the process is short-circuited taking into 
account the set Timeout.

The Timeout was set for 5:

[2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
[2024-08-29 14:08:04] [info]  [14356] Starting service...
[2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
[2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:08:47] [info]  [14432] Stopping service...
[2024-08-29 14:08:58] [info]  [14432] Service stop thread completed.


The Timeout was set for 0 (out of the box):

[2024-08-29 14:43:51] [info]  [ 8848] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:43:51] [info]  [ 8848] Running Service 'Tomcat9'...
[2024-08-29 14:43:51] [info]  [ 8796] Starting service...
[2024-08-29 14:43:52] [error] [ 1688] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:43:53] [info]  [ 8796] Service started in 1641 milliseconds.
[2024-08-29 14:44:47] [info]  [ 8848] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:44:47] [info]  [15996] Stopping service...
[2024-08-29 14:45:00] [info]  [15996] Service stop thread completed.
[2024-08-29 14:46:00] [info]  [ 8848] Run service finished.
[2024-08-29 14:46:00] [info]  [ 8848] Apache Commons Daemon procrun finished.


All that said, I believe the procrun version is the difference.

Greatly appreciate your help !!!


From: Mark Thomas 
Sent: Thursday, August 29, 2024 9:22 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat takes over 1 minute to stop

On 27/08/2024 21:41, Christopher Schultz wrote:
> Quoc,
>
> On 8/27/24 14:58, Quoc Nguyen wrote:
>> Apache Tomcat version: 9.0.90 and above
>> OS: Windows Server 2019
>>
>> Tomcat Version UsedTime Taken to stop
>>
>> Apache Tomcat/8.5.66~ 9 seconds
>> Apache Tomcat/9.0.1~ 9 seconds
>> Apache Tomcat/9.0.10~ 9 seconds
>> Apache Tomcat/9.0.13~ 9 seconds
>> Apache Tomcat/9.0.14~ 1 min 3 secs
>> Apach

Tomcat migration tool for .war file going to 10.1x from 9x.

[Mcalexander, Jon J.]

I hate asking this question, but I'm not finding the documentation I'm looking 
for. I remember reading that if you DON'T want to migrate your .war file when 
moving from 9x to 10.1x, you can put the .war file in a different webapps 
directory, but I can't find the name of the alternate webapps directory. Can 
someone point me to that documentation please?

Happy long weekend!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: Tomcat migration tool for .war file going to 10.1x from 9x.

[Chuck Caldarale]

> On Aug 29, 2024, at 14:46, Mcalexander, Jon J. 
>  wrote:
> 
> I hate asking this question, but I'm not finding the documentation I'm 
> looking for. I remember reading that if you DON'T want to migrate your .war 
> file when moving from 9x to 10.1x, you can put the .war file in a different 
> webapps directory, but I can't find the name of the alternate webapps 
> directory. Can someone point me to that documentation please?


I think you’re looking for this:

https://tomcat.apache.org/migration-10.html#Specification_APIs

The section title is perhaps not as comprehensive as it might be…

  - Chuck

RE: Tomcat migration tool for .war file going to 10.1x from 9x.

[Mcalexander, Jon J.]

Thank you

From: Chuck Caldarale 
Sent: Thursday, August 29, 2024 2:57 PM
To: Tomcat Users List 
Subject: Re: Tomcat migration tool for .war file going to 10.1x from 9x.

> On Aug 29, 2024, at 14: 46, Mcalexander, Jon J.  com. INVALID> wrote: > > I hate asking this question, but I'm not finding the 
> documentation I'm looking for. I remember reading that if you DON'T want




> On Aug 29, 2024, at 14:46, Mcalexander, Jon J. 
> mailto:jonmcalexan...@wellsfargo.com.INVALID>>
>  wrote:

>

> I hate asking this question, but I'm not finding the documentation I'm 
> looking for. I remember reading that if you DON'T want to migrate your .war 
> file when moving from 9x to 10.1x, you can put the .war file in a different 
> webapps directory, but I can't find the name of the alternate webapps 
> directory. Can someone point me to that documentation please?





I think you’re looking for this:



https://urldefense.com/v3/__https://tomcat.apache.org/migration-10.html*Specification_APIs__;Iw!!F9svGWnIaVPGSwU!qvgKSl7zLS-oLSYGG8hET1ISl7fhFVr5wbTpfBmBs-_GYVYiRQXQW6rJRdYkcoGKY3j5x6QbRV5tFFDTp2Y5Lw$



The section title is perhaps not as comprehensive as it might be…



  - Chuck

Re: Tomcat takes over 1 minute to stop

[Christopher Schultz]

Quoc,

On 8/29/24 15:23, Quoc Nguyen wrote:

Thank you Mr. Thomas !!!

Yes sir !!! I noticed that a clean Tomcat 9.0.93 install (as with other 9.0.9x 
versions) stops around 1s. I believe that it is so because it has no managed 
web apps/resources. Just Tomcat itself. I could be wrong.

Yes, I noticed that there are warnings of non-daemon threads that weren't 
stopped in catalina.log.  I read somewhere that they're just warnings; thus 
don't affect this process.

There are no requests running at all while stopping Tomcat. Essentially, 
install/deploy different versions (9.0.89, 9.0.9x) of Tomcat with the same set 
of non-changing web apps and stop Tomcat via Windows service and record the 
stop times.

Yes, I took the thread dumps while stopping version 9.0.90. There is a thread 
"DestroyJavaVM" that, after a few seconds after Tomcat receives the shutdown 
signal (maybe after it's done stopping its main stuff), was running for 60s.

That said, there're no explanations for what happened:

a) between version 9.0.13 and 9.0.14 with the introduction of "..scheduled executor 
to the Server..", which has default wait time of 60s and forces a Timeout in 
Tomcat9w.exe to get Tomcat stop under 60s.
b) between version 9.0.89 and 9.0.90 after the upgrade of Apache Commons Daemon 
procrun to version 1.4.0.0, which has a default pause of 60s.

More work/data to confirm: I'm working with Tomcat version 9.0.89 and 9.0.90 
(where I noticed the change) in two different boxes.

For version 9.0.90 box: started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.4.0.0 64-bit)
* exactly 60s wait until finished regardless of the Timeout set in Tomcat9w.exe

[2024-08-29 13:41:58] [info]  [13472] Apache Commons Daemon procrun (1.4.0.0 
64-bit) started.
[2024-08-29 13:41:58] [info]  [13472] Running Service 'Tomcat9'...
[2024-08-29 13:41:58] [info]  [ 9148] Starting service...
[2024-08-29 13:41:58] [error] [12380] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 13:41:59] [info]  [ 9148] Service started in 1636 milliseconds.
[2024-08-29 13:42:40] [info]  [13472] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 13:42:40] [info]  [11996] Stopping service...
[2024-08-29 13:43:06] [info]  [11996] Service stop thread completed.
[2024-08-29 13:44:06] [info]  [13472] Run service finished.
[2024-08-29 13:44:06] [info]  [13472] Apache Commons Daemon procrun finished.


For version 9.0.90 box: switched version 9.0.89 of Tomcat9.exe into this box. 
Started and stopped. Daemon logs below.

Note:

* Apache Commons Daemon procrun (1.3.4.0 64-bit)
* stop time is definitely less than 60s if the Timeout set in Tomcat9w.exe is 
less than 60 and ~63s (or 1 min 3 secs as reported)  when set to 0 (out of the 
box)
* the last two log lines of "out of the box" don't appear in the log for 
Timeout being set to 5. Speculation: the process is short-circuited taking into account 
the set Timeout.

The Timeout was set for 5:

[2024-08-29 14:08:04] [info]  [11012] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:08:04] [info]  [11012] Running Service 'Tomcat9'...
[2024-08-29 14:08:04] [info]  [14356] Starting service...
[2024-08-29 14:08:05] [error] [ 6740] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:08:06] [info]  [14356] Service started in 1648 milliseconds.
[2024-08-29 14:08:47] [info]  [11012] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:08:47] [info]  [14432] Stopping service...
[2024-08-29 14:08:58] [info]  [14432] Service stop thread completed.


The Timeout was set for 0 (out of the box):

[2024-08-29 14:43:51] [info]  [ 8848] Apache Commons Daemon procrun (1.3.4.0 
64-bit) started.
[2024-08-29 14:43:51] [info]  [ 8848] Running Service 'Tomcat9'...
[2024-08-29 14:43:51] [info]  [ 8796] Starting service...
[2024-08-29 14:43:52] [error] [ 1688] Could not create instance of 
java/io/FileOutputStream
[2024-08-29 14:43:53] [info]  [ 8796] Service started in 1641 milliseconds.
[2024-08-29 14:44:47] [info]  [ 8848] Service SERVICE_CONTROL_STOP signalled.
[2024-08-29 14:44:47] [info]  [15996] Stopping service...
[2024-08-29 14:45:00] [info]  [15996] Service stop thread completed.
[2024-08-29 14:46:00] [info]  [ 8848] Run service finished.
[2024-08-29 14:46:00] [info]  [ 8848] Apache Commons Daemon procrun finished.


All that said, I believe the procrun version is the difference.

Greatly appreciate your help !!!


The non-daemon threads are highly likely to be involved in this. I'm not 
sure why you weren't having any issues in previous versions of Tomcat.


You should definitely try to fix those whether or not they are related 
to this 1-minute stop.


What "timeout" are you setting in Tomcat9w.exe?

-chris

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

Re: How to resolve 403 forbidden error in Tomcat level

[Christopher Schultz]

Jadgish,

This list does not accept image attachments. We are not seeing what you 
are posting. Please post text-only.


-chris

On 8/29/24 11:01, jagadish sahu wrote:

Hi Team and Christopher,

We have attached a 403 error screenshot with full information.
The error seems to be generated from Tomcat level.

We don't have any changes in the java code and our application is 
working as expected in Tomcat 9.0.14.


After upgrading to latest version Tomcat,we have been facing this 
issue(Error communicating with web server status:403)


Please find attached screenshot for authentication and web.xml.

It would be great help if you provide a solution for this.

Thanks,
Jagadish



On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
mailto:ch...@christopherschultz.net>> wrote:


Jagdesh,

On 8/29/24 06:29, jagadish sahu wrote:
 > We have tested our application in Apache tomcat 9.0.14. It is
working as
 > expected, After upgrading from 9.0.14 to the latest versions it
is not
 > working.
 >
 >    When we leave the session for 30 mins, we will get some
warning like
 > due to an inactive session, you can click on Ok to continue the
session,
 > after clicking Ok we are getting a 403 error message (attached
 > screenshot for your reference).

Your screenshot has been stripped from the list. Is this an
application-generated 403 or one from Tomcat?

 > The correct functionality is it should not get any error message,
after
 > clicking waring message it should redirect to login page again,
but in
 > the latest version of tomcat its not working, so we are
contacting you
 > people.
 >
 > Please provide a solution/ workaround for this issue.

What kind of authentication are you using? What kind of login mechanism
are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?

Can you post the relevant parts of your web.xml?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

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




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


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