Re: [Bug 47410] Using Request#getStream() while reading parameters

[Igal @ Lucee.org]

Volkan,

On 9/19/2017 11:21 AM, Volkan Yazıcı wrote:

Hey Igal,

Thanks for the response! I believe having more people suffering from 
the same limitation makes it more clear that there is a shortcoming 
that needs to addressed in Tomcat.
The problem is that Tomcat is compliant with the Servlet specification, 
and as Mark pointed out in the original ticket #47410 that is part of 
the spec.


Coming back to your project, thanks for the pointer. Though I have two 
concerns: 1) It is [still] a Tomcat-specific solution and
This is not a Tomcat-specific solution.  I use it with Jetty as well.  
It does use a library from Apache for processing FileUpload, and if you 
are running Tomcat you already have it in your classpath, but if you are 
not, you need to add that jar.


2) it consumes the entire InputStream regardless of whether the 
request handler will use it or not.
I've never had an issue with that, and am not sure what you are worried 
about?  network traffic?  memory? (the FileUpload library writes the 
contents to disk after a certain threshold), but if you're concerned 
with that then you can write your own filter and model it after mine if 
you want to hit the ground running.  Then you can break the read 
whenever you want, though I really think that you're over-optimizing here.


TBH I did not read your original emails with Chris in full, so I'm not 
sure what your requirements are.




Best.

On Tue, Sep 19, 2017 at 7:55 PM, Igal @ Lucee.org > wrote:


Volkan,

On 9/19/2017 10:47 AM, Volkan Yazıcı wrote:

Did not try (or consider) using a Tomcat Valve, since it would
make the
entire tool Tomcat-specific. I would rather find a way to
solve the problem
in a container agnostic way.

I had a similar issue so I wrote a simple Filter and named it
"RereadableServletRequestFilter":

https://github.com/isapir/servlet-filter-utils#rereadableservletrequestfilter



HTH,


Igal




Igal Sapir
Lucee Core Developer
Lucee.org 

Re: tomcat ssl setup

[tomcat]

On 19.09.2017 20:17, John Ellis wrote:

Here are the tomcat 9 log file DropBox links-

https://www.dropbox.com/s/hlcg3cycddteyaz/catalina.2017-09-08.log?dl=0


Well, there you go. It tells you explicitly where you made the mistakes, up to the file 
and line  numbers.
I can't see your server.xml, but I would bet that you have modified it, by surrounding 
some XML comment sections by another comment pair 

That crashes because XML does not allow that.
You cannot have this kind of thing :

  -->




https://www.dropbox.com/s/yj93ub9woxdoie0/localhost_access_log.2017-09-19.txt?dl=0

Thanks,

John Ellis

405.285.2500 office

United States

bize-logo-rgb-original_Ryan_Revised_portal 
sizecid:image002.jpg@01CECFDA.65B42CD0

http://biz-e.io

*From:*Alejandro Vargas M. [mailto:alejandro.var...@kymsolutions.com]
*Sent:* Tuesday, September 19, 2017 11:10 AM
*To:* users@tomcat.apache.org
*Subject:* Re: tomcat ssl setup

Do you see what's on the log files, they can tell you what's the problem in. 
Maybe you can
share those files too.

I also saw on line 117 this "|  -->|"  Looks like there's left over.

On 09/19/2017 09:31 AM, John Ellis wrote:

I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 6.4) 
server for
testing purposes. I downloaded & installed Tomcat9 fine and I get a proper 
webpage on
port 8080 but when I used the keytool commands and created a certificate 
from
cacert.org and then edited the server.xml file to setup the ssl 
configuration to run
on port 8443 I cannot get a webpage on that port; it defaults back to port 
8080. If I
am not providing all the needed info or asking a wrong question please 
forgive me. I
am not a programmer. My background is in computer hardware. I have just 
been forced to
learn this to support two products that we use here in our office; Jira and
Confluence. I have actually been working on setting them up for an SSL 
connection on a
different server. I got Confluence working on a secure port but not Jira so 
my boss
suggested troubleshooting the issue by trying to first get SSL setup for 
Tomcat on
this other server.

I am providing a copy of the Tomcat9 server.sml file here on a DropBox link-
https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0

Thanks in advance!

John Ellis

405.285.2500 office

United States

bize-logo-rgb-original_Ryan_Revised_portal 
sizecid:image002.jpg@01CECFDA.65B42CD0

http://biz-e.io

--



