RE: Unable to access Global JNDI Resource

2016-10-03 Thread Chinoy Gupta
Hi Mark,

Thanks for the info. But I am afraid the custom loader directly extends 
URLClassLoader. Actually my application is a generic web app which can be 
deployed in any ApplciationServer like tomcat, JBoss, etc. So I don't have any 
tomcat specific implementations.

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, October 03, 2016 6:16 PM
To: Tomcat Users List 
Subject: Re: Unable to access Global JNDI Resource

On 30/09/2016 13:34, Chinoy Gupta wrote:
> Hi Mark,
> 
> The following is added in server.xml:
> 
>  
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
> 
>type="java.lang.String"/>
>   
> 
> And the following is added in context.xml:
> 
>type="java.lang.String" override="false"/>
>type="java.lang.String" />
> 
> If I try to get "my/local/test", it works and I get "local test". But if I 
> try to get " my/secret/password", it returns NULL.

This works for me with both 9.0.x and 8.0.x.

Your previous posts mentioned a custom class loader. If the web application 
class loader is not the thread context class loader then the resource will not 
be visible.

Is that custom class loader a child of the web application class loader?
If so, a fix for the next release should be fairly simple.

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, September 30, 2016 6:00 PM
> To: Tomcat Users List 
> Subject: Re: Unable to access Global JNDI Resource
> 
> On 30/09/2016 13:20, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> This is my stacktrace:
>>
>>  ResourceLinkFactory.validateGlobalResourceAccess(String) line: 109  
>>  ResourceLinkFactory.getObjectInstance(Object, Name, Context, 
>> Hashtable) line: 142  
>>  NamingManager.getObjectInstance(Object, Name, Context, Hashtable) 
>> line: 321
>>  NamingContext.lookup(Name, boolean) line: 847   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(String) line: 172
>>
>> validateGlobalResourceAccess function returns false and then 
>> getObjectInstance returns NULL.
> 
> You haven't defined a ResourceLink.
> 
> Mark
> 
>>
>> Regards,
>> Chinoy
>>
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Friday, September 30, 2016 5:28 PM
>> To: Tomcat Users List 
>> Subject: Re: Unable to access Global JNDI Resource
>>
>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>> I am getting NULL instead of the resource's value. I debugged the 
>>> tomcat code and figured out that in ResourceLinkFactory.java, before 
>>> fetching the resource there is a validation based on current 
>>> classloader. That validation fails and tomcat returns NULL.
>>
>> The above statement is not correct. If the class loader based validation 
>> fails, Tomcat throws an exception. It does not return null.
>>
>> Mark
>>
>>>
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org]
>>> Sent: Friday, September 30, 2016 4:11 PM
>>> To: Tomcat Users List  Subject: Re: Unable 
>>> to access Global JNDI Resource
>>>
>>> On 30/09/2016 11:30, Chinoy Gupta wrote:
 Hi,

 I have a web application which runs on tomcat. In server.xml, I 
 provide some resources under " section" and 
 then provide a ResourceLink to the same in context.xml. And then I 
 fetch that resource in my application. This was working properly 
 earlier but started breaking with 8.0.37.
>>>
>>> Define breaking. Ideally with a stack trace.
>>>
>>> Mark
>>>
>>>
 I think the reason is the extra validation check introduced in 
 ResourceLinkFactory class. My application has its own classloader 
 and when I try to fetch the JNDI resource, the Thread's classloader 
 is my custom one rather than the default one. Because of that 
 validation fails and tomcat returns NULL. Is there a way to fix 
 this through configuration or any other means?

 Regards, Chinoy


>>>
>>>
>>> 
>>> -
>>>
>>>
>> 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: ping websocket clients

2016-10-03 Thread Mark Thomas
On 03/10/2016 16:33, Cristian Lorenzetto wrote:
> Using websockets with tomcat i saw the connection is never closed until
> client closes it.

Correct.

> It sounds Ok just if server send ping frame to client.
> Does tomcat make it?

Tomcat does not send pings. That is an application responsibility.

> -if yes what is the ping interval?

Mark


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



Re: HTTP/2 PushBuilder.push() synchronous?

2016-10-03 Thread Mark Thomas
On 29 September 2016 15:30:40 BST, Brian Clozel  wrote:
>Hi,
>
>Looking at previous Servlet 4.0 EG e-mails [1] and the
>PushBuilder.push()
>API [2], it seems the current version returns true if the PUSH_PROMISE
>frame + headers were sent, meaning the client can still reset that
>stream
>and refuse to receive the response that goes with it.

Not quite. It returns true if the push is accepted by the server. I'm on my 
phone so looking at the code is tricky. I can't remember if an error triggers 
an exception or returns false.

>Now looking at former EG e-mails, it seems that a previous version of
>the
>spec stated that push "returns immediately without blocking" [3]. But
>this
>API, and the implementation as far as I understand things [4], seems
>synchronous. Or does that writing does not happen directly on the
>actual
>socket but is later dispatched on another thread?

The push is built on the current thread and then passed to a separate thread 
for processing. The idea being to catch as many errors as possible on the 
current thread.

The client is free to reset the pushed steam at any point. 

HTH,

Mark


