Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Thanks Thomas,

I just wanted to know in tomcat is there any way to detect such
long running thread and kill them.

On 6 October 2015 at 01:07, Mark Thomas  wrote:

> On 05/10/2015 16:00, Yogesh Patel wrote:
> > Other 199 process are also for /solr430/update?wt=xml&version=2.2
> HTTP/1.1
> > only
>
> That is surprising. That could be a Solr issue or a Tomcat issue. Best
> to take three thread dumps each 10 to 30 seconds apart and then take a
> look to see what is holding up those threads. Best guess is a deadlock
> or a database issue.
>
> (You still have the potential for thread starvation that will come back
> to bite you later after you fix this issue unless you fix it)
>
> Mark
>
> >
> > On 5 October 2015 at 20:18, Mark Thomas  wrote:
> >
> >> On 05/10/2015 12:58, Yogesh Patel wrote:
> >>> Hi Mark Thomas,
> >>>
> >>> in image it shows Tomcat Manager screen:
> >>> Under "ajp-apr-10003" Section in tomcat manager:
> >>> Max threads: 200 Current thread count:200 Current thread busy :200
> Keeped
> >>> alive socket count :0
> >>>
> >>> *Stage   Time  BSentBRecv  Client VHost
> >>>  Request*
> >>> S  2884466 ms0 KB 184063 KB machineip host
> >>  POST
> >>> /solr430/update?wt=xml&version=2.2 HTTP/1.1
> >>
> >> And the other 199 processors?
> >>
> >> Mark
> >>
> >>
> >>>
> >>> ..
> >>> 
> >>>
> >>>
> >>> On 5 October 2015 at 16:12, Yogesh Patel 
> >> wrote:
> >>>
>  Hi , let me try sending image using attachment , if still its not
> >> viewable
>  then i will find another way.
> 
>  On 5 October 2015 at 16:06, Mark Thomas  wrote:
> 
> > On 05/10/2015 11:28, Yogesh Patel wrote:
> >> Hi Thomas ,
> >>   Please see this image ...have a look at Time
> column
> >
> > The list strips images. If you really want us to look at the image
> (not
> > that I think it will be remotely relevant) upload it somewhere and
> post
> > the URL (make sure it is publicly accessible and doe snot require any
> > form of registration to view it).
> >
> > Mark
> >
> >
> >>
> >>
> >> ​
> >>
> >> On 5 October 2015 at 14:50, Mark Thomas  >> > wrote:
> >>
> >> On 05/10/2015 10:09, Yogesh Patel wrote:
> >> > Hi Thomas,
> >> >
> >> > Connector configuration is like :
> >> >  >> />
> >>
> >> That means you are using the BIO AJP connector.
> >>
> >> You don't have a problem with long running requests.
> >>
> >> You have a problem with thread starvation.
> >>
> >> AJP uses persistent connections.
> >>
> >> BIO requires one thread per connection, regardless of whether or
> >> nor
> >> that connection is processing a request or waiting for the next
> >> one.
> >>
> >> httpd will (eventually, assuming mostly default config) create
> one
> > AJP
> >> connection for each httpd thread. If you have more httpd threads
> > than
> >> Tomcat threads you will eventually reach the point where httpd
> >> can't
> >> create a Tomcat thread it requires and at that point it will
> >> appear
> >> to hang.
> >>
> >> There are several possible fixes:
> >> a) disable connection re-use in httpd for AJP connections
> >> b) use the NIO AJP connector in Tomcat
> >> c) increase maxThreads in Tomcat so it is > max threads in httpd
> >>
> >> For more explanation read this:
> >>
> >
> >>
> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> >> <
> >
> >>
> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> >>
> >>
> >> from slide 29 to 33
> >>
> >> Mark
> >>
> >>
> >>
> >> >
> >> > On 5 October 2015 at 14:17, Mark Thomas  >> > wrote:
> >> >
> >> >> On 05/10/2015 09:07, Yogesh Patel wrote:
> >> >>> Thanks Mark Thomas ,
> >> >>>
> >> >>>Our application is access by Apache TO Tomcat using AJP
> >> Connector.
> >> >>
> >> >> OK. That answers one of the questions I asked. However, you
> > haven't
> >> >> provided the connector configuration.
> >> >>
> >> >>> Problem :
> >> >>> Our application was mostly hanged,after looking at
> tomcat
> >> manager it
> >> >>> shown there are so many long running threads shown.
> >> >>
> >> >> The Tomcat Manager app does not show long running threads. It
> >> does show
> >> >> you how many requests are busy but again, a busy thread is
> not
> >> >> necessarily processing a request.
> >> >>
> >> >>> We want to recognize why so 

Re: configuring login for static content and Servlets

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 10/5/15 3:21 PM, Bill Ross wrote:
> Is it possible to set up a site so that you have to log in to
> access the site at all, either the static content or the servlet
> interface? I have in mind 10-100 users. It seems a simple setup
> like .htaccess (httpd only?) would be perfect if it existed and
> covered static and servlet. Is this doable in Tomcat? I have been
> struggling to get it working in Jetty, but it doesn't seem
> well-supported there.

Adding to Chuck's reply: if you don't want to set up anything more
complicated than ".htaccess" authentication (I think you mean
httpasswd, right?), then what you are looking for is a "UserDatabase"
resource paired with a "UserDatabaseRealm".

If you look at the stock conf/server.xml that ships with Tomcat (8),
you'll see that both of those exist and are configured already by
default. You just need to modify tomcat-users.xml (also included, with
examples which are all commented-out) to define your users.

For reference:

Configuring the Resource (where the data comes from):
http://tomcat.apache.org/tomcat-8.0-doc/jndi-resources-howto.html#UserDa
tabase_Resources

Configuring the Realm (where the authentication happens):
http://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#UserDatabaseRea
lm

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWEyGkAAoJEBzwKT+lPKRYJUEQAMC/2HKmaihmxPmhag7UD/BY
3dTfzbUSKHDtGHv30eiwqyNkPVxZQZPUVskgIDaP7yKX0yv1jLagChjPJ3+Ik2xB
huNjC9e8yN43wvdvi4CEhgDClRO1+oCyIAcu97YmVg6y5CGosz2vLXqexdbeh/vv
he3WWXwGuAWSeS4ua/dEwmd7jayQIpYJqsESA/HVsNxLkRrh9xVccuV6giOaaFUs
Zsw7HGkUnA7aI2MbvjoobqQD8vlazlSpF1juaqalIk+MlEHdQ0/zRXvGInw3VpbQ
ozlhiA80SCsPbaZDTylkM34a9o9qttHO2wU/8+HQ6qeEjNet0M/YJpfFUXo8PdE9
oyrIdEv3iMh3ozFKreOOHLxcf2Ib8c77E7HTuvJcVNhxV7wmvO1ide++X/N6KcrL
FZezTq7ueDETNLEzGpf2wwDGNfl1gfl8ggZmlm82Hqf3Sl+Znzjo156XfCXdkDvU
lASN7ol/v8b8eASi9ePIhYiSRwchQru+5e4c44S8Vo3m833MUxW/6TdgAH0rqN43
YFjuPqAyovIFF2Ge8hf2yV0sxTV2dZ1wRloDsQixyH7T5lb7Yv4uPg7V6c3j9tcY
5xP+29SSsQv3Tn0+oAD/Em9xWsu3dWaCiu2uGCPXMjTGsjOfzYFR/zNlI3pWIFpz
jKUE2SvI+HnIL7Anomp1
=IoD+
-END PGP SIGNATURE-

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

Re: Tomcat bad char issue with new cluster

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Saurav,

On 10/5/15 12:23 PM, Saurav Maulick wrote:
> I know Tomcat 5.5 is very old and this is outdated, but we are
> still using Tomcat 5.5 and we got an issue. Please help.
> 
> Problem description:
> 
> Recently my client has asked me to add two new clusters in the
> production, after adding the clusters we found that these two new
> clusters are not able to handle special characters.

Two new clusters, or two new nodes added to an existing cluster?

> When user copies some data (especially from MS-Word which contains
> double quote) and paste into the application we have found that
> double quote becomes junk character, but these problems only
> persist with newly created clusters not with old clusters.
> 
> While creating the new cluster I just copied the old cluster folder
> and all the clusters are identical except some changes in
> server.xml.
> 
> Could you please help me to resolve this issue?
> 
> NB. UTF-8 char encoding present in the xml files

What is the difference between the conf/server.xml on a "working"
server and one of these new servers that is misbehaving? Identical WAR
files deployed to all servers?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWEx6mAAoJEBzwKT+lPKRYPzIP/iFpPGH+zfPOsgwtqhnqe5ou
5PqaVEJ0G9+854Gs+q19n9Fcug2NHCnjRaDHj/ujhiOjj2phF1KbWtvEOmMeH6rG
QpuPTPr6DJZiEZpnvCaK2tolQEwnO7CqJ1AEqQo/TQ7IzKFx+Ou5SxZ9m8kQeBKg
ZrPt4vBxrASaELSn+vPPzsA2aBzr9OXijO35Gbjf09FCbR7BC/QnucbAaS6b3z2W
jxrFDRzv7QTxSoA9c8QdNPdcJXEbLQF59yf/4JO/Bx68A7apneSWjo9zw9POWfD2
wHysHZJFF8WBbh1lBJXFuyLMT9luu1v4I7nvdYU98S2p9EOqVTnDM84XBVN9xd/r
TbNGvcIErLsXeNRqHaXSCF95KbjMSdeKCYKfroPz9/xEZUWWpdFRm6OLVTY6mF1F
WDJZUltgGT/O6iM0x39rcEnwapX5XUlPgpolhhEJFC4PXZgLpwQQTwhEBACtClVn
30P4brBZYIW1NIR4Vq7yI0ltpf7CT0X3Y7xSvP53yM5zIpcmwQsWVCnle+8XY9bz
4msgAfpp5Xb2q3ovGwrCKahWCeddTofUfgqCBmg7fgvD7K7812rSgjOQ617QgNl5
FZnt9Td79vcWe7I8J1vJdvWTymuydfVMWEu5ptOpORwsGdWVYI/qnOTCl+b8XW7K
oVU1afvuvfBA+abbnz/L
=e9Is
-END PGP SIGNATURE-

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

Re: Class Loader Problems with Tomcat 8 + Ant Task