Alejandro Vargas Mayorga
*/Gerente Desarrollo C.A. & C./*
*Tel. 506- 7232-3366*
*Email:**alejandro.var...@kymsolutions.com* 
*
**www.kymsolutions.com* *
Visite nuestra aula virtual! *




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

Re: tomcat ssl setup

[tomcat]

On 19.09.2017 20:19, John Ellis wrote:

Andre at this point Alan, my boss, only has had me setup Tomcat 9 on this
server; not jira or confluence. He thought it might be easier to get the SSL
port working just on Tomcat first and then work with Jira and Confluence on
this server.


Yes, and he is right. And at least this way, we have a reasonable picture of what files 
and configuration to expect, to start with.
That is, provided we can figure out where the (RedHat ?) package-management of your 
platform puts the files which normally constitute tomcat.


I have a suggestion for you (and I know that you have already posted your current tomcat 
config files for people to look at, but do this in parallel).


If you really want to understand how tomcat works in its basic form, then do 
this :
- go to the "official tomcat website" tomcat.apache.org, and download an "official tomcat 
9" from that website.
- unpack it and install it, to some directory of your choice like "/opt/tomcat9" or 
"/srv/tomcat9" (pick somewhere where there are  not already a lot of things).


The difference with a packaged version, is mainly this :
- the whole tomcat software and standard configuration files will be installed under a 
single directory of your choice (e.g. /opt/tomcat9), and will be in a simple layout, like

- /opt/tomcat9
- bin (the basic startup scripts, and the initial tomcat "bootstrap.jar" which loads 
tomcat and starts it)

- conf (the configuration files)
- lib (the java libraries of tomcat and used by tomcat)
- logs (the logfiles that tomcat writes)
- temp (a writeable work directory for temporary files)
- webapps (top of all the application directories)
   - ROOT (the "default" application - basically a basic "Hello" page)
- work (where tomcat expands some files when it starts)

(It will not put things anywhere else, nor interfere with any other software that is 
already there, and it will be easy to delete when you do not want it anymore.)


This tomcat, you will not really run it at first. But it will give you an overview of the 
pieces, and how they relate to one another, in a simple layout.
It will also make it a lot easier for you to get help here, and to find your way in the 
on-line tomcat documentation, which often refers to such a standard layout.
(And you may even try to run it, following the detailed instructions that you will find in 
the top directory, in the file "RUNNING.txt". It is really quite simple.).


The issue with per-platform packaged versions, is that they do re-arrange all these pieces 
and files into other locations, to better fit the logic of other packages on that 
platform. And then they put a series of links between these directories, files etc., to 
make that packaged tomcat find these different pieces when it runs.
That is perfectly ok, and it makes it easier later, to run tomcat automatically as a 
daemon, update it, manage its logfiles etc.
But makes it quite difficult to find things initially, unless you have that standard 
layout to guide you. (Because then at least you know what you are looking for).




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

Re: Tomcat misuse of Servlet 3.0's asynchronous support

[Yasser Zamani]

On 9/13/2017 10:25 PM, Yasser Zamani wrote:
> 
> 
> On 9/13/2017 9:49 PM, Mark Thomas wrote:
>> On 05/09/2017 19:56, Yasser Zamani wrote:
>>> Thanks a lot Mark!
>>>
>>> Yes I knew these and before tested that a tomcat with 400 max threads
>>> "scalabilitaly is equal" to a tomcat with 200 max threads but with
>>> servlet 3's async API including application's thread pool with size 200.
>>>
>>> However so far I thought Oracle's docs are like standards and tomcat
>>> have to satisfy them :)
>>
>> Tomcat implements the Servlet, JSP, UEL, EL and JASPIC specifications.
>>
>> The document you refer to is not part of those specs and, as I said, it
>> is misleading at best.
>>
 That does increase scalability
 because rather than having a bunch of threads waiting for these
 non-blocking operations to complete, those threads can do useful work.
>>>
>>> But tomcat blocks another thread from container's thread pool for
>>> waiting or locking on that non-blocking operation's response!
>>
>> As I said, if the async API is used to move a blocking operation from
>> one thread to another, that won't improve scalability.
>>
>> You are only going to improve scalability if you move non-blocking
>> operations from the Servlet.service() method (which has to block waiting
>> for the non-blocking operation to complete) to the async API.
>> Essentially, if you leave it in the service() method you have one thread
>> allocated to each non-blocking operation.
>>
>> If the Servlet async API is used, the non-blocking operation is started
>> and the container thread continues to complete the service method. The
>> container thread is now free to do other useful work and the
>> non-blocking operation isn't using any thread at all - and won't until
>> the operation completes at which point it will require a thread to
>> perform the dispatch back to the container and then to process that
>> dispatch.
>>
> 
> :S I apologize as I know that I fails to understand some points again.
> Please excuse me bothering you.
> 
> The non-blocking operation isn't using any thread at all ?! So which 
> thread executes my Runnable passed to startAsync? At my first initial 
> mail, I see Tomcat passes that to it's thread pool. If I define my 
> non-blocking operation (that Runnable) as 
> System.out.println(Thread.getCurrentThread.getName()), I'll see 
> "http-nio-exec-XX which means Tomcat's thread pool has been allocated a 
> thread for my Runnable non-blocking operation. However, maybe you mean a 
> real IO wait as non-blocking operation.
> 
> Let forget scalablity. Could you please define an example business 
> operational and functional scenario which using Servlet's async API 
> improves or resolve it in such way that could not being improved or 
> resolved with NIO and increasing maxThreads and maxConnections?
> 

Thank you Mark. I wish to close and conclude this thread as below:

To whom concern, I found an excellent article at [1] which nicely 
describes what makes difference between increasing pool sizes or using 
Servlet 3's Async API. He says:

> We have solved the problem of the HTTP thread pool exhaustion, but the number 
> of required threads to handle the requests has not improved: we are just 
> spawning background threads to handle the requests. In terms of simultaneous 
> running thread count this should be equivalent to simply increase the HTTP 
> thread pool size: under heavy load the system will not scale.
> 
> Effective usage of Asynchronous Servlets
> In order to demonstrate the powerful features offered by asynchronous 
> servlets, we will implement the following use case:
> 
> * There is a file which size is 100 bytes that may be streamed to remote 
> clients
> 
> * We will have a background thread pool with a predefined number of threads 
> that will be responsible to stream the file to remote clients
> 
> * The HTTP threads will handle incoming requests and immediately pass them to 
> the background thread pool
> 
> * The background threads will send chunks of 10 bytes to the remote clients 
> in a round robin fashion

Best Regards,
Yasser.

[1] http://www.byteslounge.com/tutorials/asynchronous-servlets-in-java

>> In this case a container thread is only required up to the point where
>> there non-blocking operation starts and form the point where it
>> completes. While the non-blocking operation is in progress, the
>> container thread is free to do other useful work.
>>
>> Mark
>>
>>
>>> so I do
>>> not agree that "because those threads can do useful work" then "does
>>> increase scalability". I think Servlet 3's async API here may increase
>>> scalability if and only if the released thread also releases some
>>> resources which other threads may are blocked on them. and if and only
>>> if the new thread does not lock more resources than the original one.
>>> **Actually as I understand, using Servlet 3's async API compared with
>>> tomcat's nio with greater max threads, does not have any gain except
>>> what I wrote 

RE: tomcat ssl setup

[John Ellis]

Andre at this point Alan, my boss, only has had me setup Tomcat 9 on this
server; not jira or confluence. He thought it might be easier to get the SSL
port working just on Tomcat first and then work with Jira and Confluence on
this server. 

John Ellis

405.285.2500 office


    

http://biz-e.io

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: Tuesday, September 19, 2017 10:57 AM
To: users@tomcat.apache.org
Subject: Re: tomcat ssl setup

On 19.09.2017 17:31, John Ellis wrote:
> I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 
> 6.4) server for testing purposes. I downloaded & installed Tomcat9 
> fine and I get a proper webpage on port
> 8080 but when I used the keytool commands and created a certificate 
> from cacert.org and then edited the server.xml file to setup the ssl 
> configuration to run on port 8443 I cannot get a webpage on that port; 
> it defaults back to port 8080. If I am not providing all the needed info
or asking a wrong question please forgive me. I am not a programmer.
> My background is in computer hardware. I have just been forced to 
> learn this to support two products that we use here in our office; 
> Jira and Confluence. I have actually been working on setting them up 
> for an SSL connection on a different server. I got Confluence working 
> on a secure port but not Jira so my boss suggested troubleshooting the
issue by trying to first get SSL setup for Tomcat on this other server.
>
> I am providing a copy of the Tomcat9 server.sml file here on a DropBox 
> link-
> https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0
>
> Thanks in advance!
>

Hi. No problem, and no need to apologise, we try to help everyone here. (Any
tomcat user, at least).
No matter what tomcat you are running or where you instlled it, it should be
writing logfiles somewhere, in which it should tell you at start, what may
be wrong. Have you found and looked at these files yet ?
Maybe something else : I am no expert, but I believe that by default, each
of Confluence and Jira sets up its own "private" tomcat server. Are you sure
that you are looking at the right one ?


-
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 ssl setup

[John Ellis]

Here are the tomcat 9 log file DropBox links-

 

https://www.dropbox.com/s/hlcg3cycddteyaz/catalina.2017-09-08.log?dl=0

 

https://www.dropbox.com/s/yj93ub9woxdoie0/localhost_access_log.2017-09-19.tx
t?dl=0

 

Thanks,

 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 

From: Alejandro Vargas M. [mailto:alejandro.var...@kymsolutions.com] 
Sent: Tuesday, September 19, 2017 11:10 AM
To: users@tomcat.apache.org
Subject: Re: tomcat ssl setup

 

Do you see what's on the log files, they can tell you what's the problem in.
Maybe you can share those files too.

I also saw on line 117 this "  -->"  Looks like there's left over.

 

 

On 09/19/2017 09:31 AM, John Ellis wrote:

I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 6.4)
server for testing purposes. I downloaded & installed Tomcat9 fine and I get
a proper webpage on port 8080 but when I used the keytool commands and
created a certificate from cacert.org and then edited the server.xml file to
setup the ssl configuration to run on port 8443 I cannot get a webpage on
that port; it defaults back to port 8080. If I am not providing all the
needed info or asking a wrong question please forgive me. I am not a
programmer. My background is in computer hardware. I have just been forced
to learn this to support two products that we use here in our office; Jira
and Confluence. I have actually been working on setting them up for an SSL
connection on a different server. I got Confluence working on a secure port
but not Jira so my boss suggested troubleshooting the issue by trying to
first get SSL setup for Tomcat on this other server. 

I am providing a copy of the Tomcat9 server.sml file here on a DropBox link-
https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0

 

Thanks in advance!  

 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 

 

-- 







Alejandro Vargas Mayorga
Gerente Desarrollo C.A. & C.
Tel. 506- 7232-3366
Email: 
alejandro.var...@kymsolutions.com
  www.kymsolutions.com
Visite nuestra aula virtual! 

Re: [Bug 47410] Using Request#getStream() while reading parameters

[Igal @ Lucee.org]

Volkan,

On 9/19/2017 10:47 AM, Volkan Yazıcı wrote:

Did not try (or consider) using a Tomcat Valve, since it would make the
entire tool Tomcat-specific. I would rather find a way to solve the problem
in a container agnostic way.
I had a similar issue so I wrote a simple Filter and named it 
"RereadableServletRequestFilter":

https://github.com/isapir/servlet-filter-utils#rereadableservletrequestfilter

HTH,


Igal

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

Re: [Bug 47410] Using Request#getStream() while reading parameters

[Volkan Yazıcı]

Hey Christopher,

Did not try (or consider) using a Tomcat Valve, since it would make the
entire tool Tomcat-specific. I would rather find a way to solve the problem
in a container agnostic way. Though, thanks for the idea. Maybe I can
release a separate artifact just for Tomcat.

Best.

On Tue, Sep 19, 2017 at 7:11 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Volkan,
>
> On 9/19/17 3:07 AM, Volkan Yazıcı wrote:
> > Hello,
> >
> > When you try to access the raw InputStream of a
> > x-www-form-urlencoded servlet request, the stream could have
> > already been indirectly consumed by a prior access to the
> > parameters (e.g., via ServletRequest#getParameterMap()) of the
> > request. This feature (bug?) has already been documented in the
> > section SRV.3.1.1 of the Servlet spec
> >  vlet-3_1-final.pdf>
> >
> >
> and there are other people (Bug 47410
> > ) who have
> > been bitten by this as well.
> >
> > This indirect stream consumption makes it, to the best of my
> > knowledge, impossible to mirror the InputStream, which is exactly
> > what we are trying to achieve in HRRS .
> > Hence, I try to re-construct the InputStream from request
> > parameters
> >  om/vlkan/hrrs/servlet/HrrsUrlEncodedFormHelper.java>.
> >
> >
> This, as you can imagine, a really nasty hack which I am not fond of
> > either. Further, to make the things worse, when servlet pushes the
> > form parameters into request parameter map, it merges them with
> > query parameters too. Now you need to manually parse both request
> > and query parameters to figure out the initial form parameters. I
> > am not even talking about lost parameter ordering. A total
> > shipwreck.
> >
> > Even if HRRS is the first filter in the list, it is not consuming
> > InputStream, it is just wrapping the InputStream and passing along
> > the wrapped request along the chain. Problem is, getParameter()
> > calls in Tomcat is using an internal reference to the InputStream
> > (that is, o.a.c.connector.Request#getStream()) and not calling
> > javax.servlet.ServletRequest#getInputStream(). Hence, InputStream
> > gets indirectly consumed without the wrapped one getting used at
> > all. Is it possible to make o.a.c.connector.Request#readPostBody()
> > use getInputStream() rather than getStream() to solve this problem?
> > Or is there an easier fix that I am missing?
>
> If you use a Valve (which is Tomcat-specific) instead of a Filter, are
> you able to intercept input stream more effectively?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZwU/RAAoJEBzwKT+lPKRYIB4P/0J7Ok3e5CtJRewaHzM/BMv2
> fLCVhyrB79T0obwQMQ/Zh8A63mGsrzjpH+TJr8pvDlgXeWviT4JHgy01uf/KVt8/
> doHJAGvYMVkSM8ZnXRl2p940Rkw8hJKyTXXqE7fN2XilbxGBse3Q4OP2S61vb/EM
> lgHJrSOdvElHyI+Wcdc/H46J/QNirYZx8PMHWl1ha9a1kw6YvOnJaFqK01KwMZR6
> ghUgbiOrP40gqEX8h8zKVYTMejZv2ngnN4worvN3Mp/PjTT2AvLAmgTVHFkHeX6J
> HvVNh429YVpJEoCOiKuK7vSEI+YlpyVI9Emym5yi6yfXm7LTi2b8eNwx3jeRT09R
> efiUhQWw4KFqBCVQPt5Jh5yjrl9Lzr9AfRIFphURvzCuHeT1qF6B+8zrE4njn4ch
> az0PB8q6Okqykbii4BwFYd64cxHRzY0QuMaOqH5gGBcTHSEbk/7rw1Qah+vOG3/R
> zt/cA51rgVwAO/jPUYFI1OcpO5vAJ7BTcejFFMCTlP3vLMz6PhhBM50P2fBaBleN
> G09KgVNgWQV3hQgOdmbTiOMc775EsLHwv9DMWwTxwsDvAVPmUEZTa4DqM3rqe8hx
> QlCjvO7fPilrgy9f6ryH0dfioSpZXUAYhADnhvX98dRbuB3cWooIbLbaTAMgIzBe
> KbEM3Ii+bGaox7k4UKeC
> =o2M4
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [Bug 47410] Using Request#getStream() while reading parameters

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Volkan,

On 9/19/17 3:07 AM, Volkan Yazıcı wrote:
> Hello,
> 
> When you try to access the raw InputStream of a
> x-www-form-urlencoded servlet request, the stream could have
> already been indirectly consumed by a prior access to the
> parameters (e.g., via ServletRequest#getParameterMap()) of the
> request. This feature (bug?) has already been documented in the
> section SRV.3.1.1 of the Servlet spec 
> 
>
> 
and there are other people (Bug 47410
> ) who have
> been bitten by this as well.
> 
> This indirect stream consumption makes it, to the best of my
> knowledge, impossible to mirror the InputStream, which is exactly
> what we are trying to achieve in HRRS .
> Hence, I try to re-construct the InputStream from request
> parameters 
> .
>
> 
This, as you can imagine, a really nasty hack which I am not fond of
> either. Further, to make the things worse, when servlet pushes the
> form parameters into request parameter map, it merges them with
> query parameters too. Now you need to manually parse both request
> and query parameters to figure out the initial form parameters. I
> am not even talking about lost parameter ordering. A total
> shipwreck.
> 
> Even if HRRS is the first filter in the list, it is not consuming 
> InputStream, it is just wrapping the InputStream and passing along
> the wrapped request along the chain. Problem is, getParameter()
> calls in Tomcat is using an internal reference to the InputStream
> (that is, o.a.c.connector.Request#getStream()) and not calling 
> javax.servlet.ServletRequest#getInputStream(). Hence, InputStream
> gets indirectly consumed without the wrapped one getting used at
> all. Is it possible to make o.a.c.connector.Request#readPostBody()
> use getInputStream() rather than getStream() to solve this problem?
> Or is there an easier fix that I am missing?

If you use a Valve (which is Tomcat-specific) instead of a Filter, are
you able to intercept input stream more effectively?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZwU/RAAoJEBzwKT+lPKRYIB4P/0J7Ok3e5CtJRewaHzM/BMv2
fLCVhyrB79T0obwQMQ/Zh8A63mGsrzjpH+TJr8pvDlgXeWviT4JHgy01uf/KVt8/
doHJAGvYMVkSM8ZnXRl2p940Rkw8hJKyTXXqE7fN2XilbxGBse3Q4OP2S61vb/EM
lgHJrSOdvElHyI+Wcdc/H46J/QNirYZx8PMHWl1ha9a1kw6YvOnJaFqK01KwMZR6
ghUgbiOrP40gqEX8h8zKVYTMejZv2ngnN4worvN3Mp/PjTT2AvLAmgTVHFkHeX6J
HvVNh429YVpJEoCOiKuK7vSEI+YlpyVI9Emym5yi6yfXm7LTi2b8eNwx3jeRT09R
efiUhQWw4KFqBCVQPt5Jh5yjrl9Lzr9AfRIFphURvzCuHeT1qF6B+8zrE4njn4ch
az0PB8q6Okqykbii4BwFYd64cxHRzY0QuMaOqH5gGBcTHSEbk/7rw1Qah+vOG3/R
zt/cA51rgVwAO/jPUYFI1OcpO5vAJ7BTcejFFMCTlP3vLMz6PhhBM50P2fBaBleN
G09KgVNgWQV3hQgOdmbTiOMc775EsLHwv9DMWwTxwsDvAVPmUEZTa4DqM3rqe8hx
QlCjvO7fPilrgy9f6ryH0dfioSpZXUAYhADnhvX98dRbuB3cWooIbLbaTAMgIzBe
KbEM3Ii+bGaox7k4UKeC
=o2M4
-END PGP SIGNATURE-

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

RE: tomcat ssl setup

[John Ellis]

Yes I will put the log files on DropBox as well when I get back from lunch.

Thanks,

 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 

From: Alejandro Vargas M. [mailto:alejandro.var...@kymsolutions.com] 
Sent: Tuesday, September 19, 2017 11:10 AM
To: users@tomcat.apache.org
Subject: Re: tomcat ssl setup

 

Do you see what's on the log files, they can tell you what's the problem in.
Maybe you can share those files too.

I also saw on line 117 this "  -->"  Looks like there's left over.

 

 

On 09/19/2017 09:31 AM, John Ellis wrote:

I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 6.4)
server for testing purposes. I downloaded & installed Tomcat9 fine and I get
a proper webpage on port 8080 but when I used the keytool commands and
created a certificate from cacert.org and then edited the server.xml file to
setup the ssl configuration to run on port 8443 I cannot get a webpage on
that port; it defaults back to port 8080. If I am not providing all the
needed info or asking a wrong question please forgive me. I am not a
programmer. My background is in computer hardware. I have just been forced
to learn this to support two products that we use here in our office; Jira
and Confluence. I have actually been working on setting them up for an SSL
connection on a different server. I got Confluence working on a secure port
but not Jira so my boss suggested troubleshooting the issue by trying to
first get SSL setup for Tomcat on this other server. 

I am providing a copy of the Tomcat9 server.sml file here on a DropBox link-
https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0

 

Thanks in advance!  

 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 

 

-- 







Alejandro Vargas Mayorga
Gerente Desarrollo C.A. & C.
Tel. 506- 7232-3366
Email: 
alejandro.var...@kymsolutions.com
  www.kymsolutions.com
Visite nuestra aula virtual! 

Re: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Coty Sutherland]

On Tue, Sep 19, 2017 at 9:53 AM, Suvendu Sekhar Mondal
 wrote:
> Radhika,
>
> On Tue, Sep 19, 2017 at 2:21 PM, Peddi, Radhika (Radhika)
>  wrote:
>> Hi,
>>
>> We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are running 
>> performance testing of our application we are seeing below error in 
>> catalina.out.
>>
>> java.lang.OutOfMemoryError: unable to create new native thread Exception in 
>> Catalina.out after upgrading to RHEL 7.4

As stated before, this is a limitation on the number of threads
spawned by the process imposed by the OS. In order to resolve it, you
need to either increase nproc/nofile or decrease the number of threads
that the Tomcat process is spawning. Check the ulimit for your user
and compare that to the number of threads that you have configured. If
you're on a 32-bit machine, it may be a problem with the process size,
but RHEL-7 is only on 64-bit AFAIK so that shouldn't be your issue :)

>
> This simply indicates that JVM was trying to create a new thread and
> OS can't create any new thread simply because native memory space was
> exhausted. This limit is very much platform dependent.
>
> Is your app opening too many threads? On my Windows 10 laptop with
> 32GB RAM and JDK 1.8, I can open 53+ threads before run into this
> OOM problem. You can find it by monitoring Tomcat instance. So far I
> ran into this problem one time - couple of years ago. We got away
> after adding some memory and by reducing thread stack size.
>
> Another thing can happen, you might have lost some OS setting(which
> was used to bump up the default OS limit) while upgrading from one
> version to another; which was preventing this issue from occurring so
> far - just speculating. And this is not a Tomcat's problem. :)
>
>> Attached is the thread dump.
>>
>> We are using Tomcat 7.0.69.
>>
>> As per REDHAT we have increased tomcat5 user which used to run Tomcat 
>> process in /etc/security/limits.d/20-nproc.conf like below
>>
>> * soft nproc 4096
>> root soft nproc unlimited
>> tomcat5 soft nproc 8192
>>
>> All the processes are used by Tomcat. If we increase the value to 16K or 32K 
>> all threads are consumed and they are in Waiting(Parking) state.
>>
>> "http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0 tid=0x7efc8c029800 
>> nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x0003c454c008> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> at 
>> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
>> at 
>> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at 
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> "http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0 tid=0x7efc0401e000 
>> nid=0x10e7a waiting on condition [0x7ef9bc82f000]
>>java.lang.Thread.State: WAITING (parking)
>> at sun.misc.Unsafe.park(Native Method)
>> - parking to wait for  <0x0003c454c008> (a 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> at 
>> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>> at 
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>> at 
>> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>> at 
>> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
>> at 
>> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at 
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> They are not get

Re: tomcat ssl setup

[Alejandro Vargas M.]

Do you see what's on the log files, they can tell you what's the problem 
in. Maybe you can share those files too.


I also saw on line 117 this "|||-->|" Looks like there's left over.



On 09/19/2017 09:31 AM, John Ellis wrote:


I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 
6.4) server for testing purposes. I downloaded & installed Tomcat9 
fine and I get a proper webpage on port 8080 but when I used the 
keytool commands and created a certificate from cacert.org and then 
edited the server.xml file to setup the ssl configuration to run on 
port 8443 I cannot get a webpage on that port; it defaults back to 
port 8080. If I am not providing all the needed info or asking a wrong 
question please forgive me. I am not a programmer. My background is in 
computer hardware. I have just been forced to learn this to support 
two products that we use here in our office; Jira and Confluence. I 
have actually been working on setting them up for an SSL connection on 
a different server. I got Confluence working on a secure port but not 
Jira so my boss suggested troubleshooting the issue by trying to first 
get SSL setup for Tomcat on this other server.


I am providing a copy of the Tomcat9 server.sml file here on a DropBox 
link- https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0


Thanks in advance!

John Ellis

405.285.2500 office

United States

bize-logo-rgb-original_Ryan_Revised_portal 
sizecid:image002.jpg@01CECFDA.65B42CD0


http://biz-e.io



--




Alejandro Vargas Mayorga
/*Gerente Desarrollo C.A. & C.*/
*Tel. 506- 7232-3366*
*Email:**alejandro.var...@kymsolutions.com* 
*

