Re: JAVA -tomcat- Request header is too large

[Christopher Schultz]

Mark,

On 12/8/23 06:50, Mark Thomas wrote:

On 08/12/2023 09:27, Ivano Luberti wrote:


Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception 
was raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is 
causing the issue?


You can try enabling debug logging for 
org.apache.coyote.http11.Http11InputBuffer


Are request-ids always allocated, or only if they are "enabled"?

I think adding the request-id to this exception detail message might be 
helpful, even if the request-id hasn't been enabled in the access-log.


WDYT?

-chris

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

Re: [EXT] Re: Datadog _ JMX Integration facing connection issues.

[Christopher Schultz]

Sai Vamsi,

On 12/8/23 00:43, Bodavula, Sai Vamsi Mohan Krishna (TR Technology) wrote:

Hey Christopher.,
Greetings of the day.


   1.
Might I have confused you with posting the arguments directly ., Yeah as i just 
shared you the annotations with comments , to state you the stuff i am using., 
But in my deployment ., I am using them in catalina opts., and trying to call 
them from values.yaml., which looks like this :

  javaVMMemoryArgument: "-Xms2048M -Xmx10240M -XX:+UseStringDeduplication 
-XX:+UseContainerSupport -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.local.only=false 
-Dcom.sun.management.jmxremote.port=49151 
-Djava.rmi.server.hostname=lab1workflow4scalsvc2zus1-service.hqm-lab1.svc.cluster.local 
"

  and I am referring the word "javaVMMemoryArgument" from values yaml and 
calling it in Catalina_opts, so that it would fetch all these annotations as 
mentioned above, during the deployment. This is my deployment part., where I am referring 
to the above values from values.yaml
env:
 - name: CATALINA_OPTS
   value: {{ .Values.deployment.javaVMMemoryArgument }}





   1.
Coming to Process., I have searched for Java process that listens on my 
mentioned port ie., 49151, but none of the process is listening to that process.

I even tried with
root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
grep LISTEN
tcp6   0  0 :::10109:::*LISTEN  
1/java
tcp6   0  0 :::9109 :::*LISTEN  
1/java
root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
more
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
tcp6   0  0 :::10109:::*LISTEN  
1/java
tcp6   0  0 :::9109 :::*LISTEN  
1/java
root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
grep ':443'netstat -tulpn | grep ':443'^C
root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
grep ':49151'
root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/#

which confirms me that , any of the process is being listening on the port 
49151.

   2.
I would like to request you to suggest me with a better approach ., where i am 
missing anything in this process!


Good question. What is pid #1? Do those port numbers make any sense for 
your Tomcat-based service?


Is Tomcat even running? Try 'ps aux | grep catalina' to see if there are 
any. Are you launching Tomcat using catalina.sh / startup.sh or similar? 
Or are you running Tomcat "embedded" within your own application?


-chris

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

Re: 9.0.83 addSslHostConfig JMX Operation Regression (Sample Code Attached)

[Christopher Schultz]

Daniel,

On 12/7/23 13:25, Daniel Skiles wrote:

All,
I've been doing some testing, and I'm pretty sure the addSslHostConfig 
operation on ProtocolHandler is busted in 9.0.83.


In versions prior to 9.0.82, you can call the operation with a single 
argument of type SSLHostConfig.


In 9.0.82, that contract seems to have been broken, and you had to call 
it with two arguments:  an SSLHostConfig and a boolean.


In 9.0.83, it seems as though both operations are present, but which one 
is actually accessible at runtime is non-deterministic.


This behavior presents through a direct invoke(...) call and via a JMX 
Proxy object instantiated through JMX.newMBeanProxy.


I have attached a sample file that reproduces the behavior (sometimes, 
as it is nondeterministic).


Is this a bug, or am I simply using the available feature incorrectly?

If it is the former, how do I formally report this?  If it is the 
latter, what is the "correct" way to call this operation from JMX?


I think your attachment was stripped. Can it be posted in-line?

-chris

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

Re: (No members active in cluster group) Cannot discover members in cluster using Delta Manager with static membership Unicast

[Manak Bisht]

