Re: [EXTERNAL] Re: Request header too large..

[Amit Pande]

Thanks Chris. Yes, I will soon send out the patch for review.

Thanks,
Amit

On 11/2/18, 5:25 PM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Amit,

On 11/2/18 17:16, Amit Pande wrote:
> As per current implementation (below snippet is from 8.5.28), if
> the request header is too large (by default >8K, the default 
> maxHttpHeaderSize), is thrown below error message is seen.
> 
> 
> For request -- 02-Nov-2018 15:15:47.649 INFO [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header Note: further occurrences of HTTP header parsing
> errors will be logged at DEBUG level. 
> java.lang.IllegalArgumentException: Request header is too large at
> org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuf
fer.java:575)
>
> 
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:70
3)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
t.java:66)
>
> 
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractPro
tocol.java:790)
> 
> For response—
> 
> 02-Nov-2018 15:15:47.867 SEVERE [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response org.apache.coyote.http11.HeadersTooLargeException: An
> attempt was made to write more data to the response headers than
> there was room available in the buffer. Increase maxHttpHeaderSize
> on the connector or write less data into the response headers. at
> org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Htt
p11OutputBuffer.java:544)
>
> 
at
org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.jav
a:481)
> at
> org.apache.coyote.http11.Http11OutputBuffer.sendStatus(Http11OutputBuf
fer.java:361)
>
> 
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor
.java:1339)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:260)
>
> 
at
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java
:1523)
> 
> 
> However, this doesn’t tell us the name of the offending header
> which I think is valuable in debugging the issues.
> 
> Do you feel it’s worth the enhancement request?
> 
> Also, I noticed the comments
> 
> “ // (1) Headers plus request line size does not exceed its limit
> 
> 
> 
> // (2) There are enough bytes to avoid expanding the buffer when
> 
> 
> // reading body “
> 
> It says request line size ..does that mean maxHttpHeaderSize comes 
> in play for request line (which includes query params) as well?

Yes.

The request headers are read before selecting which context will
service the request. The request line, which not formally a part of
the "headers" per the HTTP spec, are considered to be "part of the
headers" as far as Tomcat is concerned, because they all share the
same buffer.

To locate the offending header, look at the end of the request, then
re-wind to the previous "\r\nheader:". If you don't find
"\r\nheader:", then it was the request line. But it could be request +
partial-header-name, so you'd have to be careful.

I'm not sure it's worth it to add a debugging enhancement (you
probably already know what your huge headers are), but I am by no
means the King of Tomcat: feel free to request that enhancement in BZ
and see if you can get some support.

If you write a patch/PR for it, it will almost certainly be added as
long as its not too intrusive :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvcztQACgkQHPApP6U8
pFhj+Q//QIMUy44I2SDH5kM7UeMk2SCB/5J5hW79RGfIGITFpmEMttBONF8wilg7
U7ldyjDuu2Msn+ynRPVg5lxf9pq3OQJKySv7xFc3AG4C44em4xRrJI8aHGsLxH5N
dQyyJY/oP61HzeiiiyDLYxQY3sidC+4gieOEJ2oG5ZsXJwFpvfc0Q1LyiIzN8fXa
o2PkH0B2kPsksgXD8WZLPXAFMgAUdmUu0wVzM0lt/kBvlG9LGW/vEd+fVeLrG93s
UEs3IrWT2aTWnOVyZl2LAPhL2GynfrDUmsmsc8EF6kljXiX3IWphaH9z1nbCpLFM
zDsUoIRpqm1sgXObV52zW8YbnaUzIEAZaI7lIlrOctRvc9ACeCvKkIc+aVylgnmR
zpEhFz/gOchl1T6x2+MXLHavch653F8OgYY52/TCqxQheVKSHjc2jJu9UTcb+7z0
EBbfeWvUeEdNd7edGORhKx6tJLotbRhF1Yr2sjxxkY8I31RGHv+ZlNStOuxr5uoI
0c68L2XGbe9gBaLbjopYOfb+Y8y73iX3wfJPKIlvXl8LkupA1wyg0NAwOn+ZDL2E
Rl865F3+DaaVaFoSRkpgp7pUrKfh9wi/N2CdCJ13hH6WY32/JD8+Z2X+YuRfMu6+
6dh+NiVvrQc998/gutkx+OnH+RTC0STJp6RTzYNZbnL5hi5z1Ms=
=bjZe
-END PGP SIGNATURE-

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

Re: Request header too large..

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Amit,

On 11/2/18 17:16, Amit Pande wrote:
> As per current implementation (below snippet is from 8.5.28), if
> the request header is too large (by default >8K, the default 
> maxHttpHeaderSize), is thrown below error message is seen.
> 
> 
> For request -- 02-Nov-2018 15:15:47.649 INFO [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.service Error parsing HTTP
> request header Note: further occurrences of HTTP header parsing
> errors will be logged at DEBUG level. 
> java.lang.IllegalArgumentException: Request header is too large at
> org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuf
fer.java:575)
>
> 
at
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:70
3)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLigh
t.java:66)
>
> 
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractPro
tocol.java:790)
> 
> For response—
> 
> 02-Nov-2018 15:15:47.867 SEVERE [catalina-exec-40]
> org.apache.coyote.http11.Http11Processor.endRequest Error finishing
> response org.apache.coyote.http11.HeadersTooLargeException: An
> attempt was made to write more data to the response headers than
> there was room available in the buffer. Increase maxHttpHeaderSize
> on the connector or write less data into the response headers. at
> org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Htt
p11OutputBuffer.java:544)
>
> 
at
org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.jav
a:481)
> at
> org.apache.coyote.http11.Http11OutputBuffer.sendStatus(Http11OutputBuf
fer.java:361)
>
> 
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor
.java:1339)
> at
> org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:260)
>
> 
at
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java
:1523)
> 
> 
> However, this doesn’t tell us the name of the offending header
> which I think is valuable in debugging the issues.
> 
> Do you feel it’s worth the enhancement request?
> 
> Also, I noticed the comments
> 
> “ // (1) Headers plus request line size does not exceed its limit
> 
> 
> 
> // (2) There are enough bytes to avoid expanding the buffer when
> 
> 
> // reading body “
> 
> It says request line size ..does that mean maxHttpHeaderSize comes 
> in play for request line (which includes query params) as well?