**www.kymsolutions.com* *
Visite nuestra aula virtual! *

Re: tomcat ssl setup

[tomcat]

On 19.09.2017 17:31, John Ellis wrote:

I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 6.4) 
server for
testing purposes. I downloaded & installed Tomcat9 fine and I get a proper 
webpage on port
8080 but when I used the keytool commands and created a certificate from 
cacert.org and
then edited the server.xml file to setup the ssl configuration to run on port 
8443 I
cannot get a webpage on that port; it defaults back to port 8080. If I am not 
providing
all the needed info or asking a wrong question please forgive me. I am not a 
programmer.
My background is in computer hardware. I have just been forced to learn this to 
support
two products that we use here in our office; Jira and Confluence. I have 
actually been
working on setting them up for an SSL connection on a different server. I got 
Confluence
working on a secure port but not Jira so my boss suggested troubleshooting the 
issue by
trying to first get SSL setup for Tomcat on this other server.

I am providing a copy of the Tomcat9 server.sml file here on a DropBox link-
https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0

Thanks in advance!



Hi. No problem, and no need to apologise, we try to help everyone here. (Any tomcat user, 
at least).
No matter what tomcat you are running or where you instlled it, it should be writing 
logfiles somewhere, in which it should tell you at start, what may be wrong. Have you 
found and looked at these files yet ?
Maybe something else : I am no expert, but I believe that by default, each of Confluence 
and Jira sets up its own "private" tomcat server. Are you sure that you are looking at the 
right one ?



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