[Amit Lonkar]

Hi Chris

Any ideas why the Ant Task might be failing in Tomcat 8? 
Yes the application works on a clean fresh tomcat 7 but not on tomcat 8.

We have a Administrator application that is used for patching our scheduling 
software. The patch includes the war files and get deployed to all nodes using 
the Ant Task.

Thanks
Amit

> On Sep 25, 2015, at 2:47 PM, Christopher Schultz 
>  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Amit,
> 
> On 9/24/15 2:24 PM, Amit Lonkar wrote:
>> We are trying to upgrade from Tomcat 7 to Tomcat 8. One of the 
>> functionalities we have is to deploy a war file using the
>> DeployTask class. I have a simple test servlet that uses the
>> DeployClass.
> 
> Stop right there.
> 
> You have a servlet that is using the DeployTask for something? That
> sounds ... astoundingly weird to me. Can you explain this use case?
> The only thing I can think of is a web application used to deploy web
> applications.
> 
>> I keep getting he following exception. I have ant 1.9.6 and 
>> catalina-ant-8.0.26 in the class path. The maven project is
>> attached. Works fine on Tomcat 7.0.64 but not on Tomcat 8.0.26.
>> 
>> *Tomcat Version: *8.0.26 *Java:* jdk1.8.0_45 *OS:* OSX *Class
>> Path:*
>> 
>> * ant-1.9.6 * ant-launcher-1.9.6 * javax.servlet-api-3.1.0 *
>> tomcat-api-8.0.26 * tomcat-catalina-ant-8.0.26 *
>> tomcat-juli-8.0.26 * tomcat-servlet-api-8.0.26 *
>> tomcat-util-8.0.26 * tomcat-util-scan-8.0.26
>> 
>> 
>> *Exception Message:* javax.servlet.ServletException: Servlet
>> execution threw an exception
>> 
>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>> 
>> *root cause*
>> 
>> java.lang.NoClassDefFoundError: org/apache/tools/ant/Task 
>> java.lang.ClassLoader.defineClass1(Native Method) 
>> java.lang.ClassLoader.defineClass(ClassLoader.java:760) 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142
> )
>> 
>> 
> java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>> java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
>> java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>> 
>> 
>> // Exception is thrown when trying to instantiate DeployTask
>> 
>> DeployTask oTask = new DeployTask(); oTask.setAlwaysLog(true); 
>> oTask.setAppend(false); oTask.setCreateEmptyFiles(true); 
>> oTask.setError(oTaskError); oTask.setFailonerror(true); 
>> oTask.setLogError(true); oTask.setOutput(oTaskOutput); 
>> oTask.setPassword("adminManagerScript"); oTask.setPath("/broker"); 
>> oTask.setProject(new Project()); oTask.setTag("v7"); 
>> oTask.setUpdate(true); 
>> oTask.setUrl("http://localhost:8080/manager/text";); 
>> oTask.setUsername("adminManagerScript"); 
>> oTask.setWar("/Users/amitlonkar/Documents/Builds/2015-09-23_1612/v7bro
> ker.war");
>> 
>> 
> oTask.execute();
> 
> This application works on a clean, fresh Tomcat 7 but not on a clean,
> fresh Tomcat 8?
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> 
> iQIcBAEBCAAGBQJWBbL0AAoJEBzwKT+lPKRYPaoP/jZywxrZGTFpXZunqTXO6lPi
> iU/Cg8KGql1/dxK8rs/SINKiJFpk9nsVkOf3596NKjLtHsD5vobzWwvnQyitnI1q
> WXjGX5PgIArZgBvbZOpEDZJpNOPCcJdXisZvhL5cO9qZBY/Pas/98KXKPZgD3LuB
> iMK+lns68CjrzYIRQEGsLBWSRMZSq5Mlo0QQkeD+bHJ/hhKSvAd/Fq+KhPuPxhnm
> 7YxX9VijsMBOWFtlMzn6+8KSOqvnKNTPV/VUzi5+5zHGWxA5JcEUsJlSP4CXpTRn
> HpoPW7d7MnqbHWIJRa6A5jmNe2Dgu/Yqnn0jP/DZ3vldPEkGzsrPK6TEEZ40Av8a
> HSrRpBTfO0YnPhrJJoDTbLHYwDxdt0+Pn7IN7fejdZtBfGHAZe2pvpys27Tc2yni
> 3IkrBY60TZZAmoShd+Db9nft8aAhJtFYpVuewZYpQBovKv9xNmRkuwzTQ1bDxqAc
> a/0wS9d2P4QARYToTD7X8I92Ve7KpTITXrKL6CHTKuzQxGIjpuD4fq/S+Niz2s9X
> zkfGE3HNhklaKZejeBvI34u3UvlyFZERpc3Ghz79NgbH6t+axl2DK8dUxqY8PXbQ
> UclOeihby91Fa5n5sP00LiGOJq9Pq8CFryYp5THbuMbUYZt3uxS53jiBQV2Wcy8q
> vysGmaX3rQK250gUVnj3
> =annF
> -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: configuring login for static content and Servlets

[Caldarale, Charles R]

> From: Bill Ross [mailto:r...@cgl.ucsf.edu] 
> Subject: configuring login for static content and Servlets

> Is it possible to set up a site so that you have to log in to access the site 
> at all, 
> either the static content or the servlet interface?

Read the "Specifying Security Constraints" section of the servlet spec (13.8 in 
the current version) to see how to protect all resources in a webapp.  If you 
want to protect all webapps, you can put the config statements in Tomcat's 
conf/web.xml file, and they will be automatically included in each webapp.

 - Chuck 


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Tomcat 8.0.27 and the tomcat 8 maven plugin

[Wessel van Norel]

I'm trying to get the tomcat 8 maven plugin branch to work with the latest
tomcat 8 release, but I'm struggling with the following change:

http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/webresources/JarResource.java?r1=1643249&r2=1655123&pathrev=1655123

This change breaks the tc8.x branch. I'm now trying to create a JarResource
using a JarResourceSet, but I'm stuck. After seeing that also
/META-INF/MANIFEST.MF files get in the loops where those JarResources are
created I've given up my attempt. I've no clue why the maven plugin needs
to do all this and how I should validate it working correctly again.

Is there a bit of documentation on how to go from the JarResource with a
WebResourceRoot to a JarResource with a AbstractArchiveResourceSet?

Kind regards,
Wessel van Norel

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 16:00, Yogesh Patel wrote:
> Other 199 process are also for /solr430/update?wt=xml&version=2.2 HTTP/1.1
> only

That is surprising. That could be a Solr issue or a Tomcat issue. Best
to take three thread dumps each 10 to 30 seconds apart and then take a
look to see what is holding up those threads. Best guess is a deadlock
or a database issue.

(You still have the potential for thread starvation that will come back
to bite you later after you fix this issue unless you fix it)

Mark

> 
> On 5 October 2015 at 20:18, Mark Thomas  wrote:
> 
>> On 05/10/2015 12:58, Yogesh Patel wrote:
>>> Hi Mark Thomas,
>>>
>>> in image it shows Tomcat Manager screen:
>>> Under "ajp-apr-10003" Section in tomcat manager:
>>> Max threads: 200 Current thread count:200 Current thread busy :200 Keeped
>>> alive socket count :0
>>>
>>> *Stage   Time  BSentBRecv  Client VHost
>>>  Request*
>>> S  2884466 ms0 KB 184063 KB machineip host
>>  POST
>>> /solr430/update?wt=xml&version=2.2 HTTP/1.1
>>
>> And the other 199 processors?
>>
>> Mark
>>
>>
>>>
>>> ..
>>> 
>>>
>>>
>>> On 5 October 2015 at 16:12, Yogesh Patel 
>> wrote:
>>>
 Hi , let me try sending image using attachment , if still its not
>> viewable
 then i will find another way.

 On 5 October 2015 at 16:06, Mark Thomas  wrote:

> On 05/10/2015 11:28, Yogesh Patel wrote:
>> Hi Thomas ,
>>   Please see this image ...have a look at Time column
>
> The list strips images. If you really want us to look at the image (not
> that I think it will be remotely relevant) upload it somewhere and post
> the URL (make sure it is publicly accessible and doe snot require any
> form of registration to view it).
>
> Mark
>
>
>>
>>
>> ​
>>
>> On 5 October 2015 at 14:50, Mark Thomas > > wrote:
>>
>> On 05/10/2015 10:09, Yogesh Patel wrote:
>> > Hi Thomas,
>> >
>> > Connector configuration is like :
>> > > />
>>
>> That means you are using the BIO AJP connector.
>>
>> You don't have a problem with long running requests.
>>
>> You have a problem with thread starvation.
>>
>> AJP uses persistent connections.
>>
>> BIO requires one thread per connection, regardless of whether or
>> nor
>> that connection is processing a request or waiting for the next
>> one.
>>
>> httpd will (eventually, assuming mostly default config) create one
> AJP
>> connection for each httpd thread. If you have more httpd threads
> than
>> Tomcat threads you will eventually reach the point where httpd
>> can't
>> create a Tomcat thread it requires and at that point it will
>> appear
>> to hang.
>>
>> There are several possible fixes:
>> a) disable connection re-use in httpd for AJP connections
>> b) use the NIO AJP connector in Tomcat
>> c) increase maxThreads in Tomcat so it is > max threads in httpd
>>
>> For more explanation read this:
>>
>
>> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>> <
>
>> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>>
>>
>> from slide 29 to 33
>>
>> Mark
>>
>>
>>
>> >
>> > On 5 October 2015 at 14:17, Mark Thomas > > wrote:
>> >
>> >> On 05/10/2015 09:07, Yogesh Patel wrote:
>> >>> Thanks Mark Thomas ,
>> >>>
>> >>>Our application is access by Apache TO Tomcat using AJP
>> Connector.
>> >>
>> >> OK. That answers one of the questions I asked. However, you
> haven't
>> >> provided the connector configuration.
>> >>
>> >>> Problem :
>> >>> Our application was mostly hanged,after looking at tomcat
>> manager it
>> >>> shown there are so many long running threads shown.
>> >>
>> >> The Tomcat Manager app does not show long running threads. It
>> does show
>> >> you how many requests are busy but again, a busy thread is not
>> >> necessarily processing a request.
>> >>
>> >>> We want to recognize why so many threads are running since
>> long time.
>> >>
>> >> Threads are always "running". The key question is are those
> threads
>> >> 'idle' or 'busy'. An idle thread is waiting to be allocated
>> work.
>> A busy
>> >> thread has been allocated work but the manager application
>> can't
>> >> distinguish if that work is 'wait for a request to process' or
>> >> 'processing a request'.
>> >>
>> >