Yes.

The request headers are read before selecting which context will
service the request. The request line, which not formally a part of
the "headers" per the HTTP spec, are considered to be "part of the
headers" as far as Tomcat is concerned, because they all share the
same buffer.

To locate the offending header, look at the end of the request, then
re-wind to the previous "\r\nheader:". If you don't find
"\r\nheader:", then it was the request line. But it could be request +
partial-header-name, so you'd have to be careful.

I'm not sure it's worth it to add a debugging enhancement (you
probably already know what your huge headers are), but I am by no
means the King of Tomcat: feel free to request that enhancement in BZ
and see if you can get some support.

If you write a patch/PR for it, it will almost certainly be added as
long as its not too intrusive :)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvcztQACgkQHPApP6U8
pFhj+Q//QIMUy44I2SDH5kM7UeMk2SCB/5J5hW79RGfIGITFpmEMttBONF8wilg7
U7ldyjDuu2Msn+ynRPVg5lxf9pq3OQJKySv7xFc3AG4C44em4xRrJI8aHGsLxH5N
dQyyJY/oP61HzeiiiyDLYxQY3sidC+4gieOEJ2oG5ZsXJwFpvfc0Q1LyiIzN8fXa
o2PkH0B2kPsksgXD8WZLPXAFMgAUdmUu0wVzM0lt/kBvlG9LGW/vEd+fVeLrG93s
UEs3IrWT2aTWnOVyZl2LAPhL2GynfrDUmsmsc8EF6kljXiX3IWphaH9z1nbCpLFM
zDsUoIRpqm1sgXObV52zW8YbnaUzIEAZaI7lIlrOctRvc9ACeCvKkIc+aVylgnmR
zpEhFz/gOchl1T6x2+MXLHavch653F8OgYY52/TCqxQheVKSHjc2jJu9UTcb+7z0
EBbfeWvUeEdNd7edGORhKx6tJLotbRhF1Yr2sjxxkY8I31RGHv+ZlNStOuxr5uoI
0c68L2XGbe9gBaLbjopYOfb+Y8y73iX3wfJPKIlvXl8LkupA1wyg0NAwOn+ZDL2E
Rl865F3+DaaVaFoSRkpgp7pUrKfh9wi/N2CdCJ13hH6WY32/JD8+Z2X+YuRfMu6+
6dh+NiVvrQc998/gutkx+OnH+RTC0STJp6RTzYNZbnL5hi5z1Ms=
=bjZe
-END PGP SIGNATURE-

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

Request header too large..

[Amit Pande]

As per current implementation (below snippet is from 8.5.28), if the request 
header is too large (by default >8K, the default maxHttpHeaderSize), is thrown 
below error message is seen.


For request --
02-Nov-2018 15:15:47.649 INFO [catalina-exec-40] 
org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request 
header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG 
level.
java.lang.IllegalArgumentException: Request header is too large
at 
org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:575)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:703)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:790)

For response—

02-Nov-2018 15:15:47.867 SEVERE [catalina-exec-40] 
org.apache.coyote.http11.Http11Processor.endRequest Error finishing response
org.apache.coyote.http11.HeadersTooLargeException: An attempt was made to write 
more data to the response headers than there was room available in the buffer. 
Increase maxHttpHeaderSize on the connector or write less data into the 
response headers.
at 
org.apache.coyote.http11.Http11OutputBuffer.checkLengthBeforeWrite(Http11OutputBuffer.java:544)
at 
org.apache.coyote.http11.Http11OutputBuffer.write(Http11OutputBuffer.java:481)
at 
org.apache.coyote.http11.Http11OutputBuffer.sendStatus(Http11OutputBuffer.java:361)
at 
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1339)
at 
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:260)
at 
org.apache.coyote.http11.Http11Processor.endRequest(Http11Processor.java:1523)


However, this doesn’t tell us the name of the offending header which I think is 
valuable in debugging the issues.

Do you feel it’s worth the enhancement request?

Also, I noticed the comments

“
// (1) Headers plus request line size does not exceed its limit



// (2) There are enough bytes to avoid expanding the buffer when


// reading body
“

It says request line size ..does that mean maxHttpHeaderSize comes in play for 
request line (which includes query params) as well?

Thanks,
Amit

Re: Request for a technical review

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mallory,

On 11/2/18 12:34, Mallory Mooney wrote:
> Hi everyone!
> 
> Just wanted to check-in to see if anyone has had the chance to take
> a look at the draft and leave feedback. I'll be locking things down
> for this one by Thursday of next week (Nov. 8), so there's some
> time left if you are still working through it.

In your section on connector/protocol types, you say that Tomcat
auto-switches between APR and NIO, and that the default is APR. That
is not true in Tomcat 8.5 and later, where NIO is the default unless
the APR Lifecycle Listener's "useAprConnector" attribute has been set
to true (the default value for that is false).