>In general, I'm trying to understand how I can use that API in an
>async,
>non-blocking way and if the application really needs to know if the
>Push
>promise "happened" or not...
>
>Cheers,
>
>[1] https://java.net/projects/servlet-spec/lists/jsr369-
>experts/archive/2016-03/message/0
>[2] https://github.com/apache/tomcat/blob/trunk/java/javax/s
>ervlet/http/PushBuilder.java#L161-L178
>[3] https://java.net/projects/servlet-spec/lists/jsr369-expe
>rts/archive/2015-12/message/8
>[4] https://github.com/apache/tomcat/blob/trunk/java/org/apa
>che/coyote/http2/Http2UpgradeHandler.java#L1036
>--
>Brian Clozel



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



Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Martijn Bos
On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:
> I've an application under tomcat.
> When only a one or two users works on it everithing is ok.
> When the number of users grows the application slows down.
> Is not a memory nor a cpu problem : using top I see the system resources 
> quite free.
> I don't see relevant garbage collection : heap size and permgen have correct 
> dimentions.
> No other applications are running on the system.
> I log more or less every relevant operation in my system (db query and so on) 
> and I see that every slowdown is concentered in a single operation.
> I mean all operations take "normal" time but one or two of them take 4 
> seconds more.
> The "slowing" operations are not the same in different executions, and theydo 
> not have a specific type (not only DB query, not only DB stored procedures, 
> not only.).
> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
> more or less) and then it restarts.
> I don't think it's a "queue" problem because otherwise the wait time would be 
> unperdictable and not a "fixed" 4 seconds time.
> I don't know any parameter impacting on that behaviour.
> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> Could someone suggest a solution for my problem or, at least, an 
> investigation strategy.
> Tks
> 
> Tullio
> 


The few examples that you mention are all database related (query/stored 
procedure).
Can it be that your connection pool (if used) combined with not closing 
connections is part of the problem.

I can imagine :
1)
Maybe you run out of conenctions, because connections are not properly closed.
And also the connection pool teminates connections when they are not used for 4 
seconds.
After 4 seconds the pool can recreate connections again.

or 2)
Maybe your connection pool has very limited connections.
With one or two users this limited number of connections in the pool will 
suffice.
If there are more users, the max. number of connections isn't enough.
The pool then has to wait for connections to become fee again.