tomcat ssl setup

[John Ellis]

I have been trying to setup SSL for tomcat 9.00.M26 on a RHEL (version 6.4)
server for testing purposes. I downloaded & installed Tomcat9 fine and I get
a proper webpage on port 8080 but when I used the keytool commands and
created a certificate from cacert.org and then edited the server.xml file to
setup the ssl configuration to run on port 8443 I cannot get a webpage on
that port; it defaults back to port 8080. If I am not providing all the
needed info or asking a wrong question please forgive me. I am not a
programmer. My background is in computer hardware. I have just been forced
to learn this to support two products that we use here in our office; Jira
and Confluence. I have actually been working on setting them up for an SSL
connection on a different server. I got Confluence working on a secure port
but not Jira so my boss suggested troubleshooting the issue by trying to
first get SSL setup for Tomcat on this other server. 

I am providing a copy of the Tomcat9 server.sml file here on a DropBox link-
https://www.dropbox.com/s/k3l07w9p4n81fas/server.xml?dl=0

 

Thanks in advance!  

 

John Ellis

 

405.285.2500 office

 





 

http://biz-e.io

 

Re: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Suvendu Sekhar Mondal]

Radhika,

On Tue, Sep 19, 2017 at 2:21 PM, Peddi, Radhika (Radhika)
 wrote:
> Hi,
>
> We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are running 
> performance testing of our application we are seeing below error in 
> catalina.out.
>
> java.lang.OutOfMemoryError: unable to create new native thread Exception in 
> Catalina.out after upgrading to RHEL 7.4
>

This simply indicates that JVM was trying to create a new thread and
OS can't create any new thread simply because native memory space was
exhausted. This limit is very much platform dependent.

Is your app opening too many threads? On my Windows 10 laptop with
32GB RAM and JDK 1.8, I can open 53+ threads before run into this
OOM problem. You can find it by monitoring Tomcat instance. So far I
ran into this problem one time - couple of years ago. We got away
after adding some memory and by reducing thread stack size.

Another thing can happen, you might have lost some OS setting(which
was used to bump up the default OS limit) while upgrading from one
version to another; which was preventing this issue from occurring so
far - just speculating. And this is not a Tomcat's problem. :)

> Attached is the thread dump.
>
> We are using Tomcat 7.0.69.
>
> As per REDHAT we have increased tomcat5 user which used to run Tomcat process 
> in /etc/security/limits.d/20-nproc.conf like below
>
> * soft nproc 4096
> root soft nproc unlimited
> tomcat5 soft nproc 8192
>
> All the processes are used by Tomcat. If we increase the value to 16K or 32K 
> all threads are consumed and they are in Waiting(Parking) state.
>
> "http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0 tid=0x7efc8c029800 
> nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> "http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0 tid=0x7efc0401e000 
> nid=0x10e7a waiting on condition [0x7ef9bc82f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> They are not getting release. After some time Tomcat getting stopped 
> automatically. You may need the output of below from our setup.
>
> [root@iqsvtk05 ~]# rpm -qif 
> /opt/coreservices/tomcat-7.0.69/logs/
> Name : tomcat
> Version : 7.0.69
> Release : AV10
> Architecture: x86_64
> Install Date: Fri 18 Aug 2017 01:41:54 AM MDT
> Group : System Environment/Daemons
> Size : 8468465
> License : Apache License, Version 2.0
> Signature : (none)
> Source RPM : tomcat-7.0.69-AV10.src.rpm
> Build Date : Fri 24 Jun 2016 01:59:37 AM MDT
> Build Host : puiqx3650dev03.apac.avaya.com
> Relocations : /usr/share
> Packager : Avaya, Inc.
> Vendor : Apache S

RE: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Thakur, Gulam (IBM)]

Hi,

This we require in windows systems. We will be looking at Windows 10. 
Springboot application in Microsoft Azure based.


Many thanks, 

Gulam Thakur
Software Developer, Synapse Dev Squad 
BP Sunbury, Bldg H, 1st floor
TW16 7LN







Many thanks, 

Gulam Thakur
Software Developer, Synapse Dev Squad 
BP Sunbury, Bldg H, 1st floor
TW16 7LN


Mobile: +44 (0) 7443 243808 
E-mail: gulam.tha...@bp.com
 gulam.thakur-cic...@ibm.com




BP International Limited. Registered office: Chertsey Road, Sunbury on Thames, 
Middlesex, TW16 7BP. Registered in England and Wales, number 542515. 
 