To use *DeltaManager* with unicast (static membership), the Tomcat 8.5
documentation (https://tomcat.apache.org/tomcat-8.5-doc/config/cluster.html)
states that the channelStartOptions should be equal to *3*. In my original
example, I am using the same value with the *StaticMembershipInterceptor*.

However, the value should be left as the default when using the
*StaticMembershipService* according to the Tomcat 9.0 documentation (
https://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html). This is what
Mark suggested.
> On Fri, Dec 1, 2023 at 2:21 PM Mark Thomas  wrote:
> Why channelStartOptions=3 ? I think this shoudl use the default.

I am still not sure why this distinction exists.

Sincerely
Manak Bisht

Re: Failing to decode the url correctly in tomcat 9.

[Mark Thomas]

On 07/12/2023 22:42, Kalaivani Sengottaiyan wrote:

On Thu, Dec 7, 2023 at 2:34 PM Kalaivani Sengottaiyan <
kalaivani.sengottai...@veeva.com> wrote:


In one of our sample case, this is the url recorded by ngnix

"-" 127.0.0.1 - - [07/Dec/2023:21:59:30 +] "GET
/233.0.100?event=autoproc=F%D0%A9%E4%B8%AD%E7%A2%BA%C5%98%C3%86W%C5%A0d%27%C3%9C%CE%94%C3%A1%21%C3%A8%E3%81%AB%EB%AC%B8%C5%84n%C2%B0%C8%99%D0%B4%C4%BE%C3%B3%C3%A1%C3%A5%E0%B8%84%E0%B9%89%C3%A7%D0%B6%C4%90.zip=1225205368=Name%7C%7C%7CF%D0%A9%E4%B8%AD%E7%A2%BA%C5%98%C3%86W%C5%A0d%27%C3%9C%CE%94%C3%A1%21%C3%A8%E3%81%AB%EB%AC%B8%C5%84n%C2%B0%C8%99%D0%B4%C4%BE%C3%B3%C3%A1%C3%A5%E0%B8%84%E0%B9%89%C3%A7%D0%B6%C4%90%3B%3B%3B
HTTP/1.1" 200 0 "-" "curl/7.79.1"


When the request is received by the application running within tomcat, url
is decoded as


URL=http://localhost:8080/233.0.100?event=autoproc=F
Щ中確ŘÆWŠdÜΔá!èに문ńn°șдľóáåค้çжĐ.zip=1225205368=Name|||FЩ中確ŘÆWŠdÜΔá!èに문ńn°șдľóáåค้çжĐ;;;



If I decode the fn param in the url, it should
be FЩ中確ŘÆWŠd'ÜΔá!èに문ńn°șдľóáåค้çжĐ.zip rather 
FЩ中確ŘÆWŠdÜΔá!èに문ńn°șдľóáåค้çжĐ.zip.
Notice the character after d. It is ' (quote), but tomcat decodes as "39;".
Default LANG is en_US.UTF-8 and connector in conf/server.xml.


why is tomcat not url decoding correctly?


Tomcat is decoding it correctly (I've just tested this with a trivial 
JSP). Something, NOT tomcat, is HTML escaping the value. Generally, you 
want the HTML escpaing because displaying user provided data that 
contains unescaped quotes is likely to expose an XSS vulnerability.


Mark

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

Re: JAVA -tomcat- Request header is too large

[Mark Thomas]

On 08/12/2023 09:27, Ivano Luberti wrote:


Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is causing 
the issue?


You can try enabling debug logging for 
org.apache.coyote.http11.Http11InputBuffer


Mark

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

Re: Virtual Thread with Http11Nio2Protocol

[Nicolas BONAMY]

Thanks!

Nicolas

> Le 8 déc. 2023 à 11:35, Mark Thomas  a écrit :
> 
> On 08/12/2023 09:51, Mark Thomas wrote:
>>> On 08/12/2023 02:49, Han Li wrote:
>>> Hi Nicolas,
>>> 
>>> I took a quick look that Tomcat's VirtualThreadExecutor does not implement 
>>> the ExecutorService interface, which leads to this result.
>>> 
>>> So I think this is a Tomcat bug.
>> +1
> 
> This has been fixed for all versions and will be included in the January 
> release round (unless a regression is found in the December releases and  we 
> need to re-do them).
> 
> 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: Virtual Thread with Http11Nio2Protocol

[Mark Thomas]

On 08/12/2023 09:51, Mark Thomas wrote:

On 08/12/2023 02:49, Han Li wrote:

Hi Nicolas,

I took a quick look that Tomcat's VirtualThreadExecutor does not 
implement the ExecutorService interface, which leads to this result.


So I think this is a Tomcat bug.


+1


This has been fixed for all versions and will be included in the January 
release round (unless a regression is found in the December releases and 
 we need to re-do them).


Mark

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

Re: [EXT] Datadog _ JMX Integration facing connection issues.

[logo]

Sai Vamsi,


> Am 08.12.2023 um 06:43 schrieb Bodavula, Sai Vamsi Mohan Krishna (TR 
> Technology) :
> 
> Hey Christopher.,
> Greetings of the day.
> 
> 
>  1.
> Might I have confused you with posting the arguments directly ., Yeah as i 
> just shared you the annotations with comments , to state you the stuff i am 
> using., But in my deployment ., I am using them in catalina opts., and trying 
> to call them from values.yaml., which looks like this :
> 
> javaVMMemoryArgument: "-Xms2048M -Xmx10240M -XX:+UseStringDeduplication 
> -XX:+UseContainerSupport -Dcom.sun.management.jmxremote 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dcom.sun.management.jmxremote.ssl=false 
> -Dcom.sun.management.jmxremote.local.only=false 
> -Dcom.sun.management.jmxremote.port=49151 
> -Djava.rmi.server.hostname=lab1workflow4scalsvc2zus1-service.hqm-lab1.svc.cluster.local
>  "
> 
>   and I am referring the word "javaVMMemoryArgument" from values yaml and 
> calling it in Catalina_opts, so that it would fetch all these 
> annotations as mentioned above, during the deployment. This is my deployment 
> part., where I am referring to the above values from values.yaml
> env:
>- name: CATALINA_OPTS
>  value: {{ .Values.deployment.javaVMMemoryArgument }}
> 
> 

I compare with my CATALINA_OPTS (and I noticed that some of my options were 
still in JAVA_OPTS boooh!) :

export CATALINA_OPTS="${CATALINA_OPTS} -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=10001 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false  
-Djava.rmi.server.hostname=${HOSTNAME} 
-Dcom.sun.management.jmxremote.local.only=false"

I see all my options in

root@tomcat:/usr/local/tomcat# ps -aef | less

UID  PIDPPID  C STIME TTY  TIME CMD
tomcat 1   0 71 10:42 ?00:04:02 /opt/java/openjdk/bin/java 
-Djava.util.logging.config.file=/opt/apache-tomcat.base/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-agentlib:jdwp=transport=dt_socket,address=0.0.0.0:8000,server=y,suspend=n 
-XX:NativeMemoryTracking=summary -Dhostname= -Djava.awt.headless=true 
-Djavax.net.ssl.trustStore=/opt/apache-tomcat.base/conf/ssl/cacerts.jks 
-Xlog:gc:/opt/apache-tomcat.base/logs/gc.log 
-Djava.security.egd=file:/dev/urandom -Dsun.net.inetaddr.ttl=60 
-Djava.library.path=/usr/local/tomcat/native-jni-lib 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djdk.tls.rejectClientInitiatedRenegotiation=true 
-Djdk.tls.server.enableStatusRequestExtension=true 
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10001 
-Dcom.sun.management.jmxremote.rmi.port=10002 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname= 
-Dcom.sun.management.jmxremote.local.only=false 
-javaagent:/opt/apache-tomcat.base/bin/jmx_prometheus_javaagent-0.12.0.jar=8080:/opt/apache-tomcat.base/bin/tomcat.yaml
 -Djava.net.debug=ssl -XX:+UnlockDiagnosticVMOptions -Dignore.endorsed.dirs= 
-classpath 
/usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar 
-Dcatalina.base=/opt/apache-tomcat.base -Dcatalina.home=/usr/local/tomcat 
-Djava.io.tmpdir=/opt/apache-tomcat.base/temp 
org.apache.catalina.startup.Bootstrap start

Ports are opened

root@tomcat:/usr/local/tomcat# netstat -tulpn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
...
tcp0  0 0.0.0.0:10002   0.0.0.0:*   LISTEN  
-   
tcp0  0 0.0.0.0:10001   0.0.0.0:*   LISTEN  
-   
...
tcp2  0 0.0.0.0:84430.0.0.0:*   LISTEN  
-   
...


jconsole :10001   
  

> JMX connect success



> 
> 
> 
>  1.
> Coming to Process., I have searched for Java process that listens on my 
> mentioned port ie., 49151, but none of the process is listening to that 
> process.
> 
> I even tried with
> root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
> grep LISTEN
> tcp6   0  0 :::10109:::*LISTEN
>   1/java
> tcp6   0  0 :::9109 :::*LISTEN
>   1/java
> root@lab1workflow4scalsvc2zus1-deployment-fd64ff775-cwzn6:/# netstat -tulpn | 
> more
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State 
>   PID/Program name
> tcp6   0  0 :::10109  

Re: Virtual Thread with Http11Nio2Protocol

[Nicolas]

Hi Mark,

Of course I tried with 





To reference the executor in the connector ;)

> Le 8 déc. 2023 à 10:51, Mark Thomas  a écrit :
> 
> On 08/12/2023 02:49, Han Li wrote:
>> Hi Nicolas,
>> I took a quick look that Tomcat's VirtualThreadExecutor does not implement 
>> the ExecutorService interface, which leads to this result.
>> So I think this is a Tomcat bug.
> 
> +1
> 
>>> On Dec 8, 2023, at 03:55, Nicolas BONAMY >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I try to use virtual thread on Apache Tomcat 10.1.16 with this 
>>> configuration on macOS or on Linux:
>>> 
>>>>> class="org.apache.catalina.core.StandardVirtualThreadExecutor"/>
> 
> Note that the above configuration is a) unnecessary and b) doesn't do 
> anything as the following Connector does not reference the Executor
> 
> Mark
> 
> 
>>>>> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>>   connectionTimeout="2"
>>>   redirectPort="8443"
>>>   maxParameterCount="1000"
>>>   useVirtualThreads="true"
>>>   />
>>> But when I make a request, I'm not on a virtual thread : 
>>> Thread[#76,Thread-14,5,main] . I profiled my application too but no virtual 
>>> threads are used.
>>> 
>>> If I use a Http11NioProtocol instead of Http11Nio2Protocol, all requests 
>>> are on virtual thread : 
>>> VirtualThread[#65,http-nio-8080-virt-0]/runnable@ForkJoinPool-1-worker-1
>>> 
>>>>> class="org.apache.catalina.core.StandardVirtualThreadExecutor"/>
>>> 
>>> 
>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>   connectionTimeout="2"
>>>   redirectPort="8443"
>>>   maxParameterCount="1000"
>>>   useVirtualThreads="true"
>>>   />
>>> Http11Nio2Protocol is not working with virtual threads? Has anyone 
>>> encountered this problem before?
>> -
>> 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: Virtual Thread with Http11Nio2Protocol

[Nicolas]

Hi,

When the property "useVirtualThreads" is true, Tomcat create a 
VirtualThreadExecutor 
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1047)
 so a virtual thread is using 
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/threads/VirtualThreadExecutor.java#L38)
 to execute  org.apache.tomcat.util.net.Nio2Endpoint$Nio2Acceptor

but you are right that the AsynchronousServerSocketChannel in Nio2Endpoint is 
not using a VirtualThreadExecutor 
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Nio2Endpoint.java#L120)
 because it is not an ExecutorService but an Executor, so 
AsynchronousServerSocketChannel is using a ThreadPoolExecutor.

A code like this is executing AsynchronousServerSocketChannel with Virtual 
Threads (fast code, so probably bad) : 
if (getExecutor() == null) {
createExecutor();
}
if (getExecutor() instanceof ExecutorService) {
threadGroup = AsynchronousChannelGroup.withThreadPool((ExecutorService) 
getExecutor());
} else if (getExecutor() instanceof VirtualThreadExecutor) {
threadGroup = 
AsynchronousChannelGroup.withThreadPool(Executors.newVirtualThreadPerTaskExecutor());
}

What do you think about this ? It is a bug or a choice of tomcat teams that 
only Nio2Acceptor are on virtual thread and not AsynchronousServerSocketChannel?



To test this, I duplicate the TestMaxConnections test and add 
Assert.assertTrue(tomcat.getConnector().setProperty("useVirtualThreads", 
"true"));

Regards,

Nicolas

> Le 8 déc. 2023 à 03:49, Han Li  a écrit :x
> 
> Hi Nicolas,
> 
> I took a quick look that Tomcat's VirtualThreadExecutor does not implement 
> the ExecutorService interface, which leads to this result.
> 
> So I think this is a Tomcat bug.
> 
> Han
> 
>> On Dec 8, 2023, at 03:55, Nicolas BONAMY  wrote:
>> 
>> Hi,
>> 
>> I try to use virtual thread on Apache Tomcat 10.1.16 with this configuration 
>> on macOS or on Linux:
>> 
>>   > class="org.apache.catalina.core.StandardVirtualThreadExecutor"/>
>> 
>>   > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>>  connectionTimeout="2"
>>  redirectPort="8443"
>>  maxParameterCount="1000"
>>  useVirtualThreads="true"
>>  />
>> But when I make a request, I'm not on a virtual thread : 
>> Thread[#76,Thread-14,5,main] . I profiled my application too but no virtual 
>> threads are used.
>> 
>> If I use a Http11NioProtocol instead of Http11Nio2Protocol, all requests are 
>> on virtual thread : 
>> VirtualThread[#65,http-nio-8080-virt-0]/runnable@ForkJoinPool-1-worker-1
>> 
>>   > class="org.apache.catalina.core.StandardVirtualThreadExecutor"/>
>> 
>> 
>>   > protocol="org.apache.coyote.http11.Http11NioProtocol"
>>  connectionTimeout="2"
>>  redirectPort="8443"
>>  maxParameterCount="1000"
>>  useVirtualThreads="true"
>>  />
>> Http11Nio2Protocol is not working with virtual threads? Has anyone 
>> encountered this problem before?
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Virtual Thread with Http11Nio2Protocol

[Mark Thomas]

On 08/12/2023 02:49, Han Li wrote:

Hi Nicolas,

I took a quick look that Tomcat's VirtualThreadExecutor does not implement the 
ExecutorService interface, which leads to this result.

So I think this is a Tomcat bug.


+1


On Dec 8, 2023, at 03:55, Nicolas BONAMY  wrote:

Hi,

I try to use virtual thread on Apache Tomcat 10.1.16 with this configuration on 
macOS or on Linux:




Note that the above configuration is a) unnecessary and b) doesn't do 
anything as the following Connector does not reference the Executor


Mark




But when I make a request, I'm not on a virtual thread : 
Thread[#76,Thread-14,5,main] . I profiled my application too but no virtual 
threads are used.

If I use a Http11NioProtocol instead of Http11Nio2Protocol, all requests are on 
virtual thread : 
VirtualThread[#65,http-nio-8080-virt-0]/runnable@ForkJoinPool-1-worker-1





Http11Nio2Protocol is not working with virtual threads? Has anyone encountered 
this problem before?



-
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: JAVA -tomcat- Request header is too large

[Ivano Luberti]

Il 07/12/2023 17:51, Mark Thomas ha scritto:

On 07/12/2023 15:37, Ivano Luberti wrote:

Hi, since a few days these errors started showing in my log files:

06-Dec-2023 07:39:56.082 INFO [http-nio-8080-exec-5826] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP 
request header
 Note: further occurrences of HTTP request parsing errors will be 
logged at DEBUG level.

    java.lang.IllegalArgumentException: Request header is too large
        at 
org.apache.coyote.http11.Http11InputBuffer.fill(Http11InputBuffer.java:790)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:975)
        at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:604)
        at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294)
        at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
        at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
        at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789)
        at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
        at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

        at java.lang.Thread.run(Thread.java:750)


I know I can increase the tolerated header size using sometjing like 
this:


... />


Bu my question is how can i debug the issue?

For example: how can i find the page requested when the exception was 
raised?


Match the timestamp in the logs with the timestamp in the access logs 
of the associated 400 response.


Mark


Thank you Mark.

Finding the exception in log files led me to think there was noting in 
the access log.


Is there any way to log the header content so I can find what is causing 
the issue?



--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/