Your description about garbage collection seems to indicate that
Tomcat is somehow involved in GC algorithm selection. It's not: that's
entirely up to the JVM, of course.

Also, OOME's don't cause crashes. They cause confusion, since some
application's aren't resilient, and the JVM itself rarely goes down,
so some devs and admins think everything is okay. Generally, it's not
okay, but it might look okay. There are also OOMEs which are
completely benign and can be ignored. Knowing which is which comes
with experience.

- -chris

> On Fri, Oct 19, 2018 at 7:52 AM Mallory Mooney
>  wrote:
> 
>> Hi all!
>> 
>> Just wanted to give you an update. I am working to get things for
>> this series wrapped up by the first week of November. Hopefully,
>> that still gives everyone enough time to review and leave any
>> feedback.
>> 
>> Mallory
>> 
>> On Fri, Oct 12, 2018 at 3:37 PM Mallory Mooney < 
>> mallory.moo...@datadoghq.com> wrote:
>> 
>>> Igal, it will be available publicly once published! I don't
>>> have an official publish date yet but can share that when it
>>> becomes more concrete.
>>> 
>>> And no PRs yet, Chris! It's still in the less cool GDoc stage
>>> of the review process. :)
>>> 
>>> On Fri, Oct 12, 2018 at 1:36 PM Igal Sapir 
>>> wrote:
>>> 
 On 10/12/2018 11:23 AM, Christopher Schultz wrote:
> Mallory,
> 
> On 10/12/18 13:23, Mallory Mooney wrote:
>>> I definitely appreciate everyone's willingness to help
>>> out!
>>> 
>>> Here is the link to the GDoc:
>>> 
> https://docs.google.com/document/d/1fudlXj055nnPd-1lUoAXIS2ge8qNI5
6_jgUhHgKczFE/edit?usp=sharing
>>>
> 
Requesting access will still be needed, but I can grant that ASAP.
>>> I want to make sure I can attribute
>>> comments/suggestions to specific people, so I know who
>>> to thank, and who to follow up with if I need more
>>> clarification on a specific comment. Plus, it makes the
>>> IT department happy.
> What, no GitHub PRs? ;)
> 
> +1
> 
> Is that going to be publicly available or is it a 
> proprietary/private/commercial guide?
> 
> 
> Igal
> 
> -chris
> 
>>> On Thu, Oct 11, 2018 at 9:53 AM Christopher Schultz < 
>>> ch...@christopherschultz.net> wrote:
>>> 
>>> Mark,
>>> 
>>> On 10/10/18 6:00 PM, Mark Thomas wrote:
>> On 10/10/18 17:44, Mallory Mooney wrote:
>>> Hi all,
>>> 
>>> I work for Datadog and am writing a guide about
>>> monitoring Tomcat (with or without Datadog).
>>> I'd love to get some feedback on the technical
>>> content. The project maintainers we reached out
>>> to recommended we post a request here.
>>> 
>>> Would anyone be up for that? I can send the
>>> post link to someone directly.
>>> 
>>> Appreciate your help and time!
>> Why not post the link here so the community can
>> review the document?
>>> +1
>>> 
>>> There are many active community members who have an
>>> interest in monitoring. I'm sure you'll get lots of
>>> feedback.
>>> 
>>> -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
 
 
>>> 
>>> -- Mallory Mooney Technical Content Writer
>>> 
>> 
>> 
>> -- Mallory Mooney Technical Content Writer
>> 
> 
> 
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvctPEACgkQHPApP6U8
pFi/vA/+LkINXqxpg73sWHH7kuAtLvQ007NUYyPln6htAYYWkKc4UI55N/JemxhB

Re: reinstall TC service after java upgrade?

[Mark Thomas]

On 02/11/2018 19:50, Berneburg, Cris J. - US wrote:
> Hi Folks
> 
> I upgraded Java from 8u181 to 8u191 on our dev (JDK) and test (JRE) Windows 
> 2012 servers today.  After doing so, the Tomcat 8.5(.32) Windows services 
> would no longer start.  Removing and re-adding the service fixed the service. 
>  I don't remember having to re-install the TC Windows services after 
> upgrading Java previously.  Is that normal?

It is one way to fix the problem. You need to reconfigure where the
service looks for the JRE. Normally you'd do that with Tomcat[7|8|9]w.exe

Mark


> 
> 1. Stop TC Windows Service.
> 2. Uninstall old Java.
> 3. Install new Java.
> 4. Update Windows environment var - JAVA_HOME for dev, JRE_HOME for test.
> 5. Try to start TC Win Service - Fail.  Helpful error code of "1".  Windows 
> Event Log says "incorrect function".
> 6. Run startup.bat manually from a command prompt - worked.
> 7. Run shutdown.bat to stop the manual startup.
> 8. Close Windows Services panel.
> 9. Delete TC Win Service with "Service.bat remove".
> 10. Recreate TC Win Service with "Service.bat install".
> 11. Open Windows Services panel.
> 12. Modify TC Win service to automatic start.
> 13. Start TC Win Service - OK.
> 
> Please note that I did not reboot the servers between steps.
> 
> Does the TC executable write Java-specific info to the Windows registry (or 
> something) that locks the service to a specific Java location or version?  I 
> don't see any registry commands in the service batch file.
> 
> --
> Cris Berneburg
> CACI Lead Software Engineer
> 
> 
> -
> 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

reinstall TC service after java upgrade?

[Berneburg, Cris J. - US]

Hi Folks