(uhhI'm not an expert at all, but the above came immediately to my mind)

-- 
Met vriendelijke groet,

Martijn Bos
+31 6 39477001

(Public pgp-key : http://maboc.nl/pubkey.maboc.asc)


signature.asc
Description: Digital signature


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Leon Rosenberg
Hi Tullio,

well I am biased of course, but there are multiple.
First, profiles are never used in production, MoSKito is aimed for
production use. Not test lab, not dev machine, production, hardcore on all
servers you've got.
Than MoSKito also offers analysis tools, thresholds, alerts, charts etc.
Finally MoSKito allows you to integrate business data into monitoring,
things like registration count, checkout, gender of user, and so on...

'standard profiler' - is something designed to be used in the development
environment.
moskito is an apm tool.

hope that helps
regards
Leon


On Mon, Oct 3, 2016 at 4:21 PM, Tullio Bettinazzi 
wrote:

> Please help me to understand diffrences beween Moskito and standard
> profilers.
>
> Tks
>
> Tullio
>
>
> 
> Da: Leon Rosenberg 
> Inviato: lunedì 3 ottobre 2016 14.29
> A: Tomcat Users List
> Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
>
> Hi Tullio,
>
> you could download and integrate MoSKito -> http://www.moskito.org. After
> Health and Performance Monitoring for Java Applications | MoSKito<
> http://www.moskito.org/>
> www.moskito.org
> MoSKito: Health and Performance Monitoring for Java applications. Complete
> ecosystem for DevOps. Free and open source
>
>
>
> integration as described here
> blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/ or
> here: http://www.moskito.org/integration.html you can start your
> Integration for MoSKito, the Open Source Health and Performance Monitoring
> System for Java Applications
> www.moskito.org
> MoSKito Integration
>
>
>
> application and setup a tracer.
> A tracer, explained here:
> http://blog.anotheria.net/msk/newest-hottest-tracers/, can be used to
> automatically trace all requests passing a specific point and compare the
> execution times. It will keep the longest requests along with the execution
> time in each monitored component.
> So if there is some part of code you have, that lasts longer from time to
> time, the tracer will find it.
>
> regards
> Leon
>
>
> On Mon, Oct 3, 2016 at 2:12 PM, Mark Thomas  wrote:
>
> > On 03/10/2016 11:19, Tullio Bettinazzi wrote:
> > > I already use Yourkit but it doesn't seems a load problem.
> > >
> > > The delay is not spread over all operaions but concentred in only one
> or
> > two and allways takes 4 secs more than the normal operation  time.
> > >
> > > Could You suggest how to use Yourkit in this schenario ?
> >
> > I'd look at GC activity and detailed CPU profiling.
> >
> > Mark
> >
> > >
> > > Tks
> > >
> > > Tullio
> > >
> > >
> > > 
> > > Da: Mark Thomas 
> > > Inviato: lunedì 3 ottobre 2016 10.39
> > > A: Tomcat Users List
> > > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
> > >
> > > On 03/10/2016 08:56, Tullio Bettinazzi wrote:
> > >> I've an application under tomcat.
> > >> When only a one or two users works on it everithing is ok.
> > >> When the number of users grows the application slows down.
> > >> Is not a memory nor a cpu problem : using top I see the system
> > resources quite free.
> > >> I don't see relevant garbage collection : heap size and permgen have
> > correct dimentions.
> > >> No other applications are running on the system.
> > >> I log more or less every relevant operation in my system (db query and
> > so on) and I see that every slowdown is concentered in a single
> operation.
> > >> I mean all operations take "normal" time but one or two of them take 4
> > seconds more.
> > >> The "slowing" operations are not the same in different executions, and
> > theydo not have a specific type (not only DB query, not only DB stored
> > procedures, not only.).
> > >> It seems like if the thread is frozen for a fixed amount fo time (4
> > seconds more or less) and then it restarts.
> > >> I don't think it's a "queue" problem because otherwise the wait time
> > would be unperdictable and not a "fixed" 4 seconds time.
> > >> I don't know any parameter impacting on that behaviour.
> > >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> > >> Could someone suggest a solution for my problem or, at least, an
> > investigation strategy.
> > >
> > > https://www.yourkit.com/java/profiler/features/
> > > Performance and Memory Java Profiler - YourKit Java Profiler<
> > https://www.yourkit.com/java/profiler/features/>
> > > www.yourkit.com
> > > Easy to use performance and memory profiler for .NET framework.
> Supports
> > ASP.NET, Silverlight, .NET Windows services and more.
> > >
> > >
> > >
> > >
> > > Mark
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> >
> >
> > 

Re: Unable to access Global JNDI Resource

2016-10-03 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chinoy,

On 9/30/16 12:24 PM, Chinoy Gupta wrote:
> But the same thing is working in 8.0.36.

I'm very sorry, I must have read your originally message incorrectly.

I was thinking you were trying to map the UserDatabaseRealm into your
web application, and not just the password.

Apologies for the noise,
- -chris

> On Fri, Sep 30, 2016 at 9:33 PM +0530, "Christopher Schultz"
> >
> wrote:
> 
> Chinoy,
> 
> On 9/30/16 8:34 AM, Chinoy Gupta wrote:
>> Hi Mark,
> 
>> The following is added in server.xml:
> 
>>  
>> > type="org.apache.catalina.UserDatabase" description="User
>> database that can be updated and saved" 
>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 
>> pathname="conf/tomcat-users.xml" />
> 
>> > type="java.lang.String"/> 
> 
>> And the following is added in context.xml:
> 
>> > type="java.lang.String" override="false"/> > name="my/secret/password" global="my/secret/password" 
>> type="java.lang.String" />
> 
>> If I try to get "my/local/test", it works and I get "local
>> test". But if I try to get " my/secret/password", it returns
>> NULL.
> 
> You aren't mapping it correctly.
> 
> Please have another look at the documentation for .
> 
> -chris
> 
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 6:00
>> PM To: Tomcat Users List  Subject: Re:
>> Unable to access Global JNDI Resource
> 
>> On 30/09/2016 13:20, Chinoy Gupta wrote:
>>> Hi Mark,
>>> 
>>> This is my stacktrace:
>>> 
>>> ResourceLinkFactory.validateGlobalResourceAccess(String) line: 
>>> 109 ResourceLinkFactory.getObjectInstance(Object, Name,
>>> Context, Hashtable) line: 142
>>> NamingManager.getObjectInstance(Object, Name, Context,
>>> Hashtable) line: 321 NamingContext.lookup(Name, boolean)
>>> line: 847 NamingContext.lookup(Name) line: 158
>>> NamingContext.lookup(Name, boolean) line: 835
>>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name,
>>> boolean) line: 835 NamingContext.lookup(String) line: 172
>>> 
>>> validateGlobalResourceAccess function returns false and then 
>>> getObjectInstance returns NULL.
> 
>> You haven't defined a ResourceLink.
> 
>> Mark
> 
>>> 
>>> Regards, Chinoy
>>> 
>>> 
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016
>>> 5:28 PM To: Tomcat Users List 
>>> Subject: Re: Unable to access Global JNDI Resource
>>> 
>>> On 30/09/2016 12:50, Chinoy Gupta wrote:
 I am getting NULL instead of the resource's value. I
 debugged the tomcat code and figured out that in 
 ResourceLinkFactory.java, before fetching the resource there
 is a validation based on current classloader. That
 validation fails and tomcat returns NULL.
>>> 
>>> The above statement is not correct. If the class loader based 
>>> validation fails, Tomcat throws an exception. It does not
>>> return null.
>>> 
>>> Mark
>>> 
 
 -Original Message- From: Mark Thomas 
 [mailto:ma...@apache.org] Sent: Friday, September 30, 2016
 4:11 PM To: Tomcat Users List 
 Subject: Re: Unable to access Global JNDI Resource
 
 On 30/09/2016 11:30, Chinoy Gupta wrote:
> Hi,
> 
> I have a web application which runs on tomcat. In
> server.xml, I provide some resources under
> " section" and then provide a
> ResourceLink to the same in context.xml. And then I fetch
> that resource in my application. This was working properly
> earlier but started breaking with 8.0.37.
 
 Define breaking. Ideally with a stack trace.
 
 Mark
 
 
> I think the reason is the extra validation check
> introduced in ResourceLinkFactory class. My application has
> its own classloader and when I try to fetch the JNDI
> resource, the Thread's classloader is my custom one rather
> than the default one. Because of that validation fails and
> tomcat returns NULL. Is there a way to fix this through
> configuration or any other means?
> 
> Regards, Chinoy
> 
> 
 
 
 ---
- -
>
 
- -
 
 
>>> 
 
> 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: Trigger sessionDestroyed event from custom ManagerBase

2016-10-03 Thread Coty Sutherland
I set Gokul here from #tomcat on freenode :) Just for a bit more
information (since it was excluded):

 Good UGT, i'm using java - 1.8.0_74, tomcat - 8.0.32, os - win 7

On Mon, Oct 3, 2016 at 12:38 PM, GOKULA KRISHNAN  wrote:
> Hi,
>
> I want to trigger the sessionDestroyed event from custom implementation of
> ManagerBase. sessionDestroyed is not called when session expires but called
> during session invalidate. I need to call sessionDestroyed  during session
> time out.
>
> The class starts like this.
>
> *public class CustomRequestSessionManager extends ManagerBase implements
> Lifecycle*
> {...
> ..}
>
> Please help me ASAP, since this is an urgent need.
>
> Thanks,
> Gokul.

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



Trigger sessionDestroyed event from custom ManagerBase

2016-10-03 Thread GOKULA KRISHNAN
Hi,

I want to trigger the sessionDestroyed event from custom implementation of
ManagerBase. sessionDestroyed is not called when session expires but called
during session invalidate. I need to call sessionDestroyed  during session
time out.

The class starts like this.

*public class CustomRequestSessionManager extends ManagerBase implements
Lifecycle*
{...
..}

Please help me ASAP, since this is an urgent need.

Thanks,
Gokul.


ping websocket clients

2016-10-03 Thread Cristian Lorenzetto
Using websockets with tomcat i saw the connection is never closed until
client closes it.
It sounds Ok just if server send ping frame to client.
Does tomcat make it?
-if yes what is the ping interval?


Re: Async servlet and request recycling

2016-10-03 Thread Thomas Boniface
Hi,

Thanks for your feedbacks. I noticed the issue I described do not occur on
my local or integration environment. I still try to figure out how to
reproduce this in an environment I can easely update to the latest tomcat
version.

Although it may not occur in latest release. Could you give me an input on
what are the consequences of the behaviour I described ?

Thanks,
Thomas

2016-09-29 9:41 GMT+02:00 Violeta Georgieva :

> Hi,
>
> 2016-09-29 10:14 GMT+03:00 Thomas Boniface :
> >
> > The tomcat version is 7.0.64.
>
> I would recommend you to verify the behaviour against the latest Tomcat 7
> (7.0.72).
> We have changes in the async processing since 7.0.64.
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html
>
> Regards,
> Violeta
>
> > Thomas
> >
> > 2016-09-28 22:43 GMT+02:00 Christopher Schultz <
> ch...@christopherschultz.net
> > >:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > Thomas,
> > >
> > > On 9/28/16 11:55 AM, Thomas Boniface wrote:
> > > > Hi,
> > > >
> > > > When a client calls an asynchronous servlet and closes the
> > > > connection a java.io.IOException: Broken pipe is catched by Tomcat
> > > > level when the webapp tries to write to the socket.
> > > >
> > > > This exception is not transmited to the webapp level but it seems
> > > > the request has been recycled (all content is reinitialised), in
> > > > such a case it impossible for the webapp to retrieve the
> > > > AsyncContext from the HttpServletRequest making the AsyncContext
> > > > complete call impossible.
> > > >
> > > > Activating the tomcat logging for AsyncContext
> > > > (org.apache.catalina.core.AsyncContextImpl.level = FINE) shows the
> > > > recycle method is called but not the complete method, what seems to
> > > > confirm my assumption. In a use case were the client waits for the
> > > > response, I can see both complete and recycle are called.
> > > >
> > > > My question is, what is the impact of the complete not being called
> > > > on the AsyncContext, is the socket cleaned up properly ?
> > >
> > > Tomcat version?
> > >
> > > - -chris
> > > -BEGIN PGP SIGNATURE-
> > > Comment: GPGTools - http://gpgtools.org
> > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > >
> > > iQIcBAEBCAAGBQJX7CtcAAoJEBzwKT+lPKRYwekP/R1wirv0g7wJ3uR1Xk4mYIQo
> > > jPUYBirzVcewTWrDUpOe4BdXUBzgk7zDVrOsWU9PGlc0Prwik9YHeFWlG9ItxeEs
> > > 0ZJ0vJ1z6Od0KsxN6E8KobsE3rQu+td1Mh7d0g76zbHQKiLmrJNb8/hGuHVQr9Fd
> > > M597bec0JYiQSXU+8/SMErx/bdoA8HcApaeJpnl/RuCLfYwQ5ZSS/e0SCuSqMi1W
> > > bEU0vj0pBfK6h1WuweCRoBL5Shxa2XBpbc8nlPgb7IHNlQ15dwlD10nnuYDLb7DR
> > > VmOYEx2fmynZ/fOajfTsHoWUpoHjK47vMjtLUpIXARN8LY6tR2A2iUqJ6gXlM+QL
> > > gNRkucxkI3RSV3U7ipx7y5IJTglFC7uAyFlJpPLx8gLhGWSUz+q46lDr+332kF5x
> > > VU7rKLY/3RcSJG0ZLfIzPly5tz8wssMvwu94nI8lQb4SweEJDa6cT5Z8aUUTFaf6
> > > kjy34jSgsi6QyN+NK9WKapdDNzvIo1X18zK2CqfDSeyBsgprU62o1P8R/BxIiM9f
> > > YAnK98kPtmmKyJHcS7+fBngO1/TZvsdGlYj+cXcnCNi0Fnp50WKlHOPb6wcZo5q5
> > > lcpLkwj4izmdgW8rONjMDAZj3gal7OKw0WQ/srU6XIfUa1kgR0NAtb7YQGvHJA5g
> > > ljFdLIuRnMu+43OsbSKC
> > > =zrQ5
> > > -END PGP SIGNATURE-
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
>


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Tullio Bettinazzi
Please help me to understand diffrences beween Moskito and standard profilers.

Tks

Tullio



Da: Leon Rosenberg 
Inviato: lunedì 3 ottobre 2016 14.29
A: Tomcat Users List
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

Hi Tullio,

you could download and integrate MoSKito -> http://www.moskito.org. After
Health and Performance Monitoring for Java Applications | 
MoSKito
www.moskito.org
MoSKito: Health and Performance Monitoring for Java applications. Complete 
ecosystem for DevOps. Free and open source



integration as described here
blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/ or
here: http://www.moskito.org/integration.html you can start your
Integration for MoSKito, the Open Source Health and Performance Monitoring 
System for Java Applications
www.moskito.org
MoSKito Integration



application and setup a tracer.
A tracer, explained here:
http://blog.anotheria.net/msk/newest-hottest-tracers/, can be used to
automatically trace all requests passing a specific point and compare the
execution times. It will keep the longest requests along with the execution
time in each monitored component.
So if there is some part of code you have, that lasts longer from time to
time, the tracer will find it.

regards
Leon


On Mon, Oct 3, 2016 at 2:12 PM, Mark Thomas  wrote:

> On 03/10/2016 11:19, Tullio Bettinazzi wrote:
> > I already use Yourkit but it doesn't seems a load problem.
> >
> > The delay is not spread over all operaions but concentred in only one or
> two and allways takes 4 secs more than the normal operation  time.
> >
> > Could You suggest how to use Yourkit in this schenario ?
>
> I'd look at GC activity and detailed CPU profiling.
>
> Mark
>
> >
> > Tks
> >
> > Tullio
> >
> >
> > 
> > Da: Mark Thomas 
> > Inviato: lunedì 3 ottobre 2016 10.39
> > A: Tomcat Users List
> > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
> >
> > On 03/10/2016 08:56, Tullio Bettinazzi wrote:
> >> I've an application under tomcat.
> >> When only a one or two users works on it everithing is ok.
> >> When the number of users grows the application slows down.
> >> Is not a memory nor a cpu problem : using top I see the system
> resources quite free.
> >> I don't see relevant garbage collection : heap size and permgen have
> correct dimentions.
> >> No other applications are running on the system.
> >> I log more or less every relevant operation in my system (db query and
> so on) and I see that every slowdown is concentered in a single operation.
> >> I mean all operations take "normal" time but one or two of them take 4
> seconds more.
> >> The "slowing" operations are not the same in different executions, and
> theydo not have a specific type (not only DB query, not only DB stored
> procedures, not only.).
> >> It seems like if the thread is frozen for a fixed amount fo time (4
> seconds more or less) and then it restarts.
> >> I don't think it's a "queue" problem because otherwise the wait time
> would be unperdictable and not a "fixed" 4 seconds time.
> >> I don't know any parameter impacting on that behaviour.
> >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> >> Could someone suggest a solution for my problem or, at least, an
> investigation strategy.
> >
> > https://www.yourkit.com/java/profiler/features/
> > Performance and Memory Java Profiler - YourKit Java Profiler<
> https://www.yourkit.com/java/profiler/features/>
> > www.yourkit.com
> > Easy to use performance and memory profiler for .NET framework. Supports
> ASP.NET, Silverlight, .NET Windows services and more.
> >
> >
> >
> >
> > Mark
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

2016-10-03 Thread Mark Thomas
On 03/10/2016 14:20, Johannes Michler wrote:
> Hi Mark,
> 
> Thanks a lot for pointing out. Indeed I relied to much that I did not get
> any faults and didn't check that part. I'll try with the renamed method
> tomorrow, but I'm quite sure that will solve the issue.

Great.

> Regarding returning http 403 you suggest to do that in our custom
> basicauthenticator as well, correct? But this would still require us to
> install a tomcat version specific library globally, wouldn't it?

It would. I don't see a way to avoid this with custom code at this point.

Mark


> 
> Br
> Johannes
> 
> Am 03.10.2016 15:01 schrieb "Mark Thomas" :
> 
> On 01/10/2016 18:50, Johannes Michler wrote:
>> Hi,
>>
>> for our own web-application we overwrite the standard way of how Tomcat
>> BasicAuthenticator is working in order to avoid the popup of a
>> "Basic-Auth-Dialog" in some situations (where we're calling a service
>> provided by the tomcat over a script). Therefore our context.xml in the
>> app looks as follows:
>>
>> 
>> > className="biz.horus.database.server.servletscript.
> HorusTomcatBasicAuthenticator"
>> />
>> 
>>
>> HorusTomcatBasicAuthenticator is implemented as follows:
>> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
>> implements Authenticator {
>>
>> @Override
>> public boolean authenticate( Request request, HttpServletResponse
>> response) throws IOException {
>> System.out.println( " start out");
>> boolean result = super.authenticate( request, response);
>> System.out.println( " authenticate: " + result);
>> modifyResponse( request, response);
>> return result;
>> }
>> private void modifyResponse( Request request, HttpServletResponse
>> response) {
>> String url = request.getPathInfo();
>> System.out.println( "XX URL=" + url);
>> System.out.println( "XX Auth Header:" + response.getHeader(
>> AUTH_HEADER_NAME));
>> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
>> url.startsWith( "/rest"))
>> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
>> }
>>
>> }
>>
>>
>> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
>> that code in "authenticate" is no longer called. Instead it seams that
>> the "standard" BasicAuthenticator is being used.
>>
>> However if I entirely remove my jar-file that contains
>> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
>> an error.
>>
>> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
>> could not find any hints on changed behaviour.
> 
> 
> 
> Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
> there have been many changes at the detail level and they are not binary
> compatible. Developers of custom components that interact with Tomcat's
> internals should review the JavaDoc for the relevant API.
> 
> 
> ->
> http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
> catalina/authenticator/AuthenticatorBase.html
> 
> and
> 
> http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
> catalina/authenticator/BasicAuthenticator.html
> 
> 
> Of particular note will be changes related to authenticate() and
> doAuthenticate().
> 
> 
>> Also when comparing the
>> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
>>
>> Or would it be better to address this with d...@tomcat.apache.org
>>  since it might as well be a bug?
> 
> No. The users list is the right place for this.
> 
>> Or is there a more elegant way to solve this problem to not reply with
>> "WWW-Authenticate: Basic" if authentication is not succesful?
> 
> Maybe just change the status code to 403?
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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



Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

