Http 403: access to requested resource denied

2016-02-02 Thread prashant sharma
Hi,
I am using apache tomcat 7.0.57 and jdk 7 on windows 7.
I have deployed a simple web application inside tomcat webapps folder by
placing the war file directly in webapps.
This is a basic application which exposes an endpoint with put request
method.

When I try to access this endpoint I get 403 access forbidden error.

However If I place war file outside tomcat  and point it by creating
context.xml in conf/Catalina/localhost I am able to access my endpoint.

Can someone pls tell what's wrong with the first approach and why its not
working in that

Regards,
Prashant

07440456543


Problem with Tomcat Cluster

2016-02-02 Thread Edwin Quijada
Hi!
I have a Tomcat cluster over Debian Jessie, Tomcat 8.0.29 2 instances , 
PostgreSQL 9.5 ,Apache 2.4 , Mod_jk. When I try to run my project in this 
environment I get eerror. I tested with examples project and it works fine. My 
log iis this


01-Feb-2016 19:07:39.474 SEVERE [main] 
org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can only 
work as host cluster subelement!
01-Feb-2016 19:07:39.537 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployWAR Despliegue del archivo 
/opt/tomcat8_nodo1/webapps/clusterjsp.war de la aplicación web
01-Feb-2016 19:07:40.886 INFO 
[MessageDispatch15Interceptor.MessageDispatchThread1] 
org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.report 
ThroughputInterceptor Report[
Tx Msg:1 messages
Sent:0.00 MB (total)
Sent:0.00 MB (application)
Time:0.01 seconds
Tx Speed:0.06 MB/sec (total)
TxSpeed:0.06 MB/sec (application)
Error Msg:0
Rx Msg:2 messages
Rx Speed:0.00 MB/sec (since 1st msg)
Received:0.00 MB]

01-Feb-2016 19:07:42.068 INFO [localhost-startStop-1] 
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of 
SecureRandom instance for session ID generation using [SHA1PRNG] took [1.489] 
milliseconds.
01-Feb-2016 19:07:42.088 INFO [localhost-startStop-1] 
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init Initializing 
AbstractReplicatedMap with context name:localhost#/clusterjsp-map
01-Feb-2016 19:07:42.310 INFO [localhost-startStop-1] 
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init 
AbstractReplicatedMap[localhost#/clusterjsp-map] initialization was completed 
in 222 ms.
01-Feb-2016 19:07:42.585 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application 
archive /opt/tomcat8_nodo1/webapps/clusterjsp.war has finished in 3.048 ms
01-Feb-2016 19:07:45.652 INFO [localhost-startStop-1] 
org.apache.catalina.startup.HostConfig.deployWAR Despliegue del archivo 
/opt/tomcat8_nodo1/webapps/abacus.war de la aplicación web
01-Feb-2016 19:14:05.387 INFO [localhost-startStop-1] 
org.apache.jasper.servlet.TldScanner.scanJars Al menos un JAR, que se ha 
explorado buscando TLDs, aún no contenía TLDs. Activar historial de depuración 
para este historiador para una completa lista de los JARs que fueron explorados 
y de los que nos se halló TLDs. Saltarse JARs no necesarios durante la 
exploración puede dar lugar a una mejora de tiempo significativa en el arranque 
y compilación de JSP .
feb 01, 2016 7:14:05 PM org.apache.catalina.core.ApplicationContext log
INFORMACIÓN: Initializing AtmosphereFramework
feb 01, 2016 7:14:05 PM org.apache.catalina.core.ApplicationContext log
INFORMACIÓN: No Spring WebApplicationInitializer types detected on classpath
feb 01, 2016 7:14:06 PM org.apache.catalina.core.ApplicationContext log
INFORMACIÓN: Initializing Spring root WebApplicationContext
feb 01, 2016 7:14:54 PM org.apache.tomcat.jdbc.pool.ConnectionPool init
ADVERTENCIA: maxActive is smaller than 1, setting maxActive to: 100
2016-02-01 19:14:59,345 [localhost-startStop-1] ERROR 
context.GrailsContextLoaderListener  - Error initializing the application: 
Error creating bean with name 
'org.springframework.context.annotation.internalAsyncAnnotationProcessor' 
defined in class path resource 
[org/springframework/scheduling/annotation/ProxyAsyncConfiguration.class]: 
Instantiation of bean failed; nested exception is 
org.springframework.beans.factory.BeanDefinitionStoreException: Factory method 
[public 
org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor 
org.springframework.scheduling.annotation.ProxyAsyncConfiguration.asyncAdvisor()]
 threw exception; nested exception is java.lang.IllegalArgumentException: 
@EnableAsync annotation metadata was not injected
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 
'org.springframework.context.annotation.internalAsyncAnnotationProcessor' 
defined in class path resource 
[org/springframework/scheduling/annotation/ProxyAsyncConfiguration.class]: 
Instantiation of bean failed; nested exception is 
org.springframework.beans.factory.BeanDefinitionStoreException: Factory method 
[public 
org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor 
org.springframework.scheduling.annotation.ProxyAsyncConfiguration.asyncAdvisor()]
 threw exception; nested exception is java.lang.IllegalArgumentException: 
@EnableAsync annotation metadata was not injected
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: 

Installing APR based Apache Tomcat Native Library

2016-02-02 Thread Yuval Schwartz
Thanks. Answers below

On Tuesday, 2 February 2016, Christopher Schultz <
ch...@christopherschultz.net
> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yuval,
>
> On 2/2/16 9:28 AM, Yuval Schwartz wrote:
> > On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Yuval,
> >
> > On 2/2/16 6:21 AM, Yuval Schwartz wrote:
>  Hello again Christoph,
> 
>  I think there is a problem with the way that I installed the
>  APR library. If you recall, I installed a compiled version
>  from the distros with the commands yum install apr-devel
>  openssl-devel tomcat-native
> 
>  I get the desired "Loaded APR based library" in my logs.
>  However, every time I shut down tomcat I get a warning:
> 
>  WARNING [main]
>  org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
>  The executor associated with thread pool [http-apr-8080] has
>  not fully shutdown. Some application threads may still be
>  running
> 
>  If I remove the packages that I installed (yum remove
>  apr-devel openssl-devel tomcat-native) then this warning goes
>  away.
> 
>  Is there something that I forgot to configure when installing
>  the APR library?
> >
> > What makes you think that something is wrong with the library?
> > Perhaps you are getting that WARNING because you have
> > still-running request-processing threads?
> >
> >
> >> Thanks, any ideas on how I can look into this then? I've tried
> >> looking at thread dumps and at the threads that are created and
> >> destroyed in my ServletContextListener's contextInitialize and
> >> contextDestroyed methods.
>
> So, just to confirm, when you attempt to shut-down Tomcat, you get
> that WARNING and if you take a thread dump after that warning, you
> have threads still running contextInitialized and contextDestroyed?


When I shut down I get that message (I am able to shut down successfully, I
just get that message right before).
I can't take a thread dump after I get the message because tomcat is no
longer running (i.e. There are no Java processes taking place for me to
perform a thread dump on).
I mentioned contextInitialized and contextDestroyed simply because I used
those methods to print information about threads that were running in order
to try to get a better idea of what's going on (i.e. Using
Thread.getAllStackTraces()).