I upgraded Java from 8u181 to 8u191 on our dev (JDK) and test (JRE) Windows 
2012 servers today.  After doing so, the Tomcat 8.5(.32) Windows services would 
no longer start.  Removing and re-adding the service fixed the service.  I 
don't remember having to re-install the TC Windows services after upgrading 
Java previously.  Is that normal?

1. Stop TC Windows Service.
2. Uninstall old Java.
3. Install new Java.
4. Update Windows environment var - JAVA_HOME for dev, JRE_HOME for test.
5. Try to start TC Win Service - Fail.  Helpful error code of "1".  Windows 
Event Log says "incorrect function".
6. Run startup.bat manually from a command prompt - worked.
7. Run shutdown.bat to stop the manual startup.
8. Close Windows Services panel.
9. Delete TC Win Service with "Service.bat remove".
10. Recreate TC Win Service with "Service.bat install".
11. Open Windows Services panel.
12. Modify TC Win service to automatic start.
13. Start TC Win Service - OK.

Please note that I did not reboot the servers between steps.

Does the TC executable write Java-specific info to the Windows registry (or 
something) that locks the service to a specific Java location or version?  I 
don't see any registry commands in the service batch file.

--
Cris Berneburg
CACI Lead Software Engineer


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

RE: Debugging tomcat native connector

[Mark A. Claassen]

Wow, thanks a lot.  That was exactly what it was.

Something else, just in the event that someone references this email thread in 
the future, I also realized I could put this in my logging.properties file:
org.apache.coyote.level = FINE

I didn't think to add that until after the entropy thing was figured out, but 
it is something that may come in handy in similar situations.


Mark Claassen
Senior Software Engineer

Donnell Systems, Inc.
130 South Main Street
Leighton Plaza Suite 375
South Bend, IN  46601
E-mail: mailto:mclaas...@ocie.net
Voice: (574)232-3784
Fax: (574)232-4014

Disclaimer:
The opinions provided herein do not necessarily state or reflect 
those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and 
assumes no legal liability or responsibility for the posting. 
-Original Message-
From: Christopher Schultz  
Sent: Thursday, November 1, 2018 1:19 PM
To: users@tomcat.apache.org
Subject: Re: Debugging tomcat native connector

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 11/1/18 11:51, Mark A. Claassen wrote:
> Thanks for the reply.  I am using
> "org.apache.coyote.http11.Http11AprProtocol" in Tomcat 9.
> 
> The NIO connectors worked fine when we tried them, but the native ones 
> seem to start up, but then don’t work.
> 
> Interestingly, we found out that these connectors do eventually start 
> working!  We tried to connect a few hours later and they were working 
> fine. We are now trying to determine exactly how long it takes for 
> them to accept connections in hopes that this will help us figure out 
> what is going on.
> 
> Having a way to debug this better would be helpful.
Are you getting log entries in catalina.out similar to these?

INFO: Starting ProtocolHandler ["ajp-nio-8215"] Oct 10, 2018 4:23:38 PM 
org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-nio-127.0.0.1-8217"] Oct 10, 2018 4:23:38 
PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 6819 ms

??

If so, there should also be some timing information for initializing certain 
things. For example, if the server doesn't have much entropy in the entropy 
pool, then you can get a slow-startup while the crypto engine starts. This may 
be worse with the APR connector than for the NIO connectors as the source of 
randomness may be different by default (e.g. /dev/urandom for Java, /dev/random 
for APR). That may not actually be *true*, but it's a possibility.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbNXYACgkQHPApP6U8
pFhXkBAAny/RjuglPB38vMd1HZ45+9ifW4zRVgGY+2VjtJLSCJKf8+bouMdr6ZWY
5MbE9ru4WYNnIE7J01gYK7vjGfrotjxNLVAsY52qiCAf9u6Q+hsZb00T5B9Fog+z
9lFm2J4alHUMTe758vBJDtuuCqiB3I3SaY2f5rp5TiCWYVExrbNDQUe50ClbqFmB
+/e0XIybWXMCPsgylfyqQIZLwJ3t/Q+1eocQUIst86+tMrJdv2PWu+b7+J2y752Y
8dy3LqUjLQ218nDaXe1DXnWajunhuwAunK0/y1fL4pqlwJYDf6GTuWbW+AVDkBZh
3Q1o74QmM230FVyBhll2HSh9wi+rOON7MnjQD8Buks8LeTzyHRdGPRnFXoZm4H99
Re5uDXHLsJ0pweucVc4hqfE+2BxW33GT36FHUjGVAijMO6V3NX4CYhiOD7XkSlaz
uvoC+3ibhZZrgmc1AkM122u0YciSLDLb5iqGoVP/cOGJ0JVEwlEPMrpwSSe0ZTXz
BB6mTRu9WzN9j4YboTNmuiYnBx6wDAEWu+f9CjFptw7qGcwrzqrFyLp+/QuYzf4l
3iEVDlXPjF0bFsuJOvTChxfVm7s5NrxUBf2hJfMxmuKjeKKPZElgnWYtyoKokCHW
GNUD+HIGvJmc5bICo+WRzyf7zu1bsVoATcNvzM+K9WF1TBsrS+I=
=7fqB
-END PGP SIGNATURE-

-
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: Request for a technical review

[Mallory Mooney]

Hi everyone!

Just wanted to check-in to see if anyone has had the chance to take a look
at the draft and leave feedback. I'll be locking things down for this one
by Thursday of next week (Nov. 8), so there's some time left if you are
still working through it.

Have a great weekend!


On Fri, Oct 19, 2018 at 7:52 AM Mallory Mooney 
wrote:

> Hi all!
>
> Just wanted to give you an update. I am working to get things for this
> series wrapped up by the first week of November. Hopefully, that still
> gives everyone enough time to review and leave any feedback.
>
> Mallory
>
> On Fri, Oct 12, 2018 at 3:37 PM Mallory Mooney <
> mallory.moo...@datadoghq.com> wrote:
>
>> Igal, it will be available publicly once published! I don't have an
>> official publish date yet but can share that when it becomes more concrete.
>>
>> And no PRs yet, Chris! It's still in the less cool GDoc stage of the
>> review process. :)
>>
>> On Fri, Oct 12, 2018 at 1:36 PM Igal Sapir  wrote:
>>
>>> On 10/12/2018 11:23 AM, Christopher Schultz wrote:
>>> > -BEGIN PGP SIGNED MESSAGE-
>>> > Hash: SHA256
>>> >
>>> > Mallory,
>>> >
>>> > On 10/12/18 13:23, Mallory Mooney wrote:
>>> >> I definitely appreciate everyone's willingness to help out!
>>> >>
>>> >> Here is the link to the GDoc:
>>> >>
>>> https://docs.google.com/document/d/1fudlXj055nnPd-1lUoAXIS2ge8qNI56_jgUhHgKczFE/edit?usp=sharing
>>> >>   Requesting access will still be needed, but I can grant that ASAP.
>>> >> I want to make sure I can attribute comments/suggestions to
>>> >> specific people, so I know who to thank, and who to follow up with
>>> >> if I need more clarification on a specific comment. Plus, it makes
>>> >> the IT department happy.
>>> > What, no GitHub PRs? ;)
>>>
>>> +1
>>>
>>> Is that going to be publicly available or is it a
>>> proprietary/private/commercial guide?
>>>
>>>
>>> Igal
>>>
>>> > - -chris
>>> >
>>> >> On Thu, Oct 11, 2018 at 9:53 AM Christopher Schultz <
>>> >> ch...@christopherschultz.net> wrote:
>>> >>
>>> >> Mark,
>>> >>
>>> >> On 10/10/18 6:00 PM, Mark Thomas wrote:
>>> > On 10/10/18 17:44, Mallory Mooney wrote:
>>> >> Hi all,
>>> >>
>>> >> I work for Datadog and am writing a guide about monitoring
>>> >> Tomcat (with or without Datadog). I'd love to get some
>>> >> feedback on the technical content. The project maintainers
>>> >> we reached out to recommended we post a request here.
>>> >>
>>> >> Would anyone be up for that? I can send the post link to
>>> >> someone directly.
>>> >>
>>> >> Appreciate your help and time!
>>> > Why not post the link here so the community can review the
>>> > document?
>>> >> +1
>>> >>
>>> >> There are many active community members who have an interest in
>>> >> monitoring. I'm sure you'll get lots of feedback.
>>> >>
>>> >> -chris
>>> >>> -
>>> >>>
>>> >>>
>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> >>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> >>>
>>> >>>
>>> > -BEGIN PGP SIGNATURE-
>>> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>> >
>>> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvA5qUACgkQHPApP6U8
>>> > pFjPDg/+NNmp2sdTXhuPD2cXJTtBGXGMoOLost629AJF2R5ddG79a685TDPENn6B
>>> > NVPInUppI6U42RgK9hYs6/3JNpHfMIDay8HC7zaErAiu4wBHowI3yFckofYJjUwD
>>> > Wcd2Wzo+eBDZrf2PgwqiBr41nw7kbkeEAQcGeBVce7RL/+3r8Fz7FG++P5Bguu7d
>>> > 0N9S7y6leD3AdkX1o+JC9hQ6/AP2F8rZc8sws57Q2dpeV5QtK+8Pf2qOQpd6fskB
>>> > RDK4RQ1f4nLeAZgQ6BibUkwOQj6Fw7jPBHKGIfm6m5MOHvROkRTMV+fX3oLAd/dG
>>> > 3S1aW/9x8WIbKgYShR9ixxca5QuBNICC/tt9/oTYNj3XPbZLalMmMgOZ/cJcNI+R
>>> > kORA8ehwACeP/hIb/aLztze5g8FqyPslM95VPH/TWqgQXxe7bgU5fb6nUF/aCa87
>>> > RC/JXjZ/TZwMM+9xw1PQGH8aXqVGoku4Q/cbwXa4ctqklMKdGzlYRjY7TVjrqyec
>>> > ZMdFMgDb76wmDg2luD2g7jUmJJVdAtYiGXIidt5k8EtvymK6Nq/sEwj1SApV5jhT
>>> > PGdViui42IeL6IIwKY9gbuihL4btm0we9OXeeVc6fn99lySvsI8JZVgIQJzNmWEX
>>> > axmPUrQZI9iIr8qC9tufcuZOxwHpgCjYPIpM4IsR4/vlZv2VpQc=
>>> > =j6GH
>>> > -END PGP SIGNATURE-
>>> >
>>> > -
>>> > 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
>>>
>>>
>>
>> --
>> Mallory Mooney
>> Technical Content Writer
>>
>
>
> --
> Mallory Mooney
> Technical Content Writer
>


-- 
Mallory Mooney
Technical Content Writer

Re: precompile JSPs failure issue - Tomcat community

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 11/2/18 06:20, Rainer Jung wrote:
> You can control the number of threads using -threadCount. By
> default the number is equals to the number of cores the operating
> system show to the JVM.

x 2