2016-10-03 Thread Johannes Michler
Hi Mark,

Thanks a lot for pointing out. Indeed I relied to much that I did not get
any faults and didn't check that part. I'll try with the renamed method
tomorrow, but I'm quite sure that will solve the issue.

Regarding returning http 403 you suggest to do that in our custom
basicauthenticator as well, correct? But this would still require us to
install a tomcat version specific library globally, wouldn't it?

Br
Johannes

Am 03.10.2016 15:01 schrieb "Mark Thomas" :

On 01/10/2016 18:50, Johannes Michler wrote:
> Hi,
>
> for our own web-application we overwrite the standard way of how Tomcat
> BasicAuthenticator is working in order to avoid the popup of a
> "Basic-Auth-Dialog" in some situations (where we're calling a service
> provided by the tomcat over a script). Therefore our context.xml in the
> app looks as follows:
>
> 
>  className="biz.horus.database.server.servletscript.
HorusTomcatBasicAuthenticator"
> />
> 
>
> HorusTomcatBasicAuthenticator is implemented as follows:
> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
> implements Authenticator {
>
> @Override
> public boolean authenticate( Request request, HttpServletResponse
> response) throws IOException {
> System.out.println( " start out");
> boolean result = super.authenticate( request, response);
> System.out.println( " authenticate: " + result);
> modifyResponse( request, response);
> return result;
> }
> private void modifyResponse( Request request, HttpServletResponse
> response) {
> String url = request.getPathInfo();
> System.out.println( "XX URL=" + url);
> System.out.println( "XX Auth Header:" + response.getHeader(
> AUTH_HEADER_NAME));
> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
> url.startsWith( "/rest"))
> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
> }
>
> }
>
>
> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
> that code in "authenticate" is no longer called. Instead it seams that
> the "standard" BasicAuthenticator is being used.
>
> However if I entirely remove my jar-file that contains
> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
> an error.
>
> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
> could not find any hints on changed behaviour.



Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
there have been many changes at the detail level and they are not binary
compatible. Developers of custom components that interact with Tomcat's
internals should review the JavaDoc for the relevant API.