E-mail disclaimer: The information in this e-mail is confidential and may be 
legally privileged. It is intended solely for the addressee(s) only. Access to 
this e-mail by anyone else is unauthorised. If you are not the intended 
recipient, any disclosure, copying, distribution or an action taken or omitted 
to be taken in reliance on it, is prohibited and may be unlawful. Within the 
bounds of law, electronic transmissions through internal and external networks 
may be monitored to ensure compliance with internal policies and legitimate 
business purposes.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: 19 September 2017 14:10
To: Tomcat Users List 
Subject: Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution 
via JSP upload

On 19/09/17 14:00, André Warnier (tomcat) wrote:
> Hello.
> 
> Did the issue below also affect the DAV application ?

Yes, as the WebDAV servlet also processes HTTP PUT requests.

The WebDAV servlet extends the Default servlet so they actually share the 
implementation.

> And if yes, also only under Windows ?

Yes. This is, as far as we can tell, Windows specific.

HTH,

Mark


> 
>  Forwarded Message 
> Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution 
> via JSP upload
> Date: Tue, 19 Sep 2017 11:58:44 +0100
> From: Mark Thomas 
> Reply-To: Tomcat Users List 
> To: Tomcat Users List 
> CC: annou...@tomcat.apache.org , 
> annou...@apache.org, Tomcat Developers List 
> 
> CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.79
> 
> Description:
> When running on Windows with HTTP PUTs enabled (e.g. via setting the 
> readonly initialisation parameter of the Default to false) it was 
> possible to upload a JSP file to the server via a specially crafted 
> request. This JSP could then be requested and any code it contained 
> would be executed by the server.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
> 
> Credit:
> This issue was reported responsibly to the Apache Tomcat Security Team 
> by iswin from 360-sg-lab (360观星实验室)
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 
> -
> 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


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

RE: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Thakur, Gulam (IBM)]

Hi,

This we require in windows systems. We will be looking at Windows 10. 
Springboot application in Microsoft Azure based.


Many thanks, 

Gulam Thakur
Software Developer, Synapse Dev Squad 
BP Sunbury, Bldg H, 1st floor
TW16 7LN


Mobile: +44 (0) 7443 243808 
E-mail: gulam.tha...@bp.com
 gulam.thakur-cic...@ibm.com




BP International Limited. Registered office: Chertsey Road, Sunbury on Thames, 
Middlesex, TW16 7BP. Registered in England and Wales, number 542515. 
 
E-mail disclaimer: The information in this e-mail is confidential and may be 
legally privileged. It is intended solely for the addressee(s) only. Access to 
this e-mail by anyone else is unauthorised. If you are not the intended 
recipient, any disclosure, copying, distribution or an action taken or omitted 
to be taken in reliance on it, is prohibited and may be unlawful. Within the 
bounds of law, electronic transmissions through internal and external networks 
may be monitored to ensure compliance with internal policies and legitimate 
business purposes.

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com] 
Sent: 19 September 2017 14:00
To: Tomcat Users List 
Subject: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via 
JSP upload

Hello.

Did the issue below also affect the DAV application ?
And if yes, also only under Windows ?

 Forwarded Message 
Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP 
upload
Date: Tue, 19 Sep 2017 11:58:44 +0100
From: Mark Thomas 
Reply-To: Tomcat Users List 
To: Tomcat Users List 
CC: annou...@tomcat.apache.org , 
annou...@apache.org, Tomcat Developers List 

CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 7.0.0 to 7.0.79

Description:
When running on Windows with HTTP PUTs enabled (e.g. via setting the readonly 
initialisation parameter of the Default to false) it was possible to upload a 
JSP file to the server via a specially crafted request. This JSP could then be 
requested and any code it contained would be executed by the server.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)

Credit:
This issue was reported responsibly to the Apache Tomcat Security Team by iswin 
from 360-sg-lab (360观星实验室)

History:
2017-09-19 Original advisory

References:
[1] http://tomcat.apache.org/security-7.html

-
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

Re: Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

On 19/09/17 14:00, André Warnier (tomcat) wrote:
> Hello.
> 
> Did the issue below also affect the DAV application ?

Yes, as the WebDAV servlet also processes HTTP PUT requests.

The WebDAV servlet extends the Default servlet so they actually share
the implementation.

> And if yes, also only under Windows ?

Yes. This is, as far as we can tell, Windows specific.

HTH,

Mark


> 
>  Forwarded Message 
> Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution
> via JSP upload
> Date: Tue, 19 Sep 2017 11:58:44 +0100
> From: Mark Thomas 
> Reply-To: Tomcat Users List 
> To: Tomcat Users List 
> CC: annou...@tomcat.apache.org ,
> annou...@apache.org, Tomcat Developers List 
> 
> CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.79
> 
> Description:
> When running on Windows with HTTP PUTs enabled (e.g. via setting the
> readonly initialisation parameter of the Default to false) it was
> possible to upload a JSP file to the server via a specially crafted
> request. This JSP could then be requested and any code it contained
> would be executed by the server.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
> 
> Credit:
> This issue was reported responsibly to the Apache Tomcat Security Team
> by iswin from 360-sg-lab (360观星实验室)
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 
> -
> 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

Fwd: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[tomcat]

Hello.

Did the issue below also affect the DAV application ?
And if yes, also only under Windows ?

 Forwarded Message 
Subject: [SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP 
upload
Date: Tue, 19 Sep 2017 11:58:44 +0100
From: Mark Thomas 
Reply-To: Tomcat Users List 
To: Tomcat Users List 
CC: annou...@tomcat.apache.org , annou...@apache.org, Tomcat 
Developers List 


CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 7.0.0 to 7.0.79

Description:
When running on Windows with HTTP PUTs enabled (e.g. via setting the
readonly initialisation parameter of the Default to false) it was
possible to upload a JSP file to the server via a specially crafted
request. This JSP could then be requested and any code it contained
would be executed by the server.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)

Credit:
This issue was reported responsibly to the Apache Tomcat Security Team
by iswin from 360-sg-lab (360观星实验室)

History:
2017-09-19 Original advisory

References:
[1] http://tomcat.apache.org/security-7.html

-
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

[CORRECTION][SECURITY] CVE-2017-12616 Apache Tomcat Information Disclosure

[Mark Thomas]

The body of the original advisory referred to CVE-2017-7674. This was
incorrect. It was a copy and paste error from a previous Tomcat advisory.

The correct CVE reference is CVE-2017-12616, as per the subject line.

On 19/09/17 11:58, Mark Thomas wrote:
> CVE-2017-7674 Apache Tomcat Information Disclosure
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.80
> 
> Description:
> When using a VirtualDirContext it was possible to bypass security
> constraints and/or view the source code of JSPs for resources served by
> the VirtualDirContext using a specially crafted request.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81
> 
> Credit:
> This issue was identified by the Tomcat Security Team while
> investigating CVE-2017-12615.
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 


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