> You might want to use a smaller number to see whether that helps.
> 
> I suggest you also check your Linux system limits on processes per
> user. That system limit on Linux in fact limits threads per user.
> So if such a limit is set and your user has other processes with
> many threads running, you might need to increase this limit.
> 
> In addition you can run your ant process with
> 
> strace -f -o /var/tmp/strace.out HERE_COMES_YOUR_ANT_COMMAND &
> 
> Then after you get the error, you can check the strace.out file
> for system call errors. The file will be big, but most probably the
> error is relatively close to the end.

- -chris

-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvcTpgACgkQHPApP6U8
pFjorRAAgGTY4qhWtokCdEqowTjN3rWQUk75aCCEEX/zxhQloiXf3cC1CeQEDqjG
SwnATFP7VN7/z1vAdgV9MQlK4SFBy5mp/Tf8HL8K33h6kv0CoEIcvjYbn5fUbpAu
QxmD7zZzEol2hXaKm8+oMnIe28G+dp74jqEpUgbhLDZhd4gAZxc+lejkHRIM8Sqj
hAdi1jh3cslwRpHf5j+Ff9BvYfAuS7ET6aT6e85zsFotj3S6LoXr8zX2HxoDuYWc
P1OebWr9lrJDp/QZEdVDGYPk3b4mZWWG56BK0TTBo+b0TY+52bgXnG71g0tfK1PB
MV1E4wVOj1wYwTuqmZIBXUfLzvGZMIEDG8p4Ne/pM3Hf/ekViQdW7wE19Ro28b3m
iF5AQqeG80P+yerTk7Vic5p7YV11rZrnFT9bUYOe3zBwLJL/GG9zgBQJj1usGtLT
nCmS/7wj4YvqWr8UtagqfbzYyXpEZZ0ZQt67bfONLCXTyyDkd4vRQauGJkMnQEL3
Qobw9SVOefxvVa7ChNBmja6KlmsGhmSlSzW51o2UUiGuwl0tuuwuccw4A+baUMF+
8d/rfzEhFW7SF4Y1/681rvWoEyxA05ILd80+i9BSzr66z+v2+21i5ivWqYZ+TWaF
g8X7kk84JriPgiEbuwqvCG6TmpaXOF0w1FW20s28XiH7uvyllPE=
=/xUp
-END PGP SIGNATURE-

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

Tomcat 9 ocsp via proxy

[Усманов Азат Анварович]

Hi everyone! Is it possible to specify proxy server address for server-side 
ocsp checking on tomcat when using apr /tomcat native for tls connections ? 
Something  apache-like

SSLStaplingForceURL http://internal-proxy.example.org:port

or  something  nginx-like directive
ssl_stapling_file file;
so the stapled OCSP response will be taken from the specified file instead of 
querying the OCSP responder specified in the server certificate.

I tried using

SSLStaplingForceURL="http://internal-proxy.example.org:port;

on both connector and Certificate element with latest tomcat 9.0.12 which 
resulted in  " {Server/Service/Connector/SSLHostConfig/Certificate} Setting 
property 'SSLStaplingForceURL' to 'http://192.168.1.6:3131' did not find a 
matching property" in logs. So it looks like tomcat doesn't support this (yet)

Should I put an enhancement request for that?

Re: precompile JSPs failure issue - Tomcat community

[Rainer Jung]

Am 02.11.2018 um 11:23 schrieb Rathore, Rajendra:

Hi Rainer,

We never face this issue with tomcat 8.5.32 and from 8.5.33 it will causing the 
issue and it happen on both OS Window and Linux, it will be blocking for us 
because we are not able to update tomcat to latest on and it had some security 
issue fixed in it, please let me know how should I proceed from here.


Others have already pointed you at

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

This introduced a new feature to JspC to make the compilation 
multi-threaded. Before this change it was always done on only one thread.


The good: it will make the compilation of your many JSPs faster.

The bad: it seems to create a yet to understand new problem for you.

I suggest you follow the hints, that I gave in my previous mail.

Regards,

Rainer


Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rainer Jung 
Sent: 02 November 2018 03:50 PM
To: Tomcat Users List ; Rathore, Rajendra 

Subject: Re: precompile JSPs failure issue - Tomcat community

Am 02.11.2018 um 10:57 schrieb Rathore, Rajendra:

Hi Mark,

I tried with tomcat 8.5.33 and face the same issue, I logged a bug
also
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D62879data=02%7C01%7Crar
athore%40ptc.com%7C80d42185b225483c061508d640accfbb%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636767508304565081sdata=FGguJAuq0y%2Ft
TMNTsd%2Fezc6yTbuOD5wxzlNWdYs8wFI%3Dreserved=0

Please let me know how should I proceed here?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra 
Sent: 01 November 2018 06:10 PM
To: Tomcat Users List 
Subject: RE: precompile JSPs failure issue - Tomcat community

Hi Chao,

We already tried it and it still failing.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 06:07 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:


Hi Mark,

I am suspecting the same in 8.5.33 tomcat, do you still won't me to
check it on tomcat 8.5.33?



How about increasing your perm memory?




Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 03:41 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:


On 01/11/2018 09:21, Rathore, Rajendra wrote:

Hi Team,



We have precompileJSPs tests that include compilation of around
4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
*8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError:
unable to create new native thread /



The machines on which tests were executed have *16GB* of RAM, out
of which around *13GB* was free.

The precompileJSPs tests were executed on Tomcat *8.5.34* by
setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the result
was /OutOfMemoryError./

/ /

However, We successfully tested precompileJSPs tests for Tomcat
*8.5.32 *with ANT_OPTS as -Xmx384m



Can someone please have a look into this issue?