->
http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
catalina/authenticator/AuthenticatorBase.html

and

http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/
catalina/authenticator/BasicAuthenticator.html


Of particular note will be changes related to authenticate() and
doAuthenticate().


> Also when comparing the
> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
>
> Or would it be better to address this with d...@tomcat.apache.org
>  since it might as well be a bug?

No. The users list is the right place for this.

> Or is there a more elegant way to solve this problem to not reply with
> "WWW-Authenticate: Basic" if authentication is not succesful?

Maybe just change the status code to 403?

Mark


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


Re: Fwd: No longer able to use my own org.apache.catalina.authenticator.BasicAuthenticator in Tomcat 8.5.5

2016-10-03 Thread Mark Thomas
On 01/10/2016 18:50, Johannes Michler wrote:
> Hi,
> 
> for our own web-application we overwrite the standard way of how Tomcat
> BasicAuthenticator is working in order to avoid the popup of a
> "Basic-Auth-Dialog" in some situations (where we're calling a service
> provided by the tomcat over a script). Therefore our context.xml in the
> app looks as follows:
> 
> 
>  className="biz.horus.database.server.servletscript.HorusTomcatBasicAuthenticator"
> />
> 
> 
> HorusTomcatBasicAuthenticator is implemented as follows:
> public class HorusTomcatBasicAuthenticator extends BasicAuthenticator
> implements Authenticator {
> 
> @Override
> public boolean authenticate( Request request, HttpServletResponse
> response) throws IOException {
> System.out.println( " start out");
> boolean result = super.authenticate( request, response);
> System.out.println( " authenticate: " + result);
> modifyResponse( request, response);
> return result;
> }
> private void modifyResponse( Request request, HttpServletResponse
> response) {
> String url = request.getPathInfo();
> System.out.println( "XX URL=" + url);
> System.out.println( "XX Auth Header:" + response.getHeader(
> AUTH_HEADER_NAME));
> if ( response.getHeader( AUTH_HEADER_NAME) != null &&
> url.startsWith( "/rest"))
> response.setHeader( AUTH_HEADER_NAME, "HCP_BASIC");
> }
> 
> }
> 
> 
> This is working great with Tomcat 8.0(.37). Though with Tomcat 8.5.5
> that code in "authenticate" is no longer called. Instead it seams that
> the "standard" BasicAuthenticator is being used.
> 
> However if I entirely remove my jar-file that contains
> HorusTomcatBasicAuthenticator.jar from the tomcat/lib-folder I'm getting
> an error.
> 
> Any ideas on that? I've looked into the tomcat 8.5 migration guide but
> could not find any hints on changed behaviour.