>
> The thread the WARNING is talking about will be one of the HTTP
> request processor threads (it even tells you which thread pool is
> still in use: http-apr-8080). If you have some long-running requests,
> you may get that WARNING during shutdown, but shutdown can still
> succeed after those threads complete.
>
>
When I take a thread dump while the application is running I see threads
called http-apr-8080-exec-1, http-apr-8080-exec-2, etc. do these threads
belong to the pool that the warning is referring to?

Are you saying I don't need to pay attention to this warning?
As a side question: why should it concern me that a thread might stay open
when tomcat is shutting down? If tomcat is shutting down then won't all
threads be destroyed anyway?


> > If the library loads, I think you installed it properly ;)
> >
> >
> >> Yes, I just reinstalled by compiling the source code and I still
> >> get the same error...so it's not the library.
>
> If you are okay with the library version available from your Linux
> distro, you should stick with that.


I mentioned this point because, interestingly, when I don't use the apr
library (i.e. I use the standard nio) then I don't see the warning that
we're discussing.


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlaxDPgACgkQ9CaO5/Lv0PAgbACeN/Pw1NF+f8Ak9HXeS27vlUKp
> 8QAAnirgkqU04C9kTVixWDuDz0jZeBE5
> =hEat
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Problem with Tomcat Cluster

2016-02-02 Thread Mikel Ibiricu
Are you sure it starts in non-clustered environment? It sounda to me to be
just a spring initialization error.
El 02/02/2016 22:40, "Edwin Quijada"  escribió:

> Hi!
> I have a Tomcat cluster over Debian Jessie, Tomcat 8.0.29 2 instances ,
> PostgreSQL 9.5 ,Apache 2.4 , Mod_jk. When I try to run my project in this
> environment I get eerror. I tested with examples project and it works fine.
> My log iis this
>
>
> 01-Feb-2016 19:07:39.474 SEVERE [main]
> org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can
> only work as host cluster subelement!
> 01-Feb-2016 19:07:39.537 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Despliegue del archivo
> /opt/tomcat8_nodo1/webapps/clusterjsp.war de la aplicación web
> 01-Feb-2016 19:07:40.886 INFO
> [MessageDispatch15Interceptor.MessageDispatchThread1]
> org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.report
> ThroughputInterceptor Report[
> Tx Msg:1 messages
> Sent:0.00 MB (total)
> Sent:0.00 MB (application)
> Time:0.01 seconds
> Tx Speed:0.06 MB/sec (total)
> TxSpeed:0.06 MB/sec (application)
> Error Msg:0
> Rx Msg:2 messages
> Rx Speed:0.00 MB/sec (since 1st msg)
> Received:0.00 MB]
>
> 01-Feb-2016 19:07:42.068 INFO [localhost-startStop-1]
> org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation
> of SecureRandom instance for session ID generation using [SHA1PRNG] took
> [1.489] milliseconds.
> 01-Feb-2016 19:07:42.088 INFO [localhost-startStop-1]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init Initializing
> AbstractReplicatedMap with context name:localhost#/clusterjsp-map
> 01-Feb-2016 19:07:42.310 INFO [localhost-startStop-1]
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init
> AbstractReplicatedMap[localhost#/clusterjsp-map] initialization was
> completed in 222 ms.
> 01-Feb-2016 19:07:42.585 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive /opt/tomcat8_nodo1/webapps/clusterjsp.war has finished
> in 3.048 ms
> 01-Feb-2016 19:07:45.652 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Despliegue del archivo
> /opt/tomcat8_nodo1/webapps/abacus.war de la aplicación web
> 01-Feb-2016 19:14:05.387 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars Al menos un JAR, que se ha
> explorado buscando TLDs, aún no contenía TLDs. Activar historial de
> depuración para este historiador para una completa lista de los JARs que
> fueron explorados y de los que nos se halló TLDs. Saltarse JARs no
> necesarios durante la exploración puede dar lugar a una mejora de tiempo
> significativa en el arranque y compilación de JSP .
> feb 01, 2016 7:14:05 PM org.apache.catalina.core.ApplicationContext log
> INFORMACIÓN: Initializing AtmosphereFramework
> feb 01, 2016 7:14:05 PM org.apache.catalina.core.ApplicationContext log
> INFORMACIÓN: No Spring WebApplicationInitializer types detected on
> classpath
> feb 01, 2016 7:14:06 PM org.apache.catalina.core.ApplicationContext log
> INFORMACIÓN: Initializing Spring root WebApplicationContext
> feb 01, 2016 7:14:54 PM org.apache.tomcat.jdbc.pool.ConnectionPool init
> ADVERTENCIA: maxActive is smaller than 1, setting maxActive to: 100
> 2016-02-01 19:14:59,345 [localhost-startStop-1] ERROR
> context.GrailsContextLoaderListener  - Error initializing the application:
> Error creating bean with name
> 'org.springframework.context.annotation.internalAsyncAnnotationProcessor'
> defined in class path resource
> [org/springframework/scheduling/annotation/ProxyAsyncConfiguration.class]:
> Instantiation of bean failed; nested exception is
> org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public
> org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor
> org.springframework.scheduling.annotation.ProxyAsyncConfiguration.asyncAdvisor()]
> threw exception; nested exception is java.lang.IllegalArgumentException:
> @EnableAsync annotation metadata was not injected
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name
> 'org.springframework.context.annotation.internalAsyncAnnotationProcessor'
> defined in class path resource
> [org/springframework/scheduling/annotation/ProxyAsyncConfiguration.class]:
> Instantiation of bean failed; nested exception is
> org.springframework.beans.factory.BeanDefinitionStoreException: Factory
> method [public
> org.springframework.scheduling.annotation.AsyncAnnotationBeanPostProcessor
> org.springframework.scheduling.annotation.ProxyAsyncConfiguration.asyncAdvisor()]
> threw exception; nested exception is java.lang.IllegalArgumentException:
> @EnableAsync annotation metadata was not injected
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at 