Have you looked at the change log for the changes between 8.5.32 and
8.5.34 that might be relevant?



It could be changelog in 8.5.33

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
p
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Cra
r
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH
%
2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
p
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Cra
r
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7
A
3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0





Have you tried testing with 8.5.33 to narrow down the version in
which the issue first appears?

Mark


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




--
Guang <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavad
e
vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.c
o
m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678
e
2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6
O
03GGZvt6d6CWCA%3Dreserved=0







--
Guang

B 

RE: precompile JSPs failure issue - Tomcat community

[Rathore, Rajendra]

Hi Rainer,

We never face this issue with tomcat 8.5.32 and from 8.5.33 it will causing the 
issue and it happen on both OS Window and Linux, it will be blocking for us 
because we are not able to update tomcat to latest on and it had some security 
issue fixed in it, please let me know how should I proceed from here.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rainer Jung  
Sent: 02 November 2018 03:50 PM
To: Tomcat Users List ; Rathore, Rajendra 

Subject: Re: precompile JSPs failure issue - Tomcat community

Am 02.11.2018 um 10:57 schrieb Rathore, Rajendra:
> Hi Mark,
> 
> I tried with tomcat 8.5.33 and face the same issue, I logged a bug 
> also
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
> ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D62879data=02%7C01%7Crar
> athore%40ptc.com%7C80d42185b225483c061508d640accfbb%7Cb9921086ff774d0d
> 828acb3381f678e2%7C0%7C0%7C636767508304565081sdata=FGguJAuq0y%2Ft
> TMNTsd%2Fezc6yTbuOD5wxzlNWdYs8wFI%3Dreserved=0
> 
> Please let me know how should I proceed here?
> 
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
> 
> -Original Message-
> From: Rathore, Rajendra 
> Sent: 01 November 2018 06:10 PM
> To: Tomcat Users List 
> Subject: RE: precompile JSPs failure issue - Tomcat community
> 
> Hi Chao,
> 
> We already tried it and it still failing.
> 
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
> 
> -Original Message-
> From: Guang Chao 
> Sent: 01 November 2018 06:07 PM
> To: Tomcat Users List 
> Subject: Re: precompile JSPs failure issue - Tomcat community
> 
> On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:
> 
>> Hi Mark,
>>
>> I am suspecting the same in 8.5.33 tomcat, do you still won't me to 
>> check it on tomcat 8.5.33?
>>
> 
> How about increasing your perm memory?
> 
> 
>>
>> Thanks and Regards,
>> Rajendra Rathore
>> 9922701491
>>
>> -Original Message-
>> From: Guang Chao 
>> Sent: 01 November 2018 03:41 PM
>> To: Tomcat Users List 
>> Subject: Re: precompile JSPs failure issue - Tomcat community
>>
>> On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:
>>
>>> On 01/11/2018 09:21, Rathore, Rajendra wrote:
 Hi Team,



 We have precompileJSPs tests that include compilation of around
 4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
 *8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError:
 unable to create new native thread /



 The machines on which tests were executed have *16GB* of RAM, out 
 of which around *13GB* was free.

 The precompileJSPs tests were executed on Tomcat *8.5.34* by 
 setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the result 
 was /OutOfMemoryError./

 / /

 However, We successfully tested precompileJSPs tests for Tomcat
 *8.5.32 *with ANT_OPTS as -Xmx384m



 Can someone please have a look into this issue?