Whilst the Tomcat 8.5 internal API is broadly compatible with Tomcat 8.0
there have been many changes at the detail level and they are not binary
compatible. Developers of custom components that interact with Tomcat's
internals should review the JavaDoc for the relevant API.


->
http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/authenticator/AuthenticatorBase.html

and

http://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/catalina/authenticator/BasicAuthenticator.html


Of particular note will be changes related to authenticate() and
doAuthenticate().


> Also when comparing the
> Valve-Documentation of Tomcat 8.5 and 8.0 I do not see a difference.
> 
> Or would it be better to address this with d...@tomcat.apache.org
>  since it might as well be a bug?

No. The users list is the right place for this.

> Or is there a more elegant way to solve this problem to not reply with
> "WWW-Authenticate: Basic" if authentication is not succesful?

Maybe just change the status code to 403?

Mark


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



Re: Unable to access Global JNDI Resource

2016-10-03 Thread Mark Thomas
On 30/09/2016 13:34, Chinoy Gupta wrote:
> Hi Mark,
> 
> The following is added in server.xml:
> 
>  
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
> 
>type="java.lang.String"/>
>   
> 
> And the following is added in context.xml:
> 
>type="java.lang.String" override="false"/>
>type="java.lang.String" />
> 
> If I try to get "my/local/test", it works and I get "local test". But if I 
> try to get " my/secret/password", it returns NULL.

This works for me with both 9.0.x and 8.0.x.

Your previous posts mentioned a custom class loader. If the web
application class loader is not the thread context class loader then the
resource will not be visible.

