Hi all,
I am trying to put together a systemd script for an install of the current
binary release tomcat7. Follows my current best effort, cobbled together from
the (RH)EL7 packaged version and some googling... I am trying to use the
unadulterated tomcat up/down scripts from the binary
Process explorer, select columns, Process I/O, delta total bytes might show the
story.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Christopher Schultz wrote:
- -1 CPU
+1 I/O
Dale wrote:
We found issues with trying to have log4j in catalina/lib.
That said, it would be nice to use log4j for tomcat, however we found
that the two configurations collided in our slf4j setup.
You can do this if you put log4j.jar into a server-only ClassLoader.
That's not configured
Alec: That seems like a good solution. Are you able to avoid having a
single giant catalina.out file in $CATALINA_HOME/logs?
No, we find we can live with that but we try to minimise writes to
stdout etc. From Chris's note it seems like the ideal solution for us
would be
1. server log4j
Currently we use tomcat configured as out-of-the-box for logging (no
log4j) and log4j.jar and config in the app war file.
We found issues with trying to have log4j in catalina/lib.
That said, it would be nice to use log4j for tomcat, however we found
that the two configurations collided in our
We chose slf4j with log4j underneath.
1. slf4j has nice optimal syntax:
Log.debug(The logged in user is {} {},firstName,lastName);
http://www.slf4j.org/faq.html#logging_performance
2. It has bridging apis to route other logging frameworks. If you are
using other libraries which use a different
Mark Thomas [mailto:ma...@apache.org] wrote:
snip other good stuff
In short, if there is something the Tomcat developers can do to help then we
would love to do so - just let us know.
Many thanks Mark, I'll definitely take careful notes next time I look at this
and report back.
Dale
Chris made the following good suggestion in another thread:
Can I make a suggestion? Fix your web application so it can cleanly un-deploy
and re-deploy and then simply do a hot deployment?
I've been down this track with our own Spring web apps and found it to be quite
a deep rabbit hole where
Martin Gainty wrote:
How did Mattias Jiderhamn's library help?
It resolved one of the memory leaks, which allowed me to progress on to the
next leak :-(
Dale
Hi all,
Saw this recently... Some java native code included in our tomcat
deployment contained an error, which caused a JVM segfault when a
webapp called the routine.
I was startled by the fact that this native code error brought down the
entire tomcat instance (all 15+ web apps) due to a
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Not quite. My point was the loading of the EL implementation is likely to be
triggered by user code. If the webapp class loader is the TCCL loader than
classes from the web app will be loaded before those from the
-Original Message-
From: Pid * [mailto:p...@pidster.com]
Where is that dependency JSP jar from?
It should not be in WEB-INF/lib if it's providing JSP functionality.
p
The manifest for the jar says JSP 2.1 Jasper implementation from Glassfish,
and yeah it was bad practice for maven to
Does this help?
https://forums.oracle.com/forums/thread.jspa?threadID=279238
So, I ran with JVM option -verbose:class
Then I requested a jsp from app1 and the console printed:
...
[Loaded javax.el.ExpressionFactory from
file:/C:/apache-tomcat-7.0.27/lib/el-api.jar]
[Loaded org.apache.jasper.runtime.JspApplicationContextImpl from
-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com]
Sent: Monday, 13 August 2012 5:46 p.m.
To: users@tomcat.apache.org
Dale,
Are you running this under Eclipse (looks like it)? If so, what happens
when you run the same test outside of Eclipse?
/mde/
Well, the
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
The above shows the problem (along with several other classes loaded
from that location).
Looks like you have some hard-coded links to the local file system
buried inside the webapp's META-INF entries -
-Original Message-
From: Daniel Mikusa [mailto:dmik...@vmware.com]
Maybe try adding the JVM option -verbose:class to bin/setenv.sh. This
option will cause the JVM to log when a class is loaded and from where it was
loaded.
Dan
The following class load output excerpt results when I
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Thursday, 9 August 2012 8:22 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot
be cast to org.apache.jasper.el.ELContextImpl
Dale Ogilvie dale_ogil
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
1. Tomcat 7.0.26 and earlier has static field
JspApplicationContextImpl.ExpressionFactory, so the EL implementation is
effectively shared between web applications.
Thanks for that info about the earlier bug in
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, 8 August 2012 7:44 p.m.
To: Tomcat Users List
Subject: RE: ClassCastException org.apache.jasper.runtime.ELContextImpl cannot
be cast to org.apache.jasper.el.ELContextImpl
Dale Ogilvie dale_ogil
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Again, that class is not a Tomcat class. As far as I can tell, that is party
of Jetty's JSP/EL implementation.
snip
Anyway, if you start adding JARs from one container into another then all
sorts of things can and will go
They are. However, if you have classes in a shared classloader used by
both webapps, and such a class is coded badly, references can leak from
one webapp to another.
BTW, jcifs.http.NtlmHttpFilter hasn't been viable for some years (no
possibility of supporting NTLMv2), so you might want to use
Daniel Mikusa [mailto:dmik...@vmware.com] wrote:
You would be using a shared class loader if you are placing JAR files used by
multiple deployed web applications into the
$CATALINA_BASE/lib or $CATALINA_HOME/lib directory. Are you placing any JAR
files into those folders?
We have placed
2012/8/3 Dale Ogilvie dale_ogil...@trimble.com:
Hi,
I'm seeing this problem below appearing now with one of our web-apps,
google has not helped me so far... There have been no changes with the
web app in question, which was working, so I'm picking something is
going on with either the tomcat
Hi,
I'm seeing this problem below appearing now with one of our web-apps, google
has not helped me so far... There have been no changes with the web app in
question, which was working, so I'm picking something is going on with either
the tomcat or OS (virtualized) environment, but what? Any
Just a thought from someone who knows nothing more than the contents of this
thread about the issue.
Would it make sense to only cache classes within a jar? i.e. empty the cache
when moving on to scan the next jar?
Possibly one might get enough performance benefit from intra-jar class
Mark Thomas wrote:
Your rant would be better aimed at the developers of the third party
libraries and JVMs that create the problems in the first place rather
than at the community that has worked hard to:
- prevent them causing an issue in the first place [1], [2]
- cleans up the mess they leave
In our webapps running on Tomcat 7 we have seen quite a number of
classloader memory leaks. The end result is that after a number of
application reloads and redeploys, we run out of permanent generation
memory and Tomcat stops responding. We can see the evidence of this sort
of issue thanks to the
FYI, Here's how we did it with APR for local workstation SSL.
Download APR from here: http://tomcat.apache.org/download-native.cgi
Copy the files (openssl.exe and tc-native.dll) into the tomcat bin
directory
Set up your SSL connector, pointing to your CA signed server
SSLCertificateFile and
André Warnier wrote:
Just to complete your report :
- is the JVM used in both cases exactly the same ?
- are either one of the Tomcats (or both) using the native APR library ?
(although I have no idea really if this is relevant or not when a
webapp makes its own connections)
Could the
Hi,
Weird issue, perhaps someone can explain how this might be happening
from a tomcat perspective...
I have some CXF generated web service client code that calls a web
service that operates on an IP whitelist. If I run this code from the
shell as the tomcat owner user apache_tomcat on the
Permgen memory leaks can cause those permgen OOM.
One common cause is webapps not cleaning up after themselves on context
shutdown. This leaks every loaded class from the webapp into the permgen
whenever the application is unloaded.
Knowing this one can workaround these leaks by being careful
Thanks Chris. Not as simple as I'd hoped, about as complicated as I expected
:-)
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, 12 May 2011 1:56 a.m.
To: Tomcat Users List
Subject: Re: How to close all connections in a Tomcat
Hi,
We just had an issue in production on tomcat 6, a web application was
getting strange errors from the oracle database:
java.sql.SQLException: ORA-06508: PL/SQL: could not find program unit
being called in Package
Our configuration uses a database pool in GlobalNamingResources of
server.xml
Thanks for that clarification.
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Tuesday, 14 December 2010 11:23 p.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart
On 13/12/2010 22:52, Dale Ogilvie wrote:
propsFileName is the name
Subject: Re: jndi-lookup fails, cured by tomcat restart
2010/12/14 Dale Ogilvie dale.ogil...@trimble.co.nz:
The thing is that the code is working fine now, without the fully
qualified jndi-name.
IIRC, Spring adds a prefix to the name before doing the lookup (as seen
from the logs fragment).
How
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave,
On 12/14/2010 4:56 PM, Dale Ogilvie wrote:
Redeployment that first caused the issue was using manager web-app. We
tried other deployment options after that.
OS is RHEL5.x
Aha, scanning the logs around the first error I found
December 2010 12:00 p.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart
On 14/12/2010 22:35, Dale Ogilvie wrote:
We'll investigate the leak issue, there /are/ leaks from Spring active
mq code.
Mind posting the leak warning from the logs?
p
-Original Message
Hi there,
Apologies if my previous email ended up linked to another thread. A JNDI
lookup started failing mysteriously, and rather than shrug shoulders I'd
prefer to nail down what went wrong, if possible.
We are using a spring jndi-lookup to pull the name of a context file
from the global
This is how we do it in a spring app, with a resourcelink in context.xml
conf/server.xml
GlobalNamingResources
Resource auth=Container
driverClassName=oracle.jdbc.OracleDriver
maxActive=10
maxIdle=5
maxWait=1
[mailto:ch...@christopherschultz.net]
Sent: Tuesday, 14 December 2010 9:46 a.m.
To: Tomcat Users List
Subject: Re: jndi-lookup fails, cured by tomcat restart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dale,
On 12/13/2010 3:08 PM, Dale Ogilvie wrote:
We are using a spring jndi-lookup to pull
From: Dale Ogilvie dale.ogil...@trimble.co.nz
To: Tomcat Users List users@tomcat.apache.org
Sent: Mon, December 13, 2010 2:52:09 PM
Subject: RE: jndi-lookup fails, cured by tomcat restart
propsFileName is the name of the bean, which should be initialized with
the string value from the JNDI entry
Hi there,
We are using a spring jndi-lookup to pull the name of a context file
from the global environment in our apps. We have set this up in tomcat
6.0.29 like so:
$CATALINA_HOME/conf/context.xml
Environment name=/propertiesFileName
value=classpath:test-application.properties
Perhaps the INFO message needs to sound less alarming? It sounds like it
is describing a quality bug to me, akin to running tomcat in
development mode if you are not using APR. If the missing library is
not really required for production use, how about:
INFO: The optional Apache Tomcat Native
Reasons to use httpd being what? We historically have used httpd and
mod_proxy_ajp, but less being more I'm considering a tomcat only setup.
The reason we used httpd in the past was httpd serves static content
better.
One other reason that comes to mind is httpd url rewrite support,
assuming
* We are serious about our tomcat install, and find configuration file
and jvm tweaks about all we need to do.
* Agreed that most distro's (apart from the rolling release ones such as
gentoo, arch) are lagging behind. This is the problem in my view.
* I would rather delegate the responsibility
My intent is purely to find the best solution for an up-to-date tomcat on linux.
If we have to pay for an up-to-date tomcat on linux we will. Indeed we would
prefer to roll up the cost for up-to-date tomcat in our current commercial
distro fees.
From responses it seems:
1. that there is no
Hi,
The current release is 6.0.26, March 2010.
RHEL5.x is running with Tomcat 5.5.
Fedora 12 is on 6.0.20, June 2009 vintage.
Ubuntu 10.04 is on 6.0.24 from Jan 2010.
Ideally, the equivalent of a yum update would track tomcat releases so
that soon after a tomcat release the tomcat6 package
Hassan Schroeder wrote:
I watch this list for announcements of new releases and install them
:-)
I'm hoping for something a bit more distro managed. Presumably your
method means you have to maintain your own init.d scripts and use the
tar xzvf method of installation, outside of your distro
Yes, the release gap is an issue for me as well. Hence this email trail
:-)
Parallelism is achieved for us for other software by package updating
the test/dev server and testing that prior to performing the same
updates on prod. There is no need for us to have two versions of tomcat
running on
50 matches
Mail list logo