Re: Installing APR based Apache Tomcat Native Library

2016-02-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yuval,

On 2/2/16 9:28 AM, Yuval Schwartz wrote:
> On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Yuval,
> 
> On 2/2/16 6:21 AM, Yuval Schwartz wrote:
 Hello again Christoph,
 
 I think there is a problem with the way that I installed the
 APR library. If you recall, I installed a compiled version
 from the distros with the commands yum install apr-devel
 openssl-devel tomcat-native
 
 I get the desired "Loaded APR based library" in my logs.
 However, every time I shut down tomcat I get a warning:
 
 WARNING [main] 
 org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
 The executor associated with thread pool [http-apr-8080] has
 not fully shutdown. Some application threads may still be
 running
 
 If I remove the packages that I installed (yum remove
 apr-devel openssl-devel tomcat-native) then this warning goes
 away.
 
 Is there something that I forgot to configure when installing
 the APR library?
> 
> What makes you think that something is wrong with the library?
> Perhaps you are getting that WARNING because you have
> still-running request-processing threads?
> 
> 
>> Thanks, any ideas on how I can look into this then? I've tried
>> looking at thread dumps and at the threads that are created and
>> destroyed in my ServletContextListener's contextInitialize and
>> contextDestroyed methods.

So, just to confirm, when you attempt to shut-down Tomcat, you get
that WARNING and if you take a thread dump after that warning, you
have threads still running contextInitialized and contextDestroyed?

The thread the WARNING is talking about will be one of the HTTP
request processor threads (it even tells you which thread pool is
still in use: http-apr-8080). If you have some long-running requests,
you may get that WARNING during shutdown, but shutdown can still
succeed after those threads complete.

> If the library loads, I think you installed it properly ;)
> 
> 
>> Yes, I just reinstalled by compiling the source code and I still
>> get the same error...so it's not the library.

If you are okay with the library version available from your Linux
distro, you should stick with that.

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

iEYEARECAAYFAlaxDPgACgkQ9CaO5/Lv0PAgbACeN/Pw1NF+f8Ak9HXeS27vlUKp
8QAAnirgkqU04C9kTVixWDuDz0jZeBE5
=hEat
-END PGP SIGNATURE-

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



Re: rotate catalina.out without restart?

2016-02-02 Thread Harald Dunkel
Hi Christopher,

On 02/01/2016 05:07 PM, Christopher Schultz wrote:
> Harald,
> 
> On 2/1/16 10:42 AM, Harald Dunkel wrote:
>> would it be possible to integate apache's rotatelogs into
>> catalina.sh to support daily rotation of catalina.out without
>> restart?
> 
> Nope.
> 

:-(.

>> This would be #1 on my wish list for version 9.
> 
> If you use the Tomcat startup scripts, the shell is responsible for
> output redirection. Hacking that to pipe-through an external program
> (eg. chronolog, etc.) is possible but makes the scripts very complicated
> .

OK, then the question is why does catalina.sh write to catalina.out
at all? stdout/stderr of the script would be sufficient. Writing to
a hard wired log file without rotation is the worst option of all
(even if you can choose the file name).

> 
> If you want to rotate stdout/stderr logs, you should use jsvc or some
> other service-runner; they will know how to rotate those files. For
> example, jsvc can rotate those files when it receives a signal.
> 

Will this make catalina.out obsolete?


Regards
Harri

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



Re: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-02 Thread Terence M. Bandoian

On 2/2/2016 2:49 AM, Yuval Schwartz wrote:



On Mon, Feb 1, 2016 at 7:36 PM, Terence M. Bandoian > wrote:


On 2/1/2016 10:12 AM, Yuval Schwartz wrote:

Hello Terence,

Thanks for the input.
I shutdown the ScheduledExecutorService in the
contextDestroyed method of
the app's ServletContextListener class as well.
I also call shutDownNow() followed by an if statement with
!awaitTermination() as the condition.

Are you sure that the new warning that I'm getting is also
related to the
ScheduledExecutorService?
The warning again is:

WARNING [main] org.apache.tomcat.util.net
.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has
not fully
shutdown. Some application threads may still be running

I didn't find much information about http-apr-8080 on google.
When I do a thread dump while tomcat is running I see
http-apr-8080-exec-1,
http-apr-8080-exec-2,...http-apr-8080-exec-10.
I'm not sure what these do? Are these threads the same as
http-apr-8080
that is referenced in the warning?

How else can I go about debugging this message?

Thank you



Hi, Yuval-

I'm not sure the new warning is related to the way the
ScheduledExecutorService is stopped.  You mentioned though that
the previous warning was related so I thought I'd share my
experience. Here's the code I used:

public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;

executor.shutdown();

do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );

executor = null;

Thread.yield();


Java docs say use of this method is rarely necessary...so I'm a little 
hesitant to use it.


}
}

Notice the loop.

For the new warning, my suggestion would be to find out who owns
the thread in question.  Can you do that with the profiler?


Thanks. I don't use a profiler. I'm using Jstack, and at the time the 
application is running, when I do a thread dump, I don't see this 
thread ("http-apr-8080").


I also did some testing on my development environment and printing the 
threads right before tomcat shuts down prints some threads, but again, 
none are named "http-apr-8080" (although some are named 
http-apr-8080-exec-...).



Hope that helps.

-Terence Bandoian




On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian
>
wrote:

On 2/1/2016 8:54 AM, Yuval Schwartz wrote:

Hello Mark,

I think that the issue below was related to the way I
was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is
destroyed...I will
update here if I don't receive any more warnings.

However, I now get a warning:

WARNING [main] org.apache.tomcat.util.net

.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool
[http-apr-8080] has not fully
shutdown. Some application threads may still be running

I am not sure if this is related or not?
When I do a heap dump with jstack I see
http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?

Thanks.


Hi, Yuval-

Where are you shutting down the ScheduledExecutorService? 
I ran into a

similar problem trying to stop a ScheduledExecutorService
in the
contextDestroyed method of a ServletContextListener. 
Adding a call to

Thread.yield() after the executor was terminated removed
the warning.  To
terminate the executor, I used the shutdown() method
followed by a loop
with a call to awaitTermination().

-Terence Bandoian




On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz


Re: Installing APR based Apache Tomcat Native Library

2016-02-02 Thread Yuval Schwartz
On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yuval,
>
> On 2/2/16 6:21 AM, Yuval Schwartz wrote:
> > Hello again Christoph,
> >
> > I think there is a problem with the way that I installed the APR
> > library. If you recall, I installed a compiled version from the
> > distros with the commands yum install apr-devel openssl-devel
> > tomcat-native
> >
> > I get the desired "Loaded APR based library" in my logs. However,
> > every time I shut down tomcat I get a warning:
> >
> > WARNING [main]
> > org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The
> > executor associated with thread pool [http-apr-8080] has not fully
> > shutdown. Some application threads may still be running
> >
> > If I remove the packages that I installed (yum remove apr-devel
> > openssl-devel tomcat-native) then this warning goes away.
> >
> > Is there something that I forgot to configure when installing the
> > APR library?
>
> What makes you think that something is wrong with the library? Perhaps
> you are getting that WARNING because you have still-running
> request-processing threads?
>

Thanks, any ideas on how I can look into this then? I've tried looking at
thread dumps and at the threads that are created and destroyed in my
ServletContextListener's contextInitialize and contextDestroyed methods.


>
> If the library loads, I think you installed it properly ;)
>

Yes, I just reinstalled by compiling the source code and I still get the
same error...so it's not the library.


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlawuh8ACgkQ9CaO5/Lv0PAnhQCfcpg316jjclM41xnDjQtZrr9Z
> I7UAoLw0jg8tPK6m51HQDyXbCQnb402r
> =fZGU
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-02 Thread Terence M. Bandoian

On 2/1/2016 10:12 AM, Yuval Schwartz wrote:

Hello Terence,

Thanks for the input.
I shutdown the ScheduledExecutorService in the contextDestroyed method of
the app's ServletContextListener class as well.
I also call shutDownNow() followed by an if statement with
!awaitTermination() as the condition.

Are you sure that the new warning that I'm getting is also related to the
ScheduledExecutorService?
The warning again is:

WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

I didn't find much information about http-apr-8080 on google.
When I do a thread dump while tomcat is running I see http-apr-8080-exec-1,
http-apr-8080-exec-2,...http-apr-8080-exec-10.
I'm not sure what these do? Are these threads the same as http-apr-8080
that is referenced in the warning?

How else can I go about debugging this message?

Thank you



Hi, Yuval-

I'm not sure the new warning is related to the way the 
ScheduledExecutorService is stopped.  You mentioned though that the 
previous warning was related so I thought I'd share my experience. 
Here's the code I used:


public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;

executor.shutdown();

do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );

executor = null;

Thread.yield();
}
}

Notice the loop.

For the new warning, my suggestion would be to find out who owns the 
thread in question.  Can you do that with the profiler?


Hope that helps.

-Terence Bandoian




On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian 
wrote:


On 2/1/2016 8:54 AM, Yuval Schwartz wrote:


Hello Mark,

I think that the issue below was related to the way I was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is destroyed...I will
update here if I don't receive any more warnings.

However, I now get a warning:

WARNING [main] org.apache.tomcat.util.net
.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

I am not sure if this is related or not?
When I do a heap dump with jstack I see http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?

Thanks.



Hi, Yuval-