Is that custom class loader a child of the web application class loader?
If so, a fix for the next release should be fairly simple.

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Friday, September 30, 2016 6:00 PM
> To: Tomcat Users List 
> Subject: Re: Unable to access Global JNDI Resource
> 
> On 30/09/2016 13:20, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> This is my stacktrace:
>>
>>  ResourceLinkFactory.validateGlobalResourceAccess(String) line: 109  
>>  ResourceLinkFactory.getObjectInstance(Object, Name, Context, 
>> Hashtable) line: 142  
>>  NamingManager.getObjectInstance(Object, Name, Context, Hashtable) 
>> line: 321
>>  NamingContext.lookup(Name, boolean) line: 847   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(String) line: 172
>>
>> validateGlobalResourceAccess function returns false and then 
>> getObjectInstance returns NULL.
> 
> You haven't defined a ResourceLink.
> 
> Mark
> 
>>
>> Regards,
>> Chinoy
>>
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Friday, September 30, 2016 5:28 PM
>> To: Tomcat Users List 
>> Subject: Re: Unable to access Global JNDI Resource
>>
>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>> I am getting NULL instead of the resource's value. I debugged the 
>>> tomcat code and figured out that in ResourceLinkFactory.java, before 
>>> fetching the resource there is a validation based on current 
>>> classloader. That validation fails and tomcat returns NULL.
>>
>> The above statement is not correct. If the class loader based validation 
>> fails, Tomcat throws an exception. It does not return null.
>>
>> Mark
>>
>>>
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org]
>>> Sent: Friday, September 30, 2016 4:11 PM
>>> To: Tomcat Users List  Subject: Re: Unable 
>>> to access Global JNDI Resource
>>>
>>> On 30/09/2016 11:30, Chinoy Gupta wrote:
 Hi,

 I have a web application which runs on tomcat. In server.xml, I 
 provide some resources under " section" and 
 then provide a ResourceLink to the same in context.xml. And then I 
 fetch that resource in my application. This was working properly 
 earlier but started breaking with 8.0.37.
>>>
>>> Define breaking. Ideally with a stack trace.
>>>
>>> Mark
>>>
>>>
 I think the reason is the extra validation check introduced in 
 ResourceLinkFactory class. My application has its own classloader 
 and when I try to fetch the JNDI resource, the Thread's classloader 
 is my custom one rather than the default one. Because of that 
 validation fails and tomcat returns NULL. Is there a way to fix this 
 through configuration or any other means?

 Regards, Chinoy


>>>
>>>
>>> -
>>>
>>>
>> 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
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For 

Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Leon Rosenberg
Hi Tullio,

you could download and integrate MoSKito -> http://www.moskito.org. After
integration as described here
blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/ or
here: http://www.moskito.org/integration.html you can start your
application and setup a tracer.
A tracer, explained here:
http://blog.anotheria.net/msk/newest-hottest-tracers/, can be used to
automatically trace all requests passing a specific point and compare the
execution times. It will keep the longest requests along with the execution
time in each monitored component.
So if there is some part of code you have, that lasts longer from time to
time, the tracer will find it.

regards
Leon


On Mon, Oct 3, 2016 at 2:12 PM, Mark Thomas  wrote:

> On 03/10/2016 11:19, Tullio Bettinazzi wrote:
> > I already use Yourkit but it doesn't seems a load problem.
> >
> > The delay is not spread over all operaions but concentred in only one or
> two and allways takes 4 secs more than the normal operation  time.
> >
> > Could You suggest how to use Yourkit in this schenario ?
>
> I'd look at GC activity and detailed CPU profiling.
>
> Mark
>
> >
> > Tks
> >
> > Tullio
> >
> >
> > 
> > Da: Mark Thomas 
> > Inviato: lunedì 3 ottobre 2016 10.39
> > A: Tomcat Users List
> > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
> >
> > On 03/10/2016 08:56, Tullio Bettinazzi wrote:
> >> I've an application under tomcat.
> >> When only a one or two users works on it everithing is ok.
> >> When the number of users grows the application slows down.
> >> Is not a memory nor a cpu problem : using top I see the system
> resources quite free.
> >> I don't see relevant garbage collection : heap size and permgen have
> correct dimentions.
> >> No other applications are running on the system.
> >> I log more or less every relevant operation in my system (db query and
> so on) and I see that every slowdown is concentered in a single operation.
> >> I mean all operations take "normal" time but one or two of them take 4
> seconds more.
> >> The "slowing" operations are not the same in different executions, and
> theydo not have a specific type (not only DB query, not only DB stored
> procedures, not only.).
> >> It seems like if the thread is frozen for a fixed amount fo time (4
> seconds more or less) and then it restarts.
> >> I don't think it's a "queue" problem because otherwise the wait time
> would be unperdictable and not a "fixed" 4 seconds time.
> >> I don't know any parameter impacting on that behaviour.
> >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> >> Could someone suggest a solution for my problem or, at least, an
> investigation strategy.
> >
> > https://www.yourkit.com/java/profiler/features/
> > Performance and Memory Java Profiler - YourKit Java Profiler<
> https://www.yourkit.com/java/profiler/features/>
> > www.yourkit.com
> > Easy to use performance and memory profiler for .NET framework. Supports
> ASP.NET, Silverlight, .NET Windows services and more.
> >
> >
> >
> >
> > Mark
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Mark Thomas
On 03/10/2016 11:19, Tullio Bettinazzi wrote:
> I already use Yourkit but it doesn't seems a load problem.
> 
> The delay is not spread over all operaions but concentred in only one or two 
> and allways takes 4 secs more than the normal operation  time.
> 
> Could You suggest how to use Yourkit in this schenario ?

I'd look at GC activity and detailed CPU profiling.

Mark

> 
> Tks
> 
> Tullio
> 
> 
> 
> Da: Mark Thomas 
> Inviato: lunedì 3 ottobre 2016 10.39
> A: Tomcat Users List
> Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
> 
> On 03/10/2016 08:56, Tullio Bettinazzi wrote:
>> I've an application under tomcat.
>> When only a one or two users works on it everithing is ok.
>> When the number of users grows the application slows down.
>> Is not a memory nor a cpu problem : using top I see the system resources 
>> quite free.
>> I don't see relevant garbage collection : heap size and permgen have correct 
>> dimentions.
>> No other applications are running on the system.
>> I log more or less every relevant operation in my system (db query and so 
>> on) and I see that every slowdown is concentered in a single operation.
>> I mean all operations take "normal" time but one or two of them take 4 
>> seconds more.
>> The "slowing" operations are not the same in different executions, and 
>> theydo not have a specific type (not only DB query, not only DB stored 
>> procedures, not only.).
>> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
>> more or less) and then it restarts.
>> I don't think it's a "queue" problem because otherwise the wait time would 
>> be unperdictable and not a "fixed" 4 seconds time.
>> I don't know any parameter impacting on that behaviour.
>> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
>> Could someone suggest a solution for my problem or, at least, an 
>> investigation strategy.
> 
> https://www.yourkit.com/java/profiler/features/
> Performance and Memory Java Profiler - YourKit Java 
> Profiler
> www.yourkit.com
> Easy to use performance and memory profiler for .NET framework. Supports 
> ASP.NET, Silverlight, .NET Windows services and more.
> 
> 
> 
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 


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