configuring login for static content and Servlets

[Bill Ross]

Is it possible to set up a site so that you have to log in to access the site 
at all, either the static content or the servlet interface? I have in mind 
10-100 users. It seems a simple setup like .htaccess (httpd only?) would be 
perfect if it existed and covered static and servlet. Is this doable in Tomcat? 
I have been struggling to get it working in Jetty, but it doesn't seem 
well-supported there.

Thanks,
Bill

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

Tomcat bad char issue with new cluster

[Saurav Maulick]

Hi All,

I know Tomcat 5.5 is very old and this is outdated, but we are still using
Tomcat 5.5 and we got an issue. Please help.

Problem description:

Recently my client has asked me to add two new clusters in the production,
after adding the clusters we found that these two new clusters are not able
to handle special characters.

When user copies some data (especially from MS-Word which contains double
quote) and paste into the application we have found that double quote
becomes junk character, but these problems only persist with newly created
clusters not with old clusters.

While creating the new cluster I just copied the old cluster folder and all
the clusters are identical except some changes in server.xml.

Could you please help me to resolve this issue?

NB. UTF-8 char encoding present in the xml files

-- 
Thanks and Regards,
Saurav

Re: JSP compilation error Tomcat 8.0.27

[Zorro]

Op 5-10-2015 om 16:27 schreef Mark Thomas:

On 05/10/2015 14:08, Zorro wrote:

Hi,

I installed Tomcat 8.0.27 last weekend and now using it I do get JSP
compilation exceptions.

This is an example causing such an exception:

 

(Active is a String and c: means jstl/core)

If I change it to this

or


Then no exception occurs anymore.

I expected
 and

being proper code and

faulty coding.

Has this to do with the change handling  \${ vs \$ escaping in JSP and EL?

It has. Having reviewed the specs carefully, the JSP spec has to be used
up to ...${ and from }... but what appears between the braces is parsed
according to the rules of the EL spec. The rule about the use of quotes
in attribute values do not apply when parsing the EL.

I'd expect either of these to work:




Yes these 2 work indeed.
I'll stick then with the "on" form.


I'm surprised that


works. I wonder how the on is being interpreted.

Mark


The outcome of the expression is always true.
I suspect that is interpreted as Active == null.

Anyway thanx for looking at it.
I'll remove the backslashes in my JSPs.

Regards,
Harm-Jan


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

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Other 199 process are also for /solr430/update?wt=xml&version=2.2 HTTP/1.1
only

On 5 October 2015 at 20:18, Mark Thomas  wrote:

> On 05/10/2015 12:58, Yogesh Patel wrote:
> > Hi Mark Thomas,
> >
> > in image it shows Tomcat Manager screen:
> > Under "ajp-apr-10003" Section in tomcat manager:
> > Max threads: 200 Current thread count:200 Current thread busy :200 Keeped
> > alive socket count :0
> >
> > *Stage   Time  BSentBRecv  Client VHost
> >  Request*
> > S  2884466 ms0 KB 184063 KB machineip host
>  POST
> > /solr430/update?wt=xml&version=2.2 HTTP/1.1
>
> And the other 199 processors?
>
> Mark
>
>
> >
> > ..
> > 
> >
> >
> > On 5 October 2015 at 16:12, Yogesh Patel 
> wrote:
> >
> >> Hi , let me try sending image using attachment , if still its not
> viewable
> >> then i will find another way.
> >>
> >> On 5 October 2015 at 16:06, Mark Thomas  wrote:
> >>
> >>> On 05/10/2015 11:28, Yogesh Patel wrote:
>  Hi Thomas ,
>    Please see this image ...have a look at Time column
> >>>
> >>> The list strips images. If you really want us to look at the image (not
> >>> that I think it will be remotely relevant) upload it somewhere and post
> >>> the URL (make sure it is publicly accessible and doe snot require any
> >>> form of registration to view it).
> >>>
> >>> Mark
> >>>
> >>>
> 
> 
>  ​
> 
>  On 5 October 2015 at 14:50, Mark Thomas   > wrote:
> 
>  On 05/10/2015 10:09, Yogesh Patel wrote:
>  > Hi Thomas,
>  >
>  > Connector configuration is like :
>  >  />
> 
>  That means you are using the BIO AJP connector.
> 
>  You don't have a problem with long running requests.
> 
>  You have a problem with thread starvation.
> 
>  AJP uses persistent connections.
> 
>  BIO requires one thread per connection, regardless of whether or
> nor
>  that connection is processing a request or waiting for the next
> one.
> 
>  httpd will (eventually, assuming mostly default config) create one
> >>> AJP
>  connection for each httpd thread. If you have more httpd threads
> >>> than
>  Tomcat threads you will eventually reach the point where httpd
> can't
>  create a Tomcat thread it requires and at that point it will
> appear
>  to hang.
> 
>  There are several possible fixes:
>  a) disable connection re-use in httpd for AJP connections
>  b) use the NIO AJP connector in Tomcat
>  c) increase maxThreads in Tomcat so it is > max threads in httpd
> 
>  For more explanation read this:
> 
> >>>
> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>  <
> >>>
> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> 
> 
>  from slide 29 to 33
> 
>  Mark
> 
> 
> 
>  >
>  > On 5 October 2015 at 14:17, Mark Thomas   > wrote:
>  >
>  >> On 05/10/2015 09:07, Yogesh Patel wrote:
>  >>> Thanks Mark Thomas ,
>  >>>
>  >>>Our application is access by Apache TO Tomcat using AJP
>  Connector.
>  >>
>  >> OK. That answers one of the questions I asked. However, you
> >>> haven't
>  >> provided the connector configuration.
>  >>
>  >>> Problem :
>  >>> Our application was mostly hanged,after looking at tomcat
>  manager it
>  >>> shown there are so many long running threads shown.
>  >>
>  >> The Tomcat Manager app does not show long running threads. It
>  does show
>  >> you how many requests are busy but again, a busy thread is not
>  >> necessarily processing a request.
>  >>
>  >>> We want to recognize why so many threads are running since
>  long time.
>  >>
>  >> Threads are always "running". The key question is are those
> >>> threads
>  >> 'idle' or 'busy'. An idle thread is waiting to be allocated
> work.
>  A busy
>  >> thread has been allocated work but the manager application
> can't
>  >> distinguish if that work is 'wait for a request to process' or
>  >> 'processing a request'.
>  >>
>  >>> We want to detect such thread and want to kill these
> stucked
>  thread.
>  >>
>  >> You continue to make the (increasingly unlikely) assumption
> that
> >>> 200
>  >> busy threads mean you have 200 threads processing long running
>  requests.
>  >> Had you provided the connector configuration I asked for (by
> that
>  I mean
>  >> the  elements in server.xml) then I'd be 

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 12:58, Yogesh Patel wrote:
> Hi Mark Thomas,
> 
> in image it shows Tomcat Manager screen:
> Under "ajp-apr-10003" Section in tomcat manager:
> Max threads: 200 Current thread count:200 Current thread busy :200 Keeped
> alive socket count :0
> 
> *Stage   Time  BSentBRecv  Client VHost
>  Request*
> S  2884466 ms0 KB 184063 KB machineip host POST
> /solr430/update?wt=xml&version=2.2 HTTP/1.1

And the other 199 processors?

Mark


> 
> ..
> 
> 
> 
> On 5 October 2015 at 16:12, Yogesh Patel  wrote:
> 
>> Hi , let me try sending image using attachment , if still its not viewable
>> then i will find another way.
>>
>> On 5 October 2015 at 16:06, Mark Thomas  wrote:
>>
>>> On 05/10/2015 11:28, Yogesh Patel wrote:
 Hi Thomas ,
   Please see this image ...have a look at Time column
>>>
>>> The list strips images. If you really want us to look at the image (not
>>> that I think it will be remotely relevant) upload it somewhere and post
>>> the URL (make sure it is publicly accessible and doe snot require any
>>> form of registration to view it).
>>>
>>> Mark
>>>
>>>


 ​

 On 5 October 2015 at 14:50, Mark Thomas >>> > wrote:

 On 05/10/2015 10:09, Yogesh Patel wrote:
 > Hi Thomas,
 >
 > Connector configuration is like :
 > 

 That means you are using the BIO AJP connector.

 You don't have a problem with long running requests.

 You have a problem with thread starvation.

 AJP uses persistent connections.

 BIO requires one thread per connection, regardless of whether or nor
 that connection is processing a request or waiting for the next one.

 httpd will (eventually, assuming mostly default config) create one
>>> AJP
 connection for each httpd thread. If you have more httpd threads
>>> than
 Tomcat threads you will eventually reach the point where httpd can't
 create a Tomcat thread it requires and at that point it will appear
 to hang.

 There are several possible fixes:
 a) disable connection re-use in httpd for AJP connections
 b) use the NIO AJP connector in Tomcat
 c) increase maxThreads in Tomcat so it is > max threads in httpd

 For more explanation read this:

>>> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
 <
>>> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf


 from slide 29 to 33

 Mark



 >
 > On 5 October 2015 at 14:17, Mark Thomas >>> > wrote:
 >
 >> On 05/10/2015 09:07, Yogesh Patel wrote:
 >>> Thanks Mark Thomas ,
 >>>
 >>>Our application is access by Apache TO Tomcat using AJP
 Connector.
 >>
 >> OK. That answers one of the questions I asked. However, you
>>> haven't
 >> provided the connector configuration.
 >>
 >>> Problem :
 >>> Our application was mostly hanged,after looking at tomcat
 manager it
 >>> shown there are so many long running threads shown.
 >>
 >> The Tomcat Manager app does not show long running threads. It
 does show
 >> you how many requests are busy but again, a busy thread is not
 >> necessarily processing a request.
 >>
 >>> We want to recognize why so many threads are running since
 long time.
 >>
 >> Threads are always "running". The key question is are those