>>>
>>> Have you looked at the change log for the changes between 8.5.32 and
>>> 8.5.34 that might be relevant?
>>>
>>
>> It could be changelog in 8.5.33
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
>> p 
>> ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Cra
>> r 
>> athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
>> d 
>> 828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH
>> %
>> 2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.a
>> p 
>> ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Cra
>> r 
>> athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0
>> d 
>> 828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7
>> A
>> 3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0
>>
>>
>>
>>>
>>> Have you tried testing with 8.5.33 to narrow down the version in 
>>> which the issue first appears?
>>>
>>> Mark
>>>
>>> 
>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>
>> --
>> Guang <
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavad
>> e 
>> vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.c
>> o 
>> m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678
>> e 
>> 2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6
>> O
>> 03GGZvt6d6CWCA%3Dreserved=0
>>>
>>
> 
> 
> --
> Guang 
>  evnotes.com%2Fjava-string-comparedata=02%7C01%7Crarathore%40ptc.c
> om%7C80d42185b225483c061508d640accfbb%7Cb9921086ff774d0d828acb3381f678
> e2%7C0%7C0%7C636767508304565081sdata=Cx%2BDIalffZ3EcaSb7oPQVPx5sl
> JFqdnMg8r2A10E6M8%3Dreserved=0>
> B CB  
> [  X  ܚX KK[XZ[
>   \ \  ][  X 

Re: precompile JSPs failure issue - Tomcat community

[Rainer Jung]

Am 02.11.2018 um 10:57 schrieb Rathore, Rajendra:

Hi Mark,

I tried with tomcat 8.5.33 and face the same issue, I logged a bug also
https://bz.apache.org/bugzilla/show_bug.cgi?id=62879

Please let me know how should I proceed here?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra 
Sent: 01 November 2018 06:10 PM
To: Tomcat Users List 
Subject: RE: precompile JSPs failure issue - Tomcat community

Hi Chao,

We already tried it and it still failing.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 06:07 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:


Hi Mark,

I am suspecting the same in 8.5.33 tomcat, do you still won't me to
check it on tomcat 8.5.33?



How about increasing your perm memory?




Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 03:41 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:


On 01/11/2018 09:21, Rathore, Rajendra wrote:

Hi Team,



We have precompileJSPs tests that include compilation of around
4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
*8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError:
unable to create new native thread /



The machines on which tests were executed have *16GB* of RAM, out
of which around *13GB* was free.

The precompileJSPs tests were executed on Tomcat *8.5.34* by
setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the
result was /OutOfMemoryError./

/ /

However, We successfully tested precompileJSPs tests for Tomcat
*8.5.32 *with ANT_OPTS as -Xmx384m



Can someone please have a look into this issue?


Have you looked at the change log for the changes between 8.5.32 and
8.5.34 that might be relevant?



It could be changelog in 8.5.33

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Crar
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH%
2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Crar
athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7A
3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0





Have you tried testing with 8.5.33 to narrow down the version in
which the issue first appears?

Mark


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




--
Guang <
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavade
vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.co
m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678e
2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6O
03GGZvt6d6CWCA%3Dreserved=0







--
Guang 

B CB  [  
X  ܚX KK[XZ[
  \ \  ][  X  ܚX P X ]
  \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
  \ \  Z[ X ]
  \X K ܙ B


You can control the number of threads using -threadCount. By default the 
number is equals to the number of cores the operating system show to the 
JVM. You might want to use a smaller number to see whether that helps.


I suggest you also check your Linux system limits on processes per user. 
That system limit on Linux in fact limits threads per user. So if such a 
limit is set and your user has other processes with many threads 
running, you might need to increase this limit.


In addition you can run your ant process with

strace -f -o /var/tmp/strace.out HERE_COMES_YOUR_ANT_COMMAND &

Then after you get the error, you can check the strace.out file for 
system call errors. The file will be big, but most probably the error is 
relatively close to the end.


Regards,

Rainer


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

RE: precompile JSPs failure issue - Tomcat community

[Rathore, Rajendra]

Hi Mark,

I tried with tomcat 8.5.33 and face the same issue, I logged a bug also
https://bz.apache.org/bugzilla/show_bug.cgi?id=62879

Please let me know how should I proceed here?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Rathore, Rajendra  
Sent: 01 November 2018 06:10 PM
To: Tomcat Users List 
Subject: RE: precompile JSPs failure issue - Tomcat community

Hi Chao,

We already tried it and it still failing.

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: Guang Chao 
Sent: 01 November 2018 06:07 PM
To: Tomcat Users List 
Subject: Re: precompile JSPs failure issue - Tomcat community

On Thu, Nov 1, 2018 at 7:13 PM Rathore, Rajendra  wrote:

> Hi Mark,
>
> I am suspecting the same in 8.5.33 tomcat, do you still won't me to 
> check it on tomcat 8.5.33?
>

How about increasing your perm memory?


>
> Thanks and Regards,
> Rajendra Rathore
> 9922701491
>
> -Original Message-
> From: Guang Chao 
> Sent: 01 November 2018 03:41 PM
> To: Tomcat Users List 
> Subject: Re: precompile JSPs failure issue - Tomcat community
>
> On Thu, Nov 1, 2018 at 5:33 PM Mark Thomas  wrote:
>
> > On 01/11/2018 09:21, Rathore, Rajendra wrote:
> > > Hi Team,
> > >
> > >
> > >
> > > We have precompileJSPs tests that include compilation of around
> > > 4000 jsp files. After upgrading to Tomcat *8.5.34* from Tomcat
> > > *8.5.32* we are facing an *Error:*/java.lang.OutOfMemoryError: 
> > > unable to create new native thread /
> > >
> > >
> > >
> > > The machines on which tests were executed have *16GB* of RAM, out 
> > > of which around *13GB* was free.
> > >
> > > The precompileJSPs tests were executed on Tomcat *8.5.34* by 
> > > setting ANT_OPTS from -Xmx4096m to -Xmx10240m, But Still the 
> > > result was /OutOfMemoryError./
> > >
> > > / /
> > >
> > > However, We successfully tested precompileJSPs tests for Tomcat
> > > *8.5.32 *with ANT_OPTS as -Xmx384m
> > >
> > >
> > >
> > > Can someone please have a look into this issue?
> >
> > Have you looked at the change log for the changes between 8.5.32 and
> > 8.5.34 that might be relevant?
> >
>
> It could be changelog in 8.5.33
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
> ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53011data=02%7C01%7Crar
> athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
> 828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=diEmx1WNaWPvH%
> 2FGMd8Ex%2B4AgZCaGxcC6fez5UD%2FEF1c%3Dreserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.ap
> ache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D53492data=02%7C01%7Crar
> athore%40ptc.com%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d
> 828acb3381f678e2%7C0%7C0%7C636766727188877636sdata=rl1N7m5upe4E7A
> 3zTAx4oht2cjUHfuDoNCWoOHKfkrs%3Dreserved=0
>
>
>
> >
> > Have you tried testing with 8.5.33 to narrow down the version in 
> > which the issue first appears?
> >
> > Mark
> >
> > 
> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
> Guang <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjavade
> vnotes.com%2Fjava-string-to-datedata=02%7C01%7Crarathore%40ptc.co
> m%7Cc0bce30fc877421ebd6808d63ff6f1f2%7Cb9921086ff774d0d828acb3381f678e
> 2%7C0%7C0%7C636766727188877636sdata=lEQmu2kFIquRsA5rAeVw17HYosy6O
> 03GGZvt6d6CWCA%3Dreserved=0
> >
>


--
Guang 

B CB  [  
X  ܚX KK[XZ[
 \ \  ][  X  ܚX P X ]
 \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 \ \  Z[ X ]
 \X K ܙ B