Where are you shutting down the ScheduledExecutorService?  I ran into a
similar problem trying to stop a ScheduledExecutorService in the
contextDestroyed method of a ServletContextListener.  Adding a call to
Thread.yield() after the executor was terminated removed the warning.  To
terminate the executor, I used the shutdown() method followed by a loop
with a call to awaitTermination().

-Terence Bandoian





On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz  wrote:

On 31/01/2016 08:06, Yuval Schwartz wrote:

Hellow Mark,

Thanks for the reply.
Follow up questions below.

On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas  wrote:

On 29/01/2016 14:34, Yuval Schwartz wrote:

Hello,

tomcat version: 8.0.22
java: jdk1.8.0_05
server: Amazon Linux AMI

I get the following warning message in my catalina log when I


undeploy a

web application:

*WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]]



org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads


The

web application [ROOT##002] appears to have started a thread named
[pool-2-thread-1] but has failed to stop it. This is very likely to


create


a memory leak. Stack trace of thread*

As you can see, for some reason, I don't get a stack trace of the


thread.

Therefore, I have no idea how to debug this warning.

This particular warning was generated when tomcat detected an unused
version and undeployed it (I set undeployOldVersions="true").

Does anyone know how I can debug this warning. How can I know more


about

this thread?

That looks like a thread from Commons Pool (possibly via DBCP). The


only
way to be sure you have a leak or not is to use a profiler. See




http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf


Is VisualVM a good profiler to start with considering my system?


Sorry, don't know. Never used it. I use YourKit, mainly because they
kindly donate free licenses to OpenSource developers to use with their
OpenSource projects.


Thank you Mark,

I installed VisualVM as a profiler.
I can now see all 

Re: Tomcat Server - Arraylist java.util.ConcurrentModificationException issue

2016-02-02 Thread Terence M. Bandoian

On 2/2/2016 3:54 AM, Subhro Paul wrote:

From:   "Terence M. Bandoian" 
To: Tomcat Users List 
Date:   02/01/2016 07:58 PM
Subject:Tomcat Server - Arraylist
java.util.ConcurrentModificationException issue



On 2/1/2016 6:50 AM, Subhro Paul wrote:

Hi Team,

Our web application has a "header.jsp" which has 2  Arraylist on it.

Each

ArrayList has more than 50 items inside. The code is to identify the
mobile device and requested page and transfer the call to mobile page
accordingly.

This code works fine once we restart the server and can continue running

2

months without any issue. But day by day it starts showing 500 error

with

exception in log "ConcurrentModificationException". Below is the code
snippet of JSP code. My Question is why this issue is happening around 2
months? If we clear the temp file created by the server in work folder
then that will run for some time( 2- 3 days) and then again the same
exception starts occurring. I have identified one solution by moving the
JAVA code from JSP to JAVA file which worked good while perform testing
but client wants to know the root cause of the issue.

FYI, earlier we had Vector in place of Arraylist which gave trouble of
thread blocking due to synchronization. So, converting from Arraylist to
Vector will not be a good idea.


Exception:

java.util.ConcurrentModificationException
  at
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
  at java.util.ArrayList$Itr.next(ArrayList.java:831)
  at
org.apache.jsp.includes.header_jsp.isHomePage(header_jsp.java:97)


Code Snippet:

<%!
private Set uas = new HashSet();
ArrayList urlnames = new ArrayList();
ArrayList excludePathList = new ArrayList();


Hi, Subhro-

Fields declared in a declarations section (<%!  ... %>) are class



That should be "instance" variables.


  
variables.  If Tomcat uses a single JSP object to serve multiple

requests, which I believe it does, access to these fields should be made
thread safe.  A simple solution would be to move the declarations of
these fields to a scriptlet section (<% ... %>) which would result in
them being local to the JSP service method.  It isn't the most efficient
way to go about it but it should solve the concurrent access problem
you're seeing.

-Terence Bandoian
/http://www.tmbsw.com/
/


private boolean haveToRedirect(HttpServletRequest request,
  String stopMobiCookie) {
  boolean doRedirect = false;

  String userAgent = request.getHeader("User-Agent");
  if (! stopMobiCookie.equals("yes") && userAgent != null &&
userAgent.length()!=0 && (userAgent.indexOf("UsableNet")==-1))
  {

  Iterator iter = uas.iterator();
  while (iter.hasNext()) {
  if (userAgent.indexOf((String)iter.next())!=-1)

{

  doRedirect = true;
  break;


  }
  }
  }
  return doRedirect;
}

  private boolean isHomePage(HttpServletRequest request){
  Iterator itr = urlnames.iterator();
  String path = "";
  while (itr.hasNext()) {
   path = itr.next();
   if
(request.getRequestURI().toString().equalsIgnoreCase(path)){
   return true;
   }
  }
  return false;
  }

  private boolean isExcludePath(HttpServletRequest request){
  Iterator itr = excludePathList.iterator();
  String path = "";
  while (itr.hasNext()) {
   path = itr.next();
   if (request.getRequestURI().startsWith(path)

&&

!request.getRequestURI().startsWith("/info/contact.jsp")){
   return true;
   }
  }
  return false;
  }

%>


<%

uas.add("Blazer");
uas.add("Danger hiptop");
uas.add("DoCoMo/");
uas.add("Ericsson");
uas.add("Googlebot-Mobile");
uas.add("MSN Mobile Proxy");
uas.add("Handheld");
uas.add("HTC_HD2_T58585 Opera");
uas.add("iPhone");
uas.add("iPod");
uas.add("Klondike");
uas.add("LG-");
uas.add("LGE-");
... Arround 40 items


excludePathList.add("/business/my_account");
excludePathList.add("/business/save_energy");
excludePathList.add("/business/services");
excludePathList.add("/business/small_large_business");
excludePathList.add("/info/environment");
excludePathList.add("/info/about");
excludePathList.add("/info/index.jsp");
excludePathList.add("/info/ambassador.jsp");
 more than 50 items


stopMobiCookie = some cookie code

boolean doRedirect = haveToRedirect((HttpServletRequest)request,
stopMobiCookie);


if(doRedirect){
  boolean isHomePage =

Re: Tomcat Server - Arraylist java.util.ConcurrentModificationException issue

2016-02-02 Thread Subhro Paul
From:   "Terence M. Bandoian" 
To: Tomcat Users List 
Date:   02/01/2016 07:58 PM
Subject:Tomcat Server - Arraylist 
java.util.ConcurrentModificationException issue



On 2/1/2016 6:50 AM, Subhro Paul wrote:
> Hi Team,
>
> Our web application has a "header.jsp" which has 2  Arraylist on it. 
Each
> ArrayList has more than 50 items inside. The code is to identify the
> mobile device and requested page and transfer the call to mobile page
> accordingly.
>
> This code works fine once we restart the server and can continue running 
2
> months without any issue. But day by day it starts showing 500 error 
with
> exception in log "ConcurrentModificationException". Below is the code
> snippet of JSP code. My Question is why this issue is happening around 2
> months? If we clear the temp file created by the server in work folder
> then that will run for some time( 2- 3 days) and then again the same
> exception starts occurring. I have identified one solution by moving the
> JAVA code from JSP to JAVA file which worked good while perform testing
> but client wants to know the root cause of the issue.
>
> FYI, earlier we had Vector in place of Arraylist which gave trouble of
> thread blocking due to synchronization. So, converting from Arraylist to
> Vector will not be a good idea.
>
>
> Exception:
>
> java.util.ConcurrentModificationException
>  at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
>  at java.util.ArrayList$Itr.next(ArrayList.java:831)
>  at
> org.apache.jsp.includes.header_jsp.isHomePage(header_jsp.java:97)
>
>
> Code Snippet:
>
> <%!
> private Set uas = new HashSet();
> ArrayList urlnames = new ArrayList();
> ArrayList excludePathList = new ArrayList();


Hi, Subhro-

Fields declared in a declarations section (<%!  ... %>) are class 
variables.  If Tomcat uses a single JSP object to serve multiple 
requests, which I believe it does, access to these fields should be made 
thread safe.  A simple solution would be to move the declarations of 
these fields to a scriptlet section (<% ... %>) which would result in 
them being local to the JSP service method.  It isn't the most efficient 
way to go about it but it should solve the concurrent access problem 
you're seeing.

-Terence Bandoian
/http://www.tmbsw.com/
/

>
> private boolean haveToRedirect(HttpServletRequest request,
>  String stopMobiCookie) {
>  boolean doRedirect = false;
> 
>  String userAgent = request.getHeader("User-Agent");
>  if (! stopMobiCookie.equals("yes") && userAgent != null &&
> userAgent.length()!=0 && (userAgent.indexOf("UsableNet")==-1))
>  {
>
>  Iterator iter = uas.iterator();
>  while (iter.hasNext()) {
>  if (userAgent.indexOf((String)iter.next())!=-1) 
{
>  doRedirect = true;
>  break;
>
>
>  }
>  }
>  }
>  return doRedirect;
> }
>
>  private boolean isHomePage(HttpServletRequest request){
>  Iterator itr = urlnames.iterator();
>  String path = "";
>  while (itr.hasNext()) {
>   path = itr.next();
>   if
> (request.getRequestURI().toString().equalsIgnoreCase(path)){
>   return true;
>   }
>  }
>  return false;
>  }
> 
>  private boolean isExcludePath(HttpServletRequest request){
>  Iterator itr = excludePathList.iterator();
>  String path = "";
>  while (itr.hasNext()) {
>   path = itr.next();
>   if (request.getRequestURI().startsWith(path) 
&&
> !request.getRequestURI().startsWith("/info/contact.jsp")){
>   return true;
>   }
>  }
>  return false;
>  }
>
> %>
>
>
> <%
>
> uas.add("Blazer");
> uas.add("Danger hiptop");
> uas.add("DoCoMo/");
> uas.add("Ericsson");
> uas.add("Googlebot-Mobile");
> uas.add("MSN Mobile Proxy");
> uas.add("Handheld");
> uas.add("HTC_HD2_T58585 Opera");
> uas.add("iPhone");
> uas.add("iPod");
> uas.add("Klondike");
> uas.add("LG-");
> uas.add("LGE-");
> ... Arround 40 items
>
>
> excludePathList.add("/business/my_account");
> excludePathList.add("/business/save_energy");
> excludePathList.add("/business/services");
> excludePathList.add("/business/small_large_business");
> excludePathList.add("/info/environment");
> excludePathList.add("/info/about");
> excludePathList.add("/info/index.jsp");
> excludePathList.add("/info/ambassador.jsp");
>  more than 50 items
>
>
> stopMobiCookie = some cookie code
>
> boolean doRedirect = haveToRedirect((HttpServletRequest)request,
> 

Re: Installing APR based Apache Tomcat Native Library

2016-02-02 Thread Yuval Schwartz
Hello again Christoph,

I think there is a problem with the way that I installed the APR library.
If you recall, I installed a compiled version from the distros with the
commands
yum install apr-devel openssl-devel tomcat-native

I get the desired "Loaded APR based library" in my logs.
However, every time I shut down tomcat I get a warning:

WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

If I remove the packages that I installed (yum remove apr-devel
openssl-devel tomcat-native) then this warning goes away.

Is there something that I forgot to configure when installing the APR
library?

Thank you
_

On Thu, Jan 28, 2016 at 2:34 PM, Yuval Schwartz 
wrote:

> Thank you Christoph,
>
> I installed a compiled version from the distros on my production servers
> and I installed the binary version from
> http://tomcat.apache.org/download-native.cgi
> on my development server.
>
> A slight problem is that when I install from the distros I don't have
> control of the version and therefore there is a slight mismatch between my
> development and production environments (development version: Apache Tomcat
> Native Library 1.1.34 using APR 1.5.1, production version: Apache Tomcat
> Native Library 1.1.33 using APR 1.5.1)
>
>
> Thank you
>
> On Thu, Jan 28, 2016 at 10:27 AM, Christoph Nenning <
> christoph.nenn...@lex-com.net> wrote:
>
>> > Hello,
>> >
>> > tomcat version: 8.0.22
>> > java: jdk1.8.0_05
>> > server: Amazon Linux AMI
>> >
>> > When deploying my web application to my production environment (detailed
>> > above), I get a message:
>> >
>> >
>> >
>> > *The APR based Apache Tomcat Native library which allows optimal
>> > performance in production environments was not found on the
>> > java.library.path*
>> > So I wanted to install the Apache Tomcat Native library (does this
>> improve
>> > performance even for a web app that doesn't use SSL?)
>> > According to the documentation: http://tomcat.apache.org/native-doc/
>> > I installed the apr-devel and openssl-devel packages with the command:
>> >
>> > yum install apr-devel openssl-devel
>> >
>> > However, I don't understand the next part of the instructions which
>> > discusses the "make && make install" command.
>> > From where do I run this command? I searched and I could not find a
>> > "jni/native" directory.
>> > From where do I run the "./configure --help" command and the other
>> > "./configure" commands?
>> >
>> > Thank you.
>>
>>
>> Those commands mean you compile source code of those libraries. So you
>> have to either download source code as zip archives and extract them or
>> check it out from version control. You probably need more C development
>> tools like a compiler.
>>
>>
>> Instead of compiling it yourself you can try to install a precompiled
>> version from your linux disros repositories:
>>
>> yum install apr tomcat-native
>>
>> If you use a recent version of tomcat it might happen that precompiled
>> libraries are outdated.
>>
>> If you just want to avoid that log message you can disable apr connector
>> AprLifecycleListener in server.xml.
>>
>>
>>
>> Regards,
>> Christoph
>>
>> This Email was scanned by Sophos Anti Virus
>>
>
>


RE: rotate catalina.out without restart?

2016-02-02 Thread Caldarale, Charles R
> From: Harald Dunkel [mailto:harald.dun...@aixigo.de] 
> Subject: Re: rotate catalina.out without restart?

> OK, then the question is why does catalina.sh write to catalina.out
> at all? stdout/stderr of the script would be sufficient.

And where would you have the output go when Tomcat is run as a service?  The 
redirection to catalina.out is there not for the benefit of the script, but 
rather to handle sloppily-written webapps that dump things into stdout or 
stderr rather than using a logger.  If you want to eliminate writing to 
catalina.out, set swallowOutput to true in the  elements of the 
offending (and offensive) webapps.

 - 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



RE: rotate catalina.out without restart?

2016-02-02 Thread RAY, DAVID

> From: Harald Dunkel [mailto:harald.dun...@aixigo.de] 
> Subject: Re: rotate catalina.out without restart?

> OK, then the question is why does catalina.sh write to catalina.out
> at all? stdout/stderr of the script would be sufficient.

>And where would you have the output go when Tomcat is run as a service?  The 
>redirection to catalina.out is there not for the benefit of the script, but 
>rather to handle sloppily->written webapps that dump things into stdout or 
>stderr rather than using a logger.  If you want to eliminate writing to 
>catalina.out, set swallowOutput to true in the  >elements of the 
>offending (and offensive) webapps.

 >- Chuck


Did you not read his response CHUCK???   He just told you.  I quote:  " 
stdout/stderr of the script would be sufficient"   Not that I have an opinion 
one way or the other.  Just pointing out the obvious.



-
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: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-02 Thread Yuval Schwartz
Hello Terence,


Can you explain what you mean when you say "who owns the thread"?

On Tue, Feb 2, 2016 at 5:18 PM, Terence M. Bandoian 
wrote:

> On 2/2/2016 2:49 AM, Yuval Schwartz wrote:
>
>>
>>
>> On Mon, Feb 1, 2016 at 7:36 PM, Terence M. Bandoian > > wrote:
>>
>> On 2/1/2016 10:12 AM, Yuval Schwartz wrote:
>>
>> Hello Terence,
>>
>> Thanks for the input.
>> I shutdown the ScheduledExecutorService in the
>> contextDestroyed method of
>> the app's ServletContextListener class as well.
>> I also call shutDownNow() followed by an if statement with
>> !awaitTermination() as the condition.
>>
>> Are you sure that the new warning that I'm getting is also
>> related to the
>> ScheduledExecutorService?
>> The warning again is:
>>
>> WARNING [main] org.apache.tomcat.util.net
>> > >.AbstractEndpoint.shutdownExecutor
>> The executor associated with thread pool [http-apr-8080] has
>> not fully
>> shutdown. Some application threads may still be running
>>
>> I didn't find much information about http-apr-8080 on google.
>> When I do a thread dump while tomcat is running I see
>> http-apr-8080-exec-1,
>> http-apr-8080-exec-2,...http-apr-8080-exec-10.
>> I'm not sure what these do? Are these threads the same as
>> http-apr-8080
>> that is referenced in the warning?
>>
>> How else can I go about debugging this message?
>>
>> Thank you
>>
>>
>>
>> Hi, Yuval-
>>
>> I'm not sure the new warning is related to the way the
>> ScheduledExecutorService is stopped.  You mentioned though that
>> the previous warning was related so I thought I'd share my
>> experience. Here's the code I used:
>>
>> public void contextDestroyed( ServletContextEvent sce )
>> {
>> if ( executor != null )
>> {
>> boolean isTerminated = false;
>>
>> executor.shutdown();
>>
>> do
>> {
>> try
>> {
>> isTerminated = executor.awaitTermination(
>> 1, TimeUnit.SECONDS );
>> }
>> catch ( InterruptedException ignore )
>> {
>> }
>> }
>> while ( !isTerminated );
>>
>> executor = null;
>>
>> Thread.yield();
>>
>>
>> Java docs say use of this method is rarely necessary...so I'm a little
>> hesitant to use it.
>>
>> }
>> }
>>
>> Notice the loop.
>>
>> For the new warning, my suggestion would be to find out who owns
>> the thread in question.  Can you do that with the profiler?
>>
>>
>> Thanks. I don't use a profiler. I'm using Jstack, and at the time the
>> application is running, when I do a thread dump, I don't see this thread
>> ("http-apr-8080").
>>
>> I also did some testing on my development environment and printing the
>> threads right before tomcat shuts down prints some threads, but again, none
>> are named "http-apr-8080" (although some are named http-apr-8080-exec-...).
>>
>>
>> Hope that helps.
>>
>> -Terence Bandoian
>>
>>
>>
>>
>> On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian
>> >
>> wrote:
>>
>> On 2/1/2016 8:54 AM, Yuval Schwartz wrote:
>>
>> Hello Mark,
>>
>> I think that the issue below was related to the way I
>> was shutting down an
>> instance of ScheduledExecutorService.
>> I changed the way it is shutdown when the context is
>> destroyed...I will
>> update here if I don't receive any more warnings.
>>
>> However, I now get a warning:
>>
>> WARNING [main] org.apache.tomcat.util.net
>> 
>> .AbstractEndpoint.shutdownExecutor
>> The executor associated with thread pool
>> [http-apr-8080] has not fully
>> shutdown. Some application threads may still be running
>>
>> I am not sure if this is related or not?
>> When I do a heap dump with jstack I see
>> http-apr-8080-exec-[1-10] but I
>> don't see any thread named http-apr-8080.
>> Any ideas on how to trouble shoot this?
>>
>> Thanks.
>>
>>
>> Hi, Yuval-
>>
>> Where are you shutting down the ScheduledExecutorService?
>>  I ran into a
>> similar problem trying to stop a ScheduledExecutorService
>> in the
>>

Re: Installing APR based Apache Tomcat Native Library

2016-02-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yuval,

On 2/2/16 6:21 AM, Yuval Schwartz wrote:
> Hello again Christoph,
> 
> I think there is a problem with the way that I installed the APR
> library. If you recall, I installed a compiled version from the
> distros with the commands yum install apr-devel openssl-devel
> tomcat-native
> 
> I get the desired "Loaded APR based library" in my logs. However,
> every time I shut down tomcat I get a warning:
> 
> WARNING [main]
> org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The
> executor associated with thread pool [http-apr-8080] has not fully 
> shutdown. Some application threads may still be running
> 
> If I remove the packages that I installed (yum remove apr-devel 
> openssl-devel tomcat-native) then this warning goes away.
> 
> Is there something that I forgot to configure when installing the
> APR library?

What makes you think that something is wrong with the library? Perhaps
you are getting that WARNING because you have still-running
request-processing threads?

If the library loads, I think you installed it properly ;)

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

iEYEARECAAYFAlawuh8ACgkQ9CaO5/Lv0PAnhQCfcpg316jjclM41xnDjQtZrr9Z
I7UAoLw0jg8tPK6m51HQDyXbCQnb402r
=fZGU
-END PGP SIGNATURE-

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



Re: rotate catalina.out without restart?

2016-02-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harald,

On 2/2/16 3:06 AM, Harald Dunkel wrote:
> Hi Christopher,
> 
> On 02/01/2016 05:07 PM, Christopher Schultz wrote:
>> Harald,
>> 
>> On 2/1/16 10:42 AM, Harald Dunkel wrote:
>>> would it be possible to integate apache's rotatelogs into 
>>> catalina.sh to support daily rotation of catalina.out without 
>>> restart?
>> 
>> Nope.
>> 
> 
> :-(.
> 
>>> This would be #1 on my wish list for version 9.
>> 
>> If you use the Tomcat startup scripts, the shell is responsible
>> for output redirection. Hacking that to pipe-through an external
>> program (eg. chronolog, etc.) is possible but makes the scripts
>> very complicated .
> 
> OK, then the question is why does catalina.sh write to
> catalina.out at all? stdout/stderr of the script would be
> sufficient. Writing to a hard wired log file without rotation is
> the worst option of all (even if you can choose the file name).

When you run "bin/catalina.sh start" you are implicitly requesting
your stdout/stderr be redirected. If you don't want that to happen,
don't run it that way.

Try this:

$ bin/catalina.sh start | whatever_you_want

>> If you want to rotate stdout/stderr logs, you should use jsvc or
>> some other service-runner; they will know how to rotate those
>> files. For example, jsvc can rotate those files when it receives
>> a signal.
>> 
> 
> Will this make catalina.out obsolete?

If you use jsvc, catalina.out is not a factor at all. The state of its
obsolescence is up to you.

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

iEYEARECAAYFAlawupMACgkQ9CaO5/Lv0PDuVACgo8NsBHw1sSvF9VZHB8O4+wIJ
314AnAspyFr8IEMyLlBc+0Pz/+Zoh/bw
=b8e0
-END PGP SIGNATURE-

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