>>> threads
 >> 'idle' or 'busy'. An idle thread is waiting to be allocated work.
 A busy
 >> thread has been allocated work but the manager application can't
 >> distinguish if that work is 'wait for a request to process' or
 >> 'processing a request'.
 >>
 >>> We want to detect such thread and want to kill these stucked
 thread.
 >>
 >> You continue to make the (increasingly unlikely) assumption that
>>> 200
 >> busy threads mean you have 200 threads processing long running
 requests.
 >> Had you provided the connector configuration I asked for (by that
 I mean
 >> the  elements in server.xml) then I'd be in a
>>> better
 >> position to tell you what is wrong.
 >>
 >> If you do have 200 long running requests then the
 >> StuckThreadDetectionValve is how you detect them. That fact that
>>> that
 >> valve is not reporting any long running requests should be a big
>>> clue
 >> that your assumptions about what is going on are not correct.
 >>
 >> If, and it is 

Re: Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Mark Thomas]

On 05/10/2015 12:05, Gael Abadin wrote:
> Hello, fellow users.
> 
> I've been trying to configure tomcat to request client certificate
> authentication on a single page, while serving every other SSL page without
> requesting a client certificate (before or after authentication). Depending
> on the configuration I use, one of 2 things happen: either I get a request
> for a client certificate on ANY HTTPS page I visit first, or I do not get a
> request at all, never, even when I launch the browser and go straight to
> the protected page (/my-app-name/public/login/login.xhtml).
> 
> Am I doing something wrong or is this kind of configuration just not
> possible?

That should be possible but you'll need two security constraints. One to
require TLS everywhere and one for the pages where you require
authentication.