[CORRECTION][SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

The body of the original advisory referred to CVE-2017-7674. This was
incorrect. It was a copy and paste error from a previous Tomcat advisory.

The correct CVE reference is CVE-2017-12615, as per the subject line.


On 19/09/17 11:58, Mark Thomas wrote:
> CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP Upload
> 
> Severity: Important
> 
> Vendor: The Apache Software Foundation
> 
> Versions Affected:
> Apache Tomcat 7.0.0 to 7.0.79
> 
> Description:
> When running on Windows with HTTP PUTs enabled (e.g. via setting the
> readonly initialisation parameter of the Default to false) it was
> possible to upload a JSP file to the server via a specially crafted
> request. This JSP could then be requested and any code it contained
> would be executed by the server.
> 
> Mitigation:
> Users of the affected versions should apply one of the following
> mitigations:
> - Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)
> 
> Credit:
> This issue was reported responsibly to the Apache Tomcat Security Team
> by iswin from 360-sg-lab (360观星实验室)
> 
> History:
> 2017-09-19 Original advisory
> 
> References:
> [1] http://tomcat.apache.org/security-7.html
> 


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

[SECURITY] CVE-2017-12615 Apache Tomcat Remote Code Execution via JSP upload

[Mark Thomas]

CVE-2017-7674 Apache Tomcat Remote Code Execution via JSP Upload

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 7.0.0 to 7.0.79

Description:
When running on Windows with HTTP PUTs enabled (e.g. via setting the
readonly initialisation parameter of the Default to false) it was
possible to upload a JSP file to the server via a specially crafted
request. This JSP could then be requested and any code it contained
would be executed by the server.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 7.0.81 or later (7.0.80 was not released)

Credit:
This issue was reported responsibly to the Apache Tomcat Security Team
by iswin from 360-sg-lab (360观星实验室)

History:
2017-09-19 Original advisory

References:
[1] http://tomcat.apache.org/security-7.html

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

[SECURITY] CVE-2017-12616 Apache Tomcat Information Disclosure

[Mark Thomas]

CVE-2017-7674 Apache Tomcat Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 7.0.0 to 7.0.80

Description:
When using a VirtualDirContext it was possible to bypass security
constraints and/or view the source code of JSPs for resources served by
the VirtualDirContext using a specially crafted request.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 7.0.81

Credit:
This issue was identified by the Tomcat Security Team while
investigating CVE-2017-12615.

History:
2017-09-19 Original advisory

References:
[1] http://tomcat.apache.org/security-7.html

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

Re: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Mark Thomas]

On 19/09/17 09:51, Peddi, Radhika (Radhika) wrote:
> Hi,
> 
> We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are running 
> performance testing of our application we are seeing below error in 
> catalina.out.
> 
> java.lang.OutOfMemoryError: unable to create new native thread Exception in 
> Catalina.out after upgrading to RHEL 7.4
> 
> Attached is the thread dump.

Attachments get dropped by the list. Best to post the thread dump
somewhere and link to it.

> We are using Tomcat 7.0.69.

That is quite old. There have been a few security vulnerabilities
disclosed since then. If you haven't already, make sure none of them are
a risk for you.

> As per REDHAT we have increased tomcat5 user which used to run Tomcat process 
> in /etc/security/limits.d/20-nproc.conf like below

tomcat5 ? That looks odd. I don't know anything about how RedHat
packages Tomcat but I'd expect that to be tomcat7. It makes me wonder if
there is some old Tomcat 5 configuration hanging around causing problems.

> * soft nproc 4096
> root soft nproc unlimited
> tomcat5 soft nproc 8192
> 
> All the processes are used by Tomcat. If we increase the value to 16K or 32K 
> all threads are consumed and they are in Waiting(Parking) state.
> 
> "http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0 tid=0x7efc8c029800 
> nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)

That is perfectly normal. It is an idle thread waiting for a request to
process.

> "http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0 tid=0x7efc0401e000 
> nid=0x10e7a waiting on condition [0x7ef9bc82f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at 
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)

Likewise.

> They are not getting release.

As expected.

> After some time Tomcat getting stopped automatically.

By what? Or do you mean the OOME?


> You may need the output of below from our setup.
> 
> [root@iqsvtk05 ~]# rpm -qif 
> /opt/coreservices/tomcat-7.0.69/logs/
> Name : tomcat
> Version : 7.0.69
> Release : AV10
> Architecture: x86_64
> Install Date: Fri 18 Aug 2017 01:41:54 AM MDT
> Group : System Environment/Daemons
> Size : 8468465
> License : Apache License, Version 2.0
> Signature : (none)
> Source RPM : tomcat-7.0.69-AV10.src.rpm
> Build Date : Fri 24 Jun 2016 01:59:37 AM MDT
> Build Host : puiqx3650dev03.apac.avaya.com
> Relocations : /usr/share
> Packager : Avaya, Inc> Vendor : Apache Software Foundation
> URL : http://tomcat.apache.org/
> Summary : Core Services Apache Jakarta Servlet/JSP server
> Description : Servlet container for developing Web applications in Java. Used 
> as basis for the
> R

RE: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Peddi, Radhika (Radhika)]

Thanks for the response we will try this.

Regards,
Radhika

-Original Message-
From: Zdeněk Henek [mailto:vrab...@gmail.com] 
Sent: Tuesday, September 19, 2017 2:27 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new 
native thread Exception in Catalina.out after upgrading to RHEL 7.4

Hi,

try configure HTTP NIO
https://urldefense.proofpoint.com/v2/url?u=https-3A__tomcat.apache.org_tomcat-2D7.0-2Ddoc_config_http.html-23NIO-5Fspecific-5Fconfiguration&d=DwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=W2ISzfcNZyKTlMxlNJ9FPQ&m=LAXeta_7sl2gYpz48nwzAR9XkW3dKO7EMeo2ogEl3_4&s=QlTtns7hmM6TFpupVKM93CQfMd1o0tsF1cj3-aPBKOo&e=
or upgrade to Tomcat 8 where HTTP NIO is on by default.

This could help in case your server is able to process the requests e.g.
you have spike where you have to process thousands of requests, but these are 
quick and you don't care much how quickly you get response.

Regards,
Zdenek Henek

út 19. 9. 2017 v 10:51 odesílatel Peddi, Radhika (Radhika) 
napsal:

> Hi,
>
> We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are 
> running performance testing of our application we are seeing below 
> error in catalina.out.
>
> java.lang.OutOfMemoryError: unable to create new native thread 
> Exception in Catalina.out after upgrading to RHEL 7.4
>
> Attached is the thread dump.
>
> We are using Tomcat 7.0.69.
>
> As per REDHAT we have increased tomcat5 user which used to run Tomcat 
> process in /etc/security/limits.d/20-nproc.conf like below
>
> * soft nproc 4096
> root soft nproc unlimited
> tomcat5 soft nproc 8192
>
> All the processes are used by Tomcat. If we increase the value to 16K 
> or 32K all threads are consumed and they are in Waiting(Parking) state.
>
> "http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0
> tid=0x7efc8c029800 nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> "http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0
> tid=0x7efc0401e000 nid=0x10e7a waiting on condition [0x7ef9bc82f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> They are not getting release. After some time Tomcat getting stopped 
> automatically. You may need the output of below from our setup.
>
> [root@iqsvtk05 ~]# rpm -qif 
> /opt/coreservices/tomcat-7.0.69/logs/
> Name : tomcat
> Version : 7.0.69
> Release : AV10
> Architecture: x86_64
> Install Date: Fri 18 Aug 2017 01:41:54 AM MDT Group : System 
> Environment/Daemons Size : 8468465 License : Apache License, Version 
> 2.0 Signature : (none) Source RPM : tomcat-7.0.69-AV10.src.rpm Build 
> Date : Fri 24 Jun

Re: Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Zdeněk Henek]