Re: Is there a 6.0.x patch for CVE-2016-5388?

2016-10-03 Thread tomcat

On 03.10.2016 13:10, André Warnier (tomcat) wrote:

On 03.10.2016 13:03, Vamsavardhana Reddy wrote:

Hi,

Is there a 6.0.x patch for CVE-2016-5388? I do not see it listed in
https://tomcat.apache.org/security-6.html .


Hi.
If you really mean "patch", see

http://tomcat.apache.org/security.html
First paragraph.

Also see
http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities
3rd paragraph

Or do you mean "version" or "release" ?



Also, if you search for "CVE-2016-5388", it leads you to a page with a complete 
explanation of what it is about,
and even source code for how to avoid the issue under Tomcat, assuming that it is even 
applicable in your case.




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



Re: Is there a 6.0.x patch for CVE-2016-5388?

2016-10-03 Thread tomcat

On 03.10.2016 13:03, Vamsavardhana Reddy wrote:

Hi,

Is there a 6.0.x patch for CVE-2016-5388? I do not see it listed in
https://tomcat.apache.org/security-6.html .


Hi.
If you really mean "patch", see

http://tomcat.apache.org/security.html
First paragraph.

Also see
http://tomcat.apache.org/security-6.html#Apache_Tomcat_6.x_vulnerabilities
3rd paragraph

Or do you mean "version" or "release" ?


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



Is there a 6.0.x patch for CVE-2016-5388?

2016-10-03 Thread Vamsavardhana Reddy
Hi,

Is there a 6.0.x patch for CVE-2016-5388? I do not see it listed in
https://tomcat.apache.org/security-6.html .

Thanks and best regards,
Vamsi


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Tullio Bettinazzi
I already use Yourkit but it doesn't seems a load problem.

The delay is not spread over all operaions but concentred in only one or two 
and allways takes 4 secs more than the normal operation  time.

Could You suggest how to use Yourkit in this schenario ?

Tks

Tullio



Da: Mark Thomas 
Inviato: lunedì 3 ottobre 2016 10.39
A: Tomcat Users List
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

On 03/10/2016 08:56, Tullio Bettinazzi wrote:
> I've an application under tomcat.
> When only a one or two users works on it everithing is ok.
> When the number of users grows the application slows down.
> Is not a memory nor a cpu problem : using top I see the system resources 
> quite free.
> I don't see relevant garbage collection : heap size and permgen have correct 
> dimentions.
> No other applications are running on the system.
> I log more or less every relevant operation in my system (db query and so on) 
> and I see that every slowdown is concentered in a single operation.
> I mean all operations take "normal" time but one or two of them take 4 
> seconds more.
> The "slowing" operations are not the same in different executions, and theydo 
> not have a specific type (not only DB query, not only DB stored procedures, 
> not only.).
> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
> more or less) and then it restarts.
> I don't think it's a "queue" problem because otherwise the wait time would be 
> unperdictable and not a "fixed" 4 seconds time.
> I don't know any parameter impacting on that behaviour.
> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> Could someone suggest a solution for my problem or, at least, an 
> investigation strategy.

https://www.yourkit.com/java/profiler/features/
Performance and Memory Java Profiler - YourKit Java 
Profiler
www.yourkit.com
Easy to use performance and memory profiler for .NET framework. Supports 
ASP.NET, Silverlight, .NET Windows services and more.




Mark


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



Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Mark Thomas
On 03/10/2016 08:56, Tullio Bettinazzi wrote:
> I've an application under tomcat.
> When only a one or two users works on it everithing is ok.
> When the number of users grows the application slows down.
> Is not a memory nor a cpu problem : using top I see the system resources 
> quite free.
> I don't see relevant garbage collection : heap size and permgen have correct 
> dimentions.
> No other applications are running on the system.
> I log more or less every relevant operation in my system (db query and so on) 
> and I see that every slowdown is concentered in a single operation.
> I mean all operations take "normal" time but one or two of them take 4 
> seconds more.
> The "slowing" operations are not the same in different executions, and theydo 
> not have a specific type (not only DB query, not only DB stored procedures, 
> not only.).
> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
> more or less) and then it restarts.
> I don't think it's a "queue" problem because otherwise the wait time would be 
> unperdictable and not a "fixed" 4 seconds time.
> I don't know any parameter impacting on that behaviour.
> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> Could someone suggest a solution for my problem or, at least, an 
> investigation strategy.

https://www.yourkit.com/java/profiler/features/

Mark


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



Strange wait time in my application - Tomcat 7.0.67

2016-10-03 Thread Tullio Bettinazzi
I've an application under tomcat.
When only a one or two users works on it everithing is ok.
When the number of users grows the application slows down.
Is not a memory nor a cpu problem : using top I see the system resources quite 
free.
I don't see relevant garbage collection : heap size and permgen have correct 
dimentions.
No other applications are running on the system.
I log more or less every relevant operation in my system (db query and so on) 
and I see that every slowdown is concentered in a single operation.
I mean all operations take "normal" time but one or two of them take 4 seconds 
more.
The "slowing" operations are not the same in different executions, and theydo 
not have a specific type (not only DB query, not only DB stored procedures, not 
only.).
It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
more or less) and then it restarts.
I don't think it's a "queue" problem because otherwise the wait time would be 
unperdictable and not a "fixed" 4 seconds time.
I don't know any parameter impacting on that behaviour.
I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
Could someone suggest a solution for my problem or, at least, an investigation 
strategy.
Tks

Tullio