You may also hit issues with which connectors support renegotiation
(don't use APR).

Mark

> 
> Here is my web.xml security constraint and login config (I've also tried
> ommitin ):
> 
>   
> 
>   Protected Context
>   /public/login/*
> 
> 
>   CONFIDENTIAL
> 
>   
>   
> CLIENT-CERT
>   
> 
> 
> And here is my server.xml config (I've also tried clientAuth="false" and
> clientAuth="true"):
> 
> 
> 
>   
> 
>   
>className="org.apache.catalina.core.AprLifecycleListener"/>
>   
>   
>   
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
> 
>   
>  factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> name="UserDatabase" pathname="conf/tomcat-users.xml"
> type="org.apache.catalina.UserDatabase"/>
>   
> 
>   
> 
>  redirectPort="443"/>
> 
>  port="443" protocol="org.apache.coyote.http11.Http11Protocol"
> scheme="https" secure="true" sslProtocol="TLS"/>
> 
> 
> 
> 
>   
>  resourceName="UserDatabase"/>
>   
>unpackWARs="true">
>  directory="logs" pattern="%h %l %u %t "%r" %s %b"
> prefix="localhost_access_log." suffix=".txt"/>
>  reloadable="true" source="org.eclipse.jst.jee.server:cividas-core-web"/>
>   
> 
>   
> 
> 
> It is my first Tomcat SSL client cert set up so I must be missing
> something. Hope you may help me see it :-)
> 
> Cheers,
> 


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

Re: JSP compilation error Tomcat 8.0.27

[Mark Thomas]

On 05/10/2015 14:08, Zorro wrote:
> Hi,
> 
> I installed Tomcat 8.0.27 last weekend and now using it I do get JSP
> compilation exceptions.
> 
> This is an example causing such an exception:
> 
> 
> 
> (Active is a String and c: means jstl/core)
> 
> If I change it to this
> 
> or
> 
> 
> Then no exception occurs anymore.
> 
> I expected
>  and
> 
> being proper code and
> 
> faulty coding.
> 
> Has this to do with the change handling  \${ vs \$ escaping in JSP and EL?

It has. Having reviewed the specs carefully, the JSP spec has to be used
up to ...${ and from }... but what appears between the braces is parsed
according to the rules of the EL spec. The rule about the use of quotes
in attribute values do not apply when parsing the EL.

I'd expect either of these to work:



I'm surprised that


works. I wonder how the on is being interpreted.

Mark


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

Re: Rewriting entire request /body in Servlet Filter not working as expected

[Michael Greco]

On Mon, Oct 5, 2015 at 3:30 AM, Mark Thomas  wrote:

> On 04/10/2015 19:03, Michael Greco wrote:
> > First time post here.
> >
> > Using :
> > Tomcat 8.0.26
> > JDK1.8.0 update 51
> > Apache MyFaces 2.2.8.
> > Maven build of webapp war file
> > Chrome  45.0.2454.101 m 64 bit
> > Windows 7 64 bit
> >
> > Trying to rewrite the entire request body in a filter using a http
> request
> > wrapper.  Not entirely sure if this is the right approach or even
> possible
> > but researching similar examples it seems this approach should work.
> > Created a simple test case with a one page test app, expecting the
> > index.xhtml page's text value of  "Welcome" to be replaced with the text
> > "NEW TEXT HERE" found in the filter code, but I only get "Welcome" back
> > when the page is rendered in the browser.
> >
> > Below is what I have in the index page, the filter and the web.xml and
> the
> > pom.xml.  The reason I can see is that the getInputStream() or
> getReader()
> > calls are never called by the FacesServlet in the extended
> > HttpServletRequestWrapper.  I did override the getParameter function to
> put
> > some simple debug output in there to ensure the wrapped request was
> > actually used, so I know it's definitely getting into this class but not
> > calling the methods that would return it the new body content.
> >
> > I even tried to re-read the entire request in the getParametersMap() from
> > examples I found on the web, but this didn't seen to do the job either.
> It
> > seems that the request body is somehow cached somewhere / somehow and not
> > changable?
> >
> > Thanks in advance for any insight on this.
>
> First of all welcome files should be exactly that. Files. They should
> not include paths. There is no guarantee that 'faces/index.html' is
> going to work as you think it will and some containers may reject the
> configuration as invalid. That Tomcat lets you get away with this is
> fortunate and - now that I know about it - likely to change in future
> releases.
>
> You seem to be confusing reading the static resource from the file
> system and reading the request body. The request body is the data sent
> by the client with the HTTP request. The static resource (index.xhtml)
> is read from the file system.
>
> I assume that FacesServlet has its own static resource handling and that
> a request for /faces/index.xhtml is expected to return the content
> listed for index.html below.
>
> The FacesServlet will open an input stream but not to the request body.
> It will open one for the static resource on the file system. It will
> then copy those bytes to the response output stream. At no point will it
> attempt to read the request body (unless it is a POST request with
> parameters).
>
> If you want to modify the response body then you need to wrap the
> response and provide Writer and OutputStream implementations that make
> the modifications you require. The simplest way is to buffer the entire
> response body and then edit it but that can get expensive in terms of
> memory. It will be more efficient to use fixed buffer but then more
> complex to ensure your desired edits take place.
>
> Mark
>
> >
> > index page code (index.xhtml) :
> >
> -
> > 
> >  >   xmlns="http://www.w3.org/1999/xhtml";
> >   xmlns:jsf="http://xmlns.jcp.org/jsf";
> >   xmlns:h="http://xmlns.jcp.org/jsf/html";>
> > 
> > 
> > Test Webapp
> > 
> > 
> > Welcome
> > 
> > 
> >
> > Filter code :
> >
> --
> > package com.testwebapp.reqrewrite.filter;
> >
> > import java.io.BufferedReader;
> > import java.io.ByteArrayInputStream;
> > import java.io.IOException;
> > import java.io.InputStreamReader;
> >
> > import javax.servlet.Filter;
> > import javax.servlet.FilterChain;
> > import javax.servlet.FilterConfig;
> > import javax.servlet.ReadListener;
> > import javax.servlet.ServletException;
> > import javax.servlet.ServletInputStream;
> > import javax.servlet.ServletRequest;
> > import javax.servlet.ServletResponse;
> > import javax.servlet.http.HttpServletRequest;
> > import javax.servlet.http.HttpServletRequestWrapper;
> >
> > public class RewriteBodyTestFilter implements Filter {
> >
> > public void init(FilterConfig filterConfig) throws ServletException {
> > return;
> > }
> >
> > public void doFilter(ServletRequest request, ServletResponse response,
> > FilterChain chain)
> > throws IOException, ServletException {
> > String newReqBody = new String("NEW TEXT HERE");
> > HttpServletRequest req = (HttpServletRequest)request;
> > RewriteBodyRequestWrapper rewriteBodyRequestWrapper = new
> > RewriteBodyRequestWrapper(req, newReqBody);
> > chain.doFilter(rewriteBodyRequestWrapper, response);
> > }
> >
> > public void destroy() {
> > return;
> > }
> > class RewriteBodyRequestWrapper extends HttpServletRequestWrapper {
> >
> > private byte[] buffer;
> >
> > public RewriteBodyRequ

JSP compilation error Tomcat 8.0.27

[Zorro]

Hi,

I installed Tomcat 8.0.27 last weekend and now using it I do get JSP 
compilation exceptions.


This is an example causing such an exception:



(Active is a String and c: means jstl/core)

If I change it to this

or


Then no exception occurs anymore.

I expected
 and

being proper code and

faulty coding.

Has this to do with the change handling  \${ vs \$ escaping in JSP and EL?

Regards,
Harm-Jan Zwinderman


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

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Hi Mark Thomas,

in image it shows Tomcat Manager screen:
Under "ajp-apr-10003" Section in tomcat manager:
Max threads: 200 Current thread count:200 Current thread busy :200 Keeped
alive socket count :0

*Stage   Time  BSentBRecv  Client VHost
 Request*
S  2884466 ms0 KB 184063 KB machineip host POST
/solr430/update?wt=xml&version=2.2 HTTP/1.1

..



On 5 October 2015 at 16:12, Yogesh Patel  wrote:

> Hi , let me try sending image using attachment , if still its not viewable
> then i will find another way.
>
> On 5 October 2015 at 16:06, Mark Thomas  wrote:
>
>> On 05/10/2015 11:28, Yogesh Patel wrote:
>> > Hi Thomas ,
>> >   Please see this image ...have a look at Time column
>>
>> The list strips images. If you really want us to look at the image (not
>> that I think it will be remotely relevant) upload it somewhere and post
>> the URL (make sure it is publicly accessible and doe snot require any
>> form of registration to view it).
>>
>> Mark
>>
>>
>> >
>> >
>> > ​
>> >
>> > On 5 October 2015 at 14:50, Mark Thomas > > > wrote:
>> >
>> > On 05/10/2015 10:09, Yogesh Patel wrote:
>> > > Hi Thomas,
>> > >
>> > > Connector configuration is like :
>> > > 
>> >
>> > That means you are using the BIO AJP connector.
>> >
>> > You don't have a problem with long running requests.
>> >
>> > You have a problem with thread starvation.
>> >
>> > AJP uses persistent connections.
>> >
>> > BIO requires one thread per connection, regardless of whether or nor
>> > that connection is processing a request or waiting for the next one.
>> >
>> > httpd will (eventually, assuming mostly default config) create one
>> AJP
>> > connection for each httpd thread. If you have more httpd threads
>> than
>> > Tomcat threads you will eventually reach the point where httpd can't
>> > create a Tomcat thread it requires and at that point it will appear
>> > to hang.
>> >
>> > There are several possible fixes:
>> > a) disable connection re-use in httpd for AJP connections
>> > b) use the NIO AJP connector in Tomcat
>> > c) increase maxThreads in Tomcat so it is > max threads in httpd
>> >
>> > For more explanation read this:
>> >
>> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>> > <
>> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>> >
>> >
>> > from slide 29 to 33
>> >
>> > Mark
>> >
>> >
>> >
>> > >
>> > > On 5 October 2015 at 14:17, Mark Thomas > > > wrote:
>> > >
>> > >> On 05/10/2015 09:07, Yogesh Patel wrote:
>> > >>> Thanks Mark Thomas ,
>> > >>>
>> > >>>Our application is access by Apache TO Tomcat using AJP
>> > Connector.
>> > >>
>> > >> OK. That answers one of the questions I asked. However, you
>> haven't
>> > >> provided the connector configuration.
>> > >>
>> > >>> Problem :
>> > >>> Our application was mostly hanged,after looking at tomcat
>> > manager it
>> > >>> shown there are so many long running threads shown.
>> > >>
>> > >> The Tomcat Manager app does not show long running threads. It
>> > does show
>> > >> you how many requests are busy but again, a busy thread is not
>> > >> necessarily processing a request.
>> > >>
>> > >>> We want to recognize why so many threads are running since
>> > long time.
>> > >>
>> > >> Threads are always "running". The key question is are those
>> threads
>> > >> 'idle' or 'busy'. An idle thread is waiting to be allocated work.
>> > A busy
>> > >> thread has been allocated work but the manager application can't
>> > >> distinguish if that work is 'wait for a request to process' or
>> > >> 'processing a request'.
>> > >>
>> > >>> We want to detect such thread and want to kill these stucked
>> > thread.
>> > >>
>> > >> You continue to make the (increasingly unlikely) assumption that
>> 200
>> > >> busy threads mean you have 200 threads processing long running
>> > requests.
>> > >> Had you provided the connector configuration I asked for (by that
>> > I mean
>> > >> the  elements in server.xml) then I'd be in a
>> better
>> > >> position to tell you what is wrong.
>> > >>
>> > >> If you do have 200 long running requests then the
>> > >> StuckThreadDetectionValve is how you detect them. That fact that
>> that
>> > >> valve is not reporting any long running requests should be a big
>> clue
>> > >> that your assumptions about what is going on are not correct.
>> > >>
>> > >> If, and it is a big if, you did have 200 concurrent long running
>> > >> requests then there is no guaranteed way to stop them. If your
>> > >> app

Demand CLIENT-CERT only on certain pages but demand SSL in all pages

[Gael Abadin]

Hello, fellow users.

I've been trying to configure tomcat to request client certificate
authentication on a single page, while serving every other SSL page without
requesting a client certificate (before or after authentication). Depending
on the configuration I use, one of 2 things happen: either I get a request
for a client certificate on ANY HTTPS page I visit first, or I do not get a
request at all, never, even when I launch the browser and go straight to
the protected page (/my-app-name/public/login/login.xhtml).

Am I doing something wrong or is this kind of configuration just not
possible?

Here is my web.xml security constraint and login config (I've also tried
ommitin ):

  

  Protected Context
  /public/login/*


  CONFIDENTIAL

  
  
CLIENT-CERT
  


And here is my server.xml config (I've also tried clientAuth="false" and
clientAuth="true"):



  

  
  
  
  
  
  
  
  

  

  

  








  

  
  


  

  


It is my first Tomcat SSL client cert set up so I must be missing
something. Hope you may help me see it :-)

Cheers,

-- 



.

Alberto Gael Abadin Martinez
Junior Developer

[image: IMATIA]

www.imatia.com

*Tel: *+34 986 342 774 ext 4531

*Email: *gael.aba...@imatia.com
Edificio CITEXVI
Fonte das Abelleiras, s/n - Local 27
36310 Vigo (Pontevedra)
España

.



.

Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede
contener información confidencial, siendo para uso exclusivo del
destinatario. Queda prohibida su divulgación copia o distribución a
terceros sin la autorización expresa del remitente. Si usted ha recibido
este mensaje erróneamente, se ruega lo notifique al remitente y proceda a
su borrado. Gracias por su colaboración.
This message, and in the case of any file annexed to it, can have
confidential information, and it is exclusively for the use of the
addressee of the message. It is strictly forbidden to spread a copy or
distribute to third parties, without the express order of the sender. If
you have received this message mistakenly, we request you to notify to the
sender, and please be sure to erase it. Thank you for your collaboration.

.

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Hi , let me try sending image using attachment , if still its not viewable
then i will find another way.

On 5 October 2015 at 16:06, Mark Thomas  wrote:

> On 05/10/2015 11:28, Yogesh Patel wrote:
> > Hi Thomas ,
> >   Please see this image ...have a look at Time column
>
> The list strips images. If you really want us to look at the image (not
> that I think it will be remotely relevant) upload it somewhere and post
> the URL (make sure it is publicly accessible and doe snot require any
> form of registration to view it).
>
> Mark
>
>
> >
> >
> > ​
> >
> > On 5 October 2015 at 14:50, Mark Thomas  > > wrote:
> >
> > On 05/10/2015 10:09, Yogesh Patel wrote:
> > > Hi Thomas,
> > >
> > > Connector configuration is like :
> > > 
> >
> > That means you are using the BIO AJP connector.
> >
> > You don't have a problem with long running requests.
> >
> > You have a problem with thread starvation.
> >
> > AJP uses persistent connections.
> >
> > BIO requires one thread per connection, regardless of whether or nor
> > that connection is processing a request or waiting for the next one.
> >
> > httpd will (eventually, assuming mostly default config) create one
> AJP
> > connection for each httpd thread. If you have more httpd threads than
> > Tomcat threads you will eventually reach the point where httpd can't
> > create a Tomcat thread it requires and at that point it will appear
> > to hang.
> >
> > There are several possible fixes:
> > a) disable connection re-use in httpd for AJP connections
> > b) use the NIO AJP connector in Tomcat
> > c) increase maxThreads in Tomcat so it is > max threads in httpd
> >
> > For more explanation read this:
> >
> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> > <
> http://people.apache.org/%7Emarkt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> >
> >
> > from slide 29 to 33
> >
> > Mark
> >
> >
> >
> > >
> > > On 5 October 2015 at 14:17, Mark Thomas  > > wrote:
> > >
> > >> On 05/10/2015 09:07, Yogesh Patel wrote:
> > >>> Thanks Mark Thomas ,
> > >>>
> > >>>Our application is access by Apache TO Tomcat using AJP
> > Connector.
> > >>
> > >> OK. That answers one of the questions I asked. However, you
> haven't
> > >> provided the connector configuration.
> > >>
> > >>> Problem :
> > >>> Our application was mostly hanged,after looking at tomcat
> > manager it
> > >>> shown there are so many long running threads shown.
> > >>
> > >> The Tomcat Manager app does not show long running threads. It
> > does show
> > >> you how many requests are busy but again, a busy thread is not
> > >> necessarily processing a request.
> > >>
> > >>> We want to recognize why so many threads are running since
> > long time.
> > >>
> > >> Threads are always "running". The key question is are those
> threads
> > >> 'idle' or 'busy'. An idle thread is waiting to be allocated work.
> > A busy
> > >> thread has been allocated work but the manager application can't
> > >> distinguish if that work is 'wait for a request to process' or
> > >> 'processing a request'.
> > >>
> > >>> We want to detect such thread and want to kill these stucked
> > thread.
> > >>
> > >> You continue to make the (increasingly unlikely) assumption that
> 200
> > >> busy threads mean you have 200 threads processing long running
> > requests.
> > >> Had you provided the connector configuration I asked for (by that
> > I mean
> > >> the  elements in server.xml) then I'd be in a
> better
> > >> position to tell you what is wrong.
> > >>
> > >> If you do have 200 long running requests then the
> > >> StuckThreadDetectionValve is how you detect them. That fact that
> that
> > >> valve is not reporting any long running requests should be a big
> clue
> > >> that your assumptions about what is going on are not correct.
> > >>
> > >> If, and it is a big if, you did have 200 concurrent long running
> > >> requests then there is no guaranteed way to stop them. If your
> > >> application checks for interrupts (most don't) then the
> > >> StuckThreadDetectionValve can interrupt them which should
> > terminate the
> > >> processing of that request but the time it would take to code the
> > >> application to handle that properly would normally be better spent
> > >> fixing the root cause of the long running request.
> > >>
> > >> Mark
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On 5 October 2015 at 13:11, Mark Thomas  > > wrote:
> > >>>
> >  On 05/10/2015 07:54, Yogesh Patel wr

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 11:28, Yogesh Patel wrote:
> Hi Thomas , 
>   Please see this image ...have a look at Time column

The list strips images. If you really want us to look at the image (not
that I think it will be remotely relevant) upload it somewhere and post
the URL (make sure it is publicly accessible and doe snot require any
form of registration to view it).

Mark


> 
> 
> ​
> 
> On 5 October 2015 at 14:50, Mark Thomas  > wrote:
> 
> On 05/10/2015 10:09, Yogesh Patel wrote:
> > Hi Thomas,
> >
> > Connector configuration is like :
> > 
> 
> That means you are using the BIO AJP connector.
> 
> You don't have a problem with long running requests.
> 
> You have a problem with thread starvation.
> 
> AJP uses persistent connections.
> 
> BIO requires one thread per connection, regardless of whether or nor
> that connection is processing a request or waiting for the next one.
> 
> httpd will (eventually, assuming mostly default config) create one AJP
> connection for each httpd thread. If you have more httpd threads than
> Tomcat threads you will eventually reach the point where httpd can't
> create a Tomcat thread it requires and at that point it will appear
> to hang.
> 
> There are several possible fixes:
> a) disable connection re-use in httpd for AJP connections
> b) use the NIO AJP connector in Tomcat
> c) increase maxThreads in Tomcat so it is > max threads in httpd
> 
> For more explanation read this:
> 
> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
> 
> 
> 
> from slide 29 to 33
> 
> Mark
> 
> 
> 
> >
> > On 5 October 2015 at 14:17, Mark Thomas  > wrote:
> >
> >> On 05/10/2015 09:07, Yogesh Patel wrote:
> >>> Thanks Mark Thomas ,
> >>>
> >>>Our application is access by Apache TO Tomcat using AJP
> Connector.
> >>
> >> OK. That answers one of the questions I asked. However, you haven't
> >> provided the connector configuration.
> >>
> >>> Problem :
> >>> Our application was mostly hanged,after looking at tomcat
> manager it
> >>> shown there are so many long running threads shown.
> >>
> >> The Tomcat Manager app does not show long running threads. It
> does show
> >> you how many requests are busy but again, a busy thread is not
> >> necessarily processing a request.
> >>
> >>> We want to recognize why so many threads are running since
> long time.
> >>
> >> Threads are always "running". The key question is are those threads
> >> 'idle' or 'busy'. An idle thread is waiting to be allocated work.
> A busy
> >> thread has been allocated work but the manager application can't
> >> distinguish if that work is 'wait for a request to process' or
> >> 'processing a request'.
> >>
> >>> We want to detect such thread and want to kill these stucked
> thread.
> >>
> >> You continue to make the (increasingly unlikely) assumption that 200
> >> busy threads mean you have 200 threads processing long running
> requests.
> >> Had you provided the connector configuration I asked for (by that
> I mean
> >> the  elements in server.xml) then I'd be in a better
> >> position to tell you what is wrong.
> >>
> >> If you do have 200 long running requests then the
> >> StuckThreadDetectionValve is how you detect them. That fact that that
> >> valve is not reporting any long running requests should be a big clue
> >> that your assumptions about what is going on are not correct.
> >>
> >> If, and it is a big if, you did have 200 concurrent long running
> >> requests then there is no guaranteed way to stop them. If your
> >> application checks for interrupts (most don't) then the
> >> StuckThreadDetectionValve can interrupt them which should
> terminate the
> >> processing of that request but the time it would take to code the
> >> application to handle that properly would normally be better spent
> >> fixing the root cause of the long running request.
> >>
> >> Mark
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 5 October 2015 at 13:11, Mark Thomas  > wrote:
> >>>
>  On 05/10/2015 07:54, Yogesh Patel wrote:
> > We are facing issues with long running thread in
> tomcat . we
> >> are
> > using Tomcat-7.0.47.Tomcat manager shows Current busy threads
> : 200,
> > application  gets stucked due to these long running threads.
> 
>  What makes you think you have issues with long running threads?
> A busy
>  thread isn't necessari

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Hi Thomas ,
  Please see this image ...have a look at Time column


​

On 5 October 2015 at 14:50, Mark Thomas  wrote:

> On 05/10/2015 10:09, Yogesh Patel wrote:
> > Hi Thomas,
> >
> > Connector configuration is like :
> > 
>
> That means you are using the BIO AJP connector.
>
> You don't have a problem with long running requests.
>
> You have a problem with thread starvation.
>
> AJP uses persistent connections.
>
> BIO requires one thread per connection, regardless of whether or nor
> that connection is processing a request or waiting for the next one.
>
> httpd will (eventually, assuming mostly default config) create one AJP
> connection for each httpd thread. If you have more httpd threads than
> Tomcat threads you will eventually reach the point where httpd can't
> create a Tomcat thread it requires and at that point it will appear to
> hang.
>
> There are several possible fixes:
> a) disable connection re-use in httpd for AJP connections
> b) use the NIO AJP connector in Tomcat
> c) increase maxThreads in Tomcat so it is > max threads in httpd
>
> For more explanation read this:
>
> http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf
>
> from slide 29 to 33
>
> Mark
>
>
>
> >
> > On 5 October 2015 at 14:17, Mark Thomas  wrote:
> >
> >> On 05/10/2015 09:07, Yogesh Patel wrote:
> >>> Thanks Mark Thomas ,
> >>>
> >>>Our application is access by Apache TO Tomcat using AJP Connector.
> >>
> >> OK. That answers one of the questions I asked. However, you haven't
> >> provided the connector configuration.
> >>
> >>> Problem :
> >>> Our application was mostly hanged,after looking at tomcat manager
> it
> >>> shown there are so many long running threads shown.
> >>
> >> The Tomcat Manager app does not show long running threads. It does show
> >> you how many requests are busy but again, a busy thread is not
> >> necessarily processing a request.
> >>
> >>> We want to recognize why so many threads are running since long
> time.
> >>
> >> Threads are always "running". The key question is are those threads
> >> 'idle' or 'busy'. An idle thread is waiting to be allocated work. A busy
> >> thread has been allocated work but the manager application can't
> >> distinguish if that work is 'wait for a request to process' or
> >> 'processing a request'.
> >>
> >>> We want to detect such thread and want to kill these stucked
> thread.
> >>
> >> You continue to make the (increasingly unlikely) assumption that 200
> >> busy threads mean you have 200 threads processing long running requests.
> >> Had you provided the connector configuration I asked for (by that I mean
> >> the  elements in server.xml) then I'd be in a better
> >> position to tell you what is wrong.
> >>
> >> If you do have 200 long running requests then the
> >> StuckThreadDetectionValve is how you detect them. That fact that that
> >> valve is not reporting any long running requests should be a big clue
> >> that your assumptions about what is going on are not correct.
> >>
> >> If, and it is a big if, you did have 200 concurrent long running
> >> requests then there is no guaranteed way to stop them. If your
> >> application checks for interrupts (most don't) then the
> >> StuckThreadDetectionValve can interrupt them which should terminate the
> >> processing of that request but the time it would take to code the
> >> application to handle that properly would normally be better spent
> >> fixing the root cause of the long running request.
> >>
> >> Mark
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 5 October 2015 at 13:11, Mark Thomas  wrote:
> >>>
>  On 05/10/2015 07:54, Yogesh Patel wrote:
> > We are facing issues with long running thread in tomcat . we
> >> are
> > using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> > application  gets stucked due to these long running threads.
> 
>  What makes you think you have issues with long running threads? A busy
>  thread isn't necessarily processing a request. Configuration errors
>  leading to thread starvation are a more typical cause of the symptom
> you
>  describe rather than long running threads in the application.
> 
> >  We implemented StuckThreadDetectionValve in server.xml(
>  >
> > className="org.apache.catalina.valves.StuckThreadDetectionValve"
> >
> > threshold="60" />), but it  could not help out.
> 
>  Why not? Again, this suggests that long running threads aren't the
> >> problem.
> 
> >So we implemented custom StuckThreadDetectionValve by
> extending
> > StuckThreadDetectionValve from
> > catalina, it only goes to "constructor","initInternal",and in
>  "invoke"(when
> > action fires), it does not go to function "getStuckThreadNames()"
> even
> > after threshold time.How to achieve the same.Is there any way to
> detect
> > stucked thread and kill them?
> 
> >

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 10:09, Yogesh Patel wrote:
> Hi Thomas,
> 
> Connector configuration is like :
> 

That means you are using the BIO AJP connector.

You don't have a problem with long running requests.

You have a problem with thread starvation.

AJP uses persistent connections.

BIO requires one thread per connection, regardless of whether or nor
that connection is processing a request or waiting for the next one.

httpd will (eventually, assuming mostly default config) create one AJP
connection for each httpd thread. If you have more httpd threads than
Tomcat threads you will eventually reach the point where httpd can't
create a Tomcat thread it requires and at that point it will appear to hang.

There are several possible fixes:
a) disable connection re-use in httpd for AJP connections
b) use the NIO AJP connector in Tomcat
c) increase maxThreads in Tomcat so it is > max threads in httpd

For more explanation read this:
http://people.apache.org/~markt/presentations/2015-04-15-Tomcat-clustering-part-1-reverse-proxies.pdf

from slide 29 to 33

Mark



> 
> On 5 October 2015 at 14:17, Mark Thomas  wrote:
> 
>> On 05/10/2015 09:07, Yogesh Patel wrote:
>>> Thanks Mark Thomas ,
>>>
>>>Our application is access by Apache TO Tomcat using AJP Connector.
>>
>> OK. That answers one of the questions I asked. However, you haven't
>> provided the connector configuration.
>>
>>> Problem :
>>> Our application was mostly hanged,after looking at tomcat manager it
>>> shown there are so many long running threads shown.
>>
>> The Tomcat Manager app does not show long running threads. It does show
>> you how many requests are busy but again, a busy thread is not
>> necessarily processing a request.
>>
>>> We want to recognize why so many threads are running since long time.
>>
>> Threads are always "running". The key question is are those threads
>> 'idle' or 'busy'. An idle thread is waiting to be allocated work. A busy
>> thread has been allocated work but the manager application can't
>> distinguish if that work is 'wait for a request to process' or
>> 'processing a request'.
>>
>>> We want to detect such thread and want to kill these stucked thread.
>>
>> You continue to make the (increasingly unlikely) assumption that 200
>> busy threads mean you have 200 threads processing long running requests.
>> Had you provided the connector configuration I asked for (by that I mean
>> the  elements in server.xml) then I'd be in a better
>> position to tell you what is wrong.
>>
>> If you do have 200 long running requests then the
>> StuckThreadDetectionValve is how you detect them. That fact that that
>> valve is not reporting any long running requests should be a big clue
>> that your assumptions about what is going on are not correct.
>>
>> If, and it is a big if, you did have 200 concurrent long running
>> requests then there is no guaranteed way to stop them. If your
>> application checks for interrupts (most don't) then the
>> StuckThreadDetectionValve can interrupt them which should terminate the
>> processing of that request but the time it would take to code the
>> application to handle that properly would normally be better spent
>> fixing the root cause of the long running request.
>>
>> Mark
>>
>>>
>>>
>>>
>>>
>>>
>>> On 5 October 2015 at 13:11, Mark Thomas  wrote:
>>>
 On 05/10/2015 07:54, Yogesh Patel wrote:
> We are facing issues with long running thread in tomcat . we
>> are
> using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> application  gets stucked due to these long running threads.

 What makes you think you have issues with long running threads? A busy
 thread isn't necessarily processing a request. Configuration errors
 leading to thread starvation are a more typical cause of the symptom you
 describe rather than long running threads in the application.

>  We implemented StuckThreadDetectionValve in server.xml( 
> className="org.apache.catalina.valves.StuckThreadDetectionValve"
>
> threshold="60" />), but it  could not help out.

 Why not? Again, this suggests that long running threads aren't the
>> problem.

>So we implemented custom StuckThreadDetectionValve by extending
> StuckThreadDetectionValve from
> catalina, it only goes to "constructor","initInternal",and in
 "invoke"(when
> action fires), it does not go to function "getStuckThreadNames()" even
> after threshold time.How to achieve the same.Is there any way to detect
> stucked thread and kill them?

 First of all your invoke() method fails to call super.invoke() so the
 Valve is never going to do anything.

 Secondly, if the original valve didn't work adding a bunch of
 System.out.println() lines isn't going to magically make it work.

 Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
 is no surprise that you never see a ca

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Hi Thomas,

Connector configuration is like :


On 5 October 2015 at 14:17, Mark Thomas  wrote:

> On 05/10/2015 09:07, Yogesh Patel wrote:
> > Thanks Mark Thomas ,
> >
> >Our application is access by Apache TO Tomcat using AJP Connector.
>
> OK. That answers one of the questions I asked. However, you haven't
> provided the connector configuration.
>
> > Problem :
> > Our application was mostly hanged,after looking at tomcat manager it
> > shown there are so many long running threads shown.
>
> The Tomcat Manager app does not show long running threads. It does show
> you how many requests are busy but again, a busy thread is not
> necessarily processing a request.
>
> > We want to recognize why so many threads are running since long time.
>
> Threads are always "running". The key question is are those threads
> 'idle' or 'busy'. An idle thread is waiting to be allocated work. A busy
> thread has been allocated work but the manager application can't
> distinguish if that work is 'wait for a request to process' or
> 'processing a request'.
>
> > We want to detect such thread and want to kill these stucked thread.
>
> You continue to make the (increasingly unlikely) assumption that 200
> busy threads mean you have 200 threads processing long running requests.
> Had you provided the connector configuration I asked for (by that I mean
> the  elements in server.xml) then I'd be in a better
> position to tell you what is wrong.
>
> If you do have 200 long running requests then the
> StuckThreadDetectionValve is how you detect them. That fact that that
> valve is not reporting any long running requests should be a big clue
> that your assumptions about what is going on are not correct.
>
> If, and it is a big if, you did have 200 concurrent long running
> requests then there is no guaranteed way to stop them. If your
> application checks for interrupts (most don't) then the
> StuckThreadDetectionValve can interrupt them which should terminate the
> processing of that request but the time it would take to code the
> application to handle that properly would normally be better spent
> fixing the root cause of the long running request.
>
> Mark
>
> >
> >
> >
> >
> >
> > On 5 October 2015 at 13:11, Mark Thomas  wrote:
> >
> >> On 05/10/2015 07:54, Yogesh Patel wrote:
> >>> We are facing issues with long running thread in tomcat . we
> are
> >>> using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> >>> application  gets stucked due to these long running threads.
> >>
> >> What makes you think you have issues with long running threads? A busy
> >> thread isn't necessarily processing a request. Configuration errors
> >> leading to thread starvation are a more typical cause of the symptom you
> >> describe rather than long running threads in the application.
> >>
> >>>  We implemented StuckThreadDetectionValve in server.xml(  >>>
> >>> className="org.apache.catalina.valves.StuckThreadDetectionValve"
> >>>
> >>> threshold="60" />), but it  could not help out.
> >>
> >> Why not? Again, this suggests that long running threads aren't the
> problem.
> >>
> >>>So we implemented custom StuckThreadDetectionValve by extending
> >>> StuckThreadDetectionValve from
> >>> catalina, it only goes to "constructor","initInternal",and in
> >> "invoke"(when
> >>> action fires), it does not go to function "getStuckThreadNames()" even
> >>> after threshold time.How to achieve the same.Is there any way to detect
> >>> stucked thread and kill them?
> >>
> >> First of all your invoke() method fails to call super.invoke() so the
> >> Valve is never going to do anything.
> >>
> >> Secondly, if the original valve didn't work adding a bunch of
> >> System.out.println() lines isn't going to magically make it work.
> >>
> >> Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
> >> is no surprise that you never see a call to that method. That method is
> >> intended for use via JMX.
> >>
> >> I suggest you start again and tell us more about the problem you are
> >> trying to solve (lack of response) and your configuration. In particular
> >> we need to know your connector configuration and how users access the
> >> application. Do they connect directly to Tomcat or do they go via a
> >> reverse proxy?
> >>
> >> Mark
> >>
> >>
> >>>
> >>>   My custom Valve is like following :
> >>>
> >>> public class StuckThreadDetection extends StuckThreadDetectionValve
> >>> {
> >>> StuckThreadDetection stuckThreadDetection;
> >>>
> >>> public StuckThreadDetection()
> >>> {
> >>> System.out.println("in StuckThreadDetection constructor");
> >>>
> >>> }
> >>>
> >>> public void invoke(Request request, Response response) throws
> >> IOException,
> >>> ServletException
> >>> {
> >>> System.out.println("in invoke...");
> >>>
> >>> getNext().invoke(request, response);
> >>> }
> >>>
> >>> @Override
> >>> protected void initInternal() throws LifecycleException
> >>> {
> >>> System.out.prin

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 09:07, Yogesh Patel wrote:
> Thanks Mark Thomas ,
> 
>Our application is access by Apache TO Tomcat using AJP Connector.

OK. That answers one of the questions I asked. However, you haven't
provided the connector configuration.

> Problem :
> Our application was mostly hanged,after looking at tomcat manager it
> shown there are so many long running threads shown.

The Tomcat Manager app does not show long running threads. It does show
you how many requests are busy but again, a busy thread is not
necessarily processing a request.

> We want to recognize why so many threads are running since long time.

Threads are always "running". The key question is are those threads
'idle' or 'busy'. An idle thread is waiting to be allocated work. A busy
thread has been allocated work but the manager application can't
distinguish if that work is 'wait for a request to process' or
'processing a request'.

> We want to detect such thread and want to kill these stucked thread.

You continue to make the (increasingly unlikely) assumption that 200
busy threads mean you have 200 threads processing long running requests.
Had you provided the connector configuration I asked for (by that I mean
the  elements in server.xml) then I'd be in a better
position to tell you what is wrong.

If you do have 200 long running requests then the
StuckThreadDetectionValve is how you detect them. That fact that that
valve is not reporting any long running requests should be a big clue
that your assumptions about what is going on are not correct.

If, and it is a big if, you did have 200 concurrent long running
requests then there is no guaranteed way to stop them. If your
application checks for interrupts (most don't) then the
StuckThreadDetectionValve can interrupt them which should terminate the
processing of that request but the time it would take to code the
application to handle that properly would normally be better spent
fixing the root cause of the long running request.

Mark

> 
> 
> 
> 
> 
> On 5 October 2015 at 13:11, Mark Thomas  wrote:
> 
>> On 05/10/2015 07:54, Yogesh Patel wrote:
>>> We are facing issues with long running thread in tomcat . we are
>>> using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
>>> application  gets stucked due to these long running threads.
>>
>> What makes you think you have issues with long running threads? A busy
>> thread isn't necessarily processing a request. Configuration errors
>> leading to thread starvation are a more typical cause of the symptom you
>> describe rather than long running threads in the application.
>>
>>>  We implemented StuckThreadDetectionValve in server.xml( >>
>>> className="org.apache.catalina.valves.StuckThreadDetectionValve"
>>>
>>> threshold="60" />), but it  could not help out.
>>
>> Why not? Again, this suggests that long running threads aren't the problem.
>>
>>>So we implemented custom StuckThreadDetectionValve by extending
>>> StuckThreadDetectionValve from
>>> catalina, it only goes to "constructor","initInternal",and in
>> "invoke"(when
>>> action fires), it does not go to function "getStuckThreadNames()" even
>>> after threshold time.How to achieve the same.Is there any way to detect
>>> stucked thread and kill them?
>>
>> First of all your invoke() method fails to call super.invoke() so the
>> Valve is never going to do anything.
>>
>> Secondly, if the original valve didn't work adding a bunch of
>> System.out.println() lines isn't going to magically make it work.
>>
>> Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
>> is no surprise that you never see a call to that method. That method is
>> intended for use via JMX.
>>
>> I suggest you start again and tell us more about the problem you are
>> trying to solve (lack of response) and your configuration. In particular
>> we need to know your connector configuration and how users access the
>> application. Do they connect directly to Tomcat or do they go via a
>> reverse proxy?
>>
>> Mark
>>
>>
>>>
>>>   My custom Valve is like following :
>>>
>>> public class StuckThreadDetection extends StuckThreadDetectionValve
>>> {
>>> StuckThreadDetection stuckThreadDetection;
>>>
>>> public StuckThreadDetection()
>>> {
>>> System.out.println("in StuckThreadDetection constructor");
>>>
>>> }
>>>
>>> public void invoke(Request request, Response response) throws
>> IOException,
>>> ServletException
>>> {
>>> System.out.println("in invoke...");
>>>
>>> getNext().invoke(request, response);
>>> }
>>>
>>> @Override
>>> protected void initInternal() throws LifecycleException
>>> {
>>> System.out.println("In initInternal");
>>> super.initInternal();
>>> }
>>>
>>> @Override
>>> public String[] getStuckThreadNames()
>>> {
>>> System.out.println("in getStuckThreadNames...");
>>> String[] listStuckedThread = this.getStuckThreadNames();
>>>
>>> for (String threadName : listStuckedThread)
>>> {
>>> System.out.println(threadName);
>>>

Re: Regarding StuckThreadDetectionValve

[Yogesh Patel]

Thanks Mark Thomas ,

   Our application is access by Apache TO Tomcat using AJP Connector.

Problem :
Our application was mostly hanged,after looking at tomcat manager it
shown there are so many long running threads shown.
We want to recognize why so many threads are running since long time.
We want to detect such thread and want to kill these stucked thread.





On 5 October 2015 at 13:11, Mark Thomas  wrote:

> On 05/10/2015 07:54, Yogesh Patel wrote:
> > We are facing issues with long running thread in tomcat . we are
> > using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> > application  gets stucked due to these long running threads.
>
> What makes you think you have issues with long running threads? A busy
> thread isn't necessarily processing a request. Configuration errors
> leading to thread starvation are a more typical cause of the symptom you
> describe rather than long running threads in the application.
>
> >  We implemented StuckThreadDetectionValve in server.xml(  >
> > className="org.apache.catalina.valves.StuckThreadDetectionValve"
> >
> > threshold="60" />), but it  could not help out.
>
> Why not? Again, this suggests that long running threads aren't the problem.
>
> >So we implemented custom StuckThreadDetectionValve by extending
> > StuckThreadDetectionValve from
> > catalina, it only goes to "constructor","initInternal",and in
> "invoke"(when
> > action fires), it does not go to function "getStuckThreadNames()" even
> > after threshold time.How to achieve the same.Is there any way to detect
> > stucked thread and kill them?
>
> First of all your invoke() method fails to call super.invoke() so the
> Valve is never going to do anything.
>
> Secondly, if the original valve didn't work adding a bunch of
> System.out.println() lines isn't going to magically make it work.
>
> Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
> is no surprise that you never see a call to that method. That method is
> intended for use via JMX.
>
> I suggest you start again and tell us more about the problem you are
> trying to solve (lack of response) and your configuration. In particular
> we need to know your connector configuration and how users access the
> application. Do they connect directly to Tomcat or do they go via a
> reverse proxy?
>
> Mark
>
>
> >
> >   My custom Valve is like following :
> >
> > public class StuckThreadDetection extends StuckThreadDetectionValve
> > {
> > StuckThreadDetection stuckThreadDetection;
> >
> > public StuckThreadDetection()
> > {
> > System.out.println("in StuckThreadDetection constructor");
> >
> > }
> >
> > public void invoke(Request request, Response response) throws
> IOException,
> > ServletException
> > {
> > System.out.println("in invoke...");
> >
> > getNext().invoke(request, response);
> > }
> >
> > @Override
> > protected void initInternal() throws LifecycleException
> > {
> > System.out.println("In initInternal");
> > super.initInternal();
> > }
> >
> > @Override
> > public String[] getStuckThreadNames()
> > {
> > System.out.println("in getStuckThreadNames...");
> > String[] listStuckedThread = this.getStuckThreadNames();
> >
> > for (String threadName : listStuckedThread)
> > {
> > System.out.println(threadName);
> > }
> >
> > return listStuckedThread;
> >
> > }
> >
> > @Override
> > public String getInfo()
> > {
> > System.out.println("In getInfo");
> > return super.getInfo();
> > }
> > }
> >
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
*Thanks & Regards,*

* Yogesh Patel*

Re: Regarding StuckThreadDetectionValve

[Mark Thomas]

On 05/10/2015 07:54, Yogesh Patel wrote:
> We are facing issues with long running thread in tomcat . we are
> using Tomcat-7.0.47.Tomcat manager shows Current busy threads : 200,
> application  gets stucked due to these long running threads.

What makes you think you have issues with long running threads? A busy
thread isn't necessarily processing a request. Configuration errors
leading to thread starvation are a more typical cause of the symptom you
describe rather than long running threads in the application.

>  We implemented StuckThreadDetectionValve in server.xml(  
> className="org.apache.catalina.valves.StuckThreadDetectionValve"
> 
> threshold="60" />), but it  could not help out.

Why not? Again, this suggests that long running threads aren't the problem.

>So we implemented custom StuckThreadDetectionValve by extending
> StuckThreadDetectionValve from
> catalina, it only goes to "constructor","initInternal",and in "invoke"(when
> action fires), it does not go to function "getStuckThreadNames()" even
> after threshold time.How to achieve the same.Is there any way to detect
> stucked thread and kill them?

First of all your invoke() method fails to call super.invoke() so the
Valve is never going to do anything.

Secondly, if the original valve didn't work adding a bunch of
System.out.println() lines isn't going to magically make it work.

Thirdly, getStuckThreadNames() is never called by any Tomcat code so it
is no surprise that you never see a call to that method. That method is
intended for use via JMX.

I suggest you start again and tell us more about the problem you are
trying to solve (lack of response) and your configuration. In particular
we need to know your connector configuration and how users access the
application. Do they connect directly to Tomcat or do they go via a
reverse proxy?

Mark


> 
>   My custom Valve is like following :
> 
> public class StuckThreadDetection extends StuckThreadDetectionValve
> {
> StuckThreadDetection stuckThreadDetection;
> 
> public StuckThreadDetection()
> {
> System.out.println("in StuckThreadDetection constructor");
> 
> }
> 
> public void invoke(Request request, Response response) throws IOException,
> ServletException
> {
> System.out.println("in invoke...");
> 
> getNext().invoke(request, response);
> }
> 
> @Override
> protected void initInternal() throws LifecycleException
> {
> System.out.println("In initInternal");
> super.initInternal();
> }
> 
> @Override
> public String[] getStuckThreadNames()
> {
> System.out.println("in getStuckThreadNames...");
> String[] listStuckedThread = this.getStuckThreadNames();
> 
> for (String threadName : listStuckedThread)
> {
> System.out.println(threadName);
> }
> 
> return listStuckedThread;
> 
> }
> 
> @Override
> public String getInfo()
> {
> System.out.println("In getInfo");
> return super.getInfo();
> }
> }
> 
> 
> 
> 


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

Re: Rewriting entire request /body in Servlet Filter not working as expected

[Mark Thomas]

On 04/10/2015 19:03, Michael Greco wrote:
> First time post here.
> 
> Using :
> Tomcat 8.0.26
> JDK1.8.0 update 51
> Apache MyFaces 2.2.8.
> Maven build of webapp war file
> Chrome  45.0.2454.101 m 64 bit
> Windows 7 64 bit
> 
> Trying to rewrite the entire request body in a filter using a http request
> wrapper.  Not entirely sure if this is the right approach or even possible
> but researching similar examples it seems this approach should work.
> Created a simple test case with a one page test app, expecting the
> index.xhtml page's text value of  "Welcome" to be replaced with the text
> "NEW TEXT HERE" found in the filter code, but I only get "Welcome" back
> when the page is rendered in the browser.
> 
> Below is what I have in the index page, the filter and the web.xml and the
> pom.xml.  The reason I can see is that the getInputStream() or getReader()
> calls are never called by the FacesServlet in the extended
> HttpServletRequestWrapper.  I did override the getParameter function to put
> some simple debug output in there to ensure the wrapped request was
> actually used, so I know it's definitely getting into this class but not
> calling the methods that would return it the new body content.
> 
> I even tried to re-read the entire request in the getParametersMap() from
> examples I found on the web, but this didn't seen to do the job either.  It
> seems that the request body is somehow cached somewhere / somehow and not
> changable?
> 
> Thanks in advance for any insight on this.

First of all welcome files should be exactly that. Files. They should
not include paths. There is no guarantee that 'faces/index.html' is
going to work as you think it will and some containers may reject the
configuration as invalid. That Tomcat lets you get away with this is
fortunate and - now that I know about it - likely to change in future
releases.

You seem to be confusing reading the static resource from the file
system and reading the request body. The request body is the data sent
by the client with the HTTP request. The static resource (index.xhtml)
is read from the file system.

I assume that FacesServlet has its own static resource handling and that
a request for /faces/index.xhtml is expected to return the content
listed for index.html below.

The FacesServlet will open an input stream but not to the request body.
It will open one for the static resource on the file system. It will
then copy those bytes to the response output stream. At no point will it
attempt to read the request body (unless it is a POST request with
parameters).

If you want to modify the response body then you need to wrap the
response and provide Writer and OutputStream implementations that make
the modifications you require. The simplest way is to buffer the entire
response body and then edit it but that can get expensive in terms of
memory. It will be more efficient to use fixed buffer but then more
complex to ensure your desired edits take place.

Mark

> 
> index page code (index.xhtml) :
> -
> 
>xmlns="http://www.w3.org/1999/xhtml";
>   xmlns:jsf="http://xmlns.jcp.org/jsf";
>   xmlns:h="http://xmlns.jcp.org/jsf/html";>
> 
> 
> Test Webapp
> 
> 
> Welcome
> 
> 
> 
> Filter code :
> --
> package com.testwebapp.reqrewrite.filter;
> 
> import java.io.BufferedReader;
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.io.InputStreamReader;
> 
> import javax.servlet.Filter;
> import javax.servlet.FilterChain;
> import javax.servlet.FilterConfig;
> import javax.servlet.ReadListener;
> import javax.servlet.ServletException;
> import javax.servlet.ServletInputStream;
> import javax.servlet.ServletRequest;
> import javax.servlet.ServletResponse;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletRequestWrapper;
> 
> public class RewriteBodyTestFilter implements Filter {
> 
> public void init(FilterConfig filterConfig) throws ServletException {
> return;
> }
> 
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain)
> throws IOException, ServletException {
> String newReqBody = new String("NEW TEXT HERE");
> HttpServletRequest req = (HttpServletRequest)request;
> RewriteBodyRequestWrapper rewriteBodyRequestWrapper = new
> RewriteBodyRequestWrapper(req, newReqBody);
> chain.doFilter(rewriteBodyRequestWrapper, response);
> }
> 
> public void destroy() {
> return;
> }
> class RewriteBodyRequestWrapper extends HttpServletRequestWrapper {
> 
> private byte[] buffer;
> 
> public RewriteBodyRequestWrapper(HttpServletRequest req, String reqBody)
> throws IOException {
> super(req);
> System.out.println("entering RewriteBodyRequestWrapper() constructor");
> this.buffer = reqBody.getBytes();
> }
> 
> @Override
> public ServletInputStream getInputStream() {
> System.out.println("entering Rew