Hi,

try configure HTTP NIO
https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#NIO_specific_configuration
or upgrade to Tomcat 8 where HTTP NIO is on by default.

This could help in case your server is able to process the requests e.g.
you have spike where you have to process thousands of requests, but these
are quick and you don't care much how quickly you get response.

Regards,
Zdenek Henek

út 19. 9. 2017 v 10:51 odesílatel Peddi, Radhika (Radhika) 
napsal:

> Hi,
>
> We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are running
> performance testing of our application we are seeing below error in
> catalina.out.
>
> java.lang.OutOfMemoryError: unable to create new native thread Exception
> in Catalina.out after upgrading to RHEL 7.4
>
> Attached is the thread dump.
>
> We are using Tomcat 7.0.69.
>
> As per REDHAT we have increased tomcat5 user which used to run Tomcat
> process in /etc/security/limits.d/20-nproc.conf like below
>
> * soft nproc 4096
> root soft nproc unlimited
> tomcat5 soft nproc 8192
>
> All the processes are used by Tomcat. If we increase the value to 16K or
> 32K all threads are consumed and they are in Waiting(Parking) state.
>
> "http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0
> tid=0x7efc8c029800 nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> "http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0
> tid=0x7efc0401e000 nid=0x10e7a waiting on condition [0x7ef9bc82f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x0003c454c008> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
> at
> org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
> They are not getting release. After some time Tomcat getting stopped
> automatically. You may need the output of below from our setup.
>
> [root@iqsvtk05 ~]# rpm -qif
> /opt/coreservices/tomcat-7.0.69/logs/
> Name : tomcat
> Version : 7.0.69
> Release : AV10
> Architecture: x86_64
> Install Date: Fri 18 Aug 2017 01:41:54 AM MDT
> Group : System Environment/Daemons
> Size : 8468465
> License : Apache License, Version 2.0
> Signature : (none)
> Source RPM : tomcat-7.0.69-AV10.src.rpm
> Build Date : Fri 24 Jun 2016 01:59:37 AM MDT
> Build Host : puiqx3650dev03.apac.avaya.com
> Relocations : /usr/share
> Packager : Avaya, Inc.
> Vendor : Apache Software Foundation
> URL : http://tomcat.apache.org/
> Summary : Core Services Apache Jakarta Servlet/JSP server
> Description : Servlet container for developing Web applications in Java.
> Used as basis for the
> Reference Implementation of the Servlet and JSP specificiations. This RPM
> mirrors the layout used by official Tomcat distributions on all other OSes
> and linux variants. If you want a FHS-based package - be warne

Tomcat 7 giving java.lang.OutOfMemoryError: unable to create new native thread Exception in Catalina.out after upgrading to RHEL 7.4

[Peddi, Radhika (Radhika)]

Hi,

We have upgraded RHEL 7.2 to RHEL 7.4. After upgrade when we are running 
performance testing of our application we are seeing below error in 
catalina.out.

java.lang.OutOfMemoryError: unable to create new native thread Exception in 
Catalina.out after upgrading to RHEL 7.4

Attached is the thread dump.

We are using Tomcat 7.0.69.

As per REDHAT we have increased tomcat5 user which used to run Tomcat process 
in /etc/security/limits.d/20-nproc.conf like below

* soft nproc 4096
root soft nproc unlimited
tomcat5 soft nproc 8192

All the processes are used by Tomcat. If we increase the value to 16K or 32K 
all threads are consumed and they are in Waiting(Parking) state.

"http-bio-8443-exec-56" #973 daemon prio=5 os_prio=0 tid=0x7efc8c029800 
nid=0x10e7b waiting on condition [0x7ef9bc7ee000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0003c454c008> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at 
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

"http-bio-8443-exec-55" #972 daemon prio=5 os_prio=0 tid=0x7efc0401e000 
nid=0x10e7a waiting on condition [0x7ef9bc82f000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x0003c454c008> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)
at 
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

They are not getting release. After some time Tomcat getting stopped 
automatically. You may need the output of below from our setup.

[root@iqsvtk05 ~]# rpm -qif 
/opt/coreservices/tomcat-7.0.69/logs/
Name : tomcat
Version : 7.0.69
Release : AV10
Architecture: x86_64
Install Date: Fri 18 Aug 2017 01:41:54 AM MDT
Group : System Environment/Daemons
Size : 8468465
License : Apache License, Version 2.0
Signature : (none)
Source RPM : tomcat-7.0.69-AV10.src.rpm
Build Date : Fri 24 Jun 2016 01:59:37 AM MDT
Build Host : puiqx3650dev03.apac.avaya.com
Relocations : /usr/share
Packager : Avaya, Inc.
Vendor : Apache Software Foundation
URL : http://tomcat.apache.org/
Summary : Core Services Apache Jakarta Servlet/JSP server
Description : Servlet container for developing Web applications in Java. Used 
as basis for the
Reference Implementation of the Servlet and JSP specificiations. This RPM 
mirrors the layout used by official Tomcat distributions on all other OSes and 
linux variants. If you want a FHS-based package - be warned that tomcat may not 
work very well. (TODO: add more warnings !). If you still want FHS-based 
package - please use jpackage.org or an RPM that is using the same exact layout.

Can you please help on this.

Regards,
Radhika

[Bug 47410] Using Request#getStream() while reading parameters

[Volkan Yazıcı]

Hello,

When you try to access the raw InputStream of a x-www-form-urlencoded
servlet request, the stream could have already been indirectly consumed by
a prior access to the parameters (e.g., via
ServletRequest#getParameterMap()) of the request. This feature (bug?) has
already been documented in the section SRV.3.1.1 of the Servlet spec

and there are other people (Bug 47410
) who have been
bitten by this as well.

This indirect stream consumption makes it, to the best of my knowledge,
impossible to mirror the InputStream, which is exactly what we are trying
to achieve in HRRS . Hence, I try to re-construct
the InputStream from request parameters
.
This, as you can imagine, a really nasty hack which I am not fond of
either. Further, to make the things worse, when servlet pushes the form
parameters into request parameter map, it merges them with query parameters
too. Now you need to manually parse both request and query parameters to
figure out the initial form parameters. I am not even talking about lost
parameter ordering. A total shipwreck.

Even if HRRS is the first filter in the list, it is not consuming
InputStream, it is just wrapping the InputStream and passing along the
wrapped request along the chain. Problem is, getParameter() calls in Tomcat
is using an internal reference to the InputStream (that is,
o.a.c.connector.Request#getStream()) and not calling
javax.servlet.ServletRequest#getInputStream(). Hence, InputStream gets
indirectly consumed without the wrapped one getting used at all. Is it
possible to make o.a.c.connector.Request#readPostBody() use
getInputStream() rather than getStream() to solve this problem? Or is there
an easier fix that I am missing?

Best.