Getting all JDBC configs from the context

[Shawn Heisey]

This is what the code in our application looks like that gets a
datasource object from the context:

  Context initContext = new InitialContext();
  Context envContext  = (Context)initContext.lookup("java:/comp/env");
  DataSource ds = (DataSource)envContext.lookup("jdbc/REDACTED");

I would like to write a logging thread that can get ALL of the
datasource objects from the context, and for types that it knows, cast
them to the appropriate object to log the active/idle connection counts.

This paste is the idea I've thought of for initializing and creating
this logging thread:

https://paste.apache.org/QcbE

The "log" variable is an slf4j Logger object.

Does that code look like it'll work, if we run it once at system
startup?  It doesn't have any errors in my IDE.  Which is not always an
indication of success!

Thanks,
Shawn


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

RE: Thread state differences according to Tomcat 7, 8 version.

[이의준]

Test sequence and inquiry contents
1. In the local test, the same load (hp-jmeter) for tomcat 7, 8 5 minutes,
2. Thread dump generated after 5 minutes of load termination
3. Thread in Tomcat 7 is in TIME_WAITING state (normally OK)
4. Thread in Tomcat 8 mostly RUNNABLE state (estimated to be abnormal)
 Thread Final Stack - Below (reading something)
 at org.apache.tomcat.jni.Socket.recvbb (Native Method)

5. Is the thread status of Tomcat 8 normal?
6. Does Tomcat 7 and Thread work differently?

Best regards

-Original Message-
From: 이의준  
Sent: Tuesday, March 27, 2018 10:47 PM
To: Rainer Jung ; Tomcat Users List 

Subject: Re: Thread state differences according to Tomcat 7, 8 version.

Thank you for answer.
​
As a further explanation, after a certain amount of time has elapsed after 
applying the same load to both groups, all threads in the tomcat7 group are in 
the TIME-WAITING state, and TOMCAT8 is in the RUNNABLE state.
So I guess there is a difference in THREAD behavior between Tomcat versions.
​
-Original Message-
From: "Rainer Jung"
To: "Tomcat Users List"; "이의준";
Cc:
Sent: 2018-03-27 (화) 22:16:20
Subject: Re: Thread state differences according to Tomcat 7, 8 version.
 
See below

Am 27.03.2018 um 07:50 schrieb 이의준:
> Hi !
>
> English is not my native language; please excuse typing errors.
>
> Why is Tomcat not handling requests with 8 versions, but in the 
> RUNNABLE state, not the TIME_WAITING state of the Tomcat 7 version?
>
> Please confirm that this operation works normally.
>
>  
>
> #Tomcat 7.0.75  jdk 1.7.0.65
>
>  
>
> #server.xml
>
>  
>
>   URIEncoding="UTF-8"
>
>acceptCount="200" acceptorThreadCount="2" maxThreads="300"
>
>minSpareThreads="50" connectionTimeout="15000"/>
>
>  
>
> #There are more than 40 threads with the following stacks:
>
>  
>
> "ajp-apr-7009-exec-111" #10247 daemon prio=5 os_prio=0
> tid=0x7fa6b811f000 nid=0x2f51 waiting on condition 
> [0x7fa6aa7b8000]
>
> java.lang.Thread.State: TIMED_WAITING (parking)
>
> at sun.misc.Unsafe.park(Native Method)
>
> - parking to wait for  <0x83769178> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.
> awaitN
> anos(AbstractQueuedSynchronizer.java:2078)
>
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java
> :467)
>
> at
> org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)
>
> at
> org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)
>
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.jav
> a:1066
> )
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:11
> 27)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:6
> 17)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
> ead.ja
> va:61)
>
> at java.lang.Thread.run(Thread.java:745)

These are thread idle in the thread pool.

> Tomcat 8.0.44 jdk 1.8.0.131
>
>  
>
> #server.xml
>
>  
>
>   URIEncoding="UTF-8"
>
>acceptCount="200" acceptorThreadCount="2" maxThreads="300"
>
>minSpareThreads="50" connectionTimeout="15000"/>
>
>  
>
> There are more than 50 threads with the following stacks:
>
>  
>
> "ajp-apr-7009-exec-1083" #19321 daemon prio=5 os_prio=0
> tid=0x7fcd1405d800 nid=0x19fe runnable [0x7fcc373f2000]
>
> java.lang.Thread.State: RUNNABLE
>
> at org.apache.tomcat.jni.Socket.recvbb(Native Method)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.readSocket(AjpAprProcessor.java:
> 256)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:197)
>
> at
> org.apache.coyote.ajp.AbstractAjpProcessor.readMessage(AbstractAjpProcessor.
> java:1091)
>
> at
> org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcesso
> r.java
> :804)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
> bstrac
> tProtocol.java:684)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(
> AprEnd
> point.java:2458)
>
> - locked <0xf6bce3a0> (a
> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:11
> 42)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:6
> 17)
>
> at
> 

Re: Trying to chase down "too many connection" problems with DB

[Shawn Heisey]

On 3/27/2018 11:03 AM, Phil Steitz wrote:
> Not exactly, if what you are using is the DBCP pool.  To see the

The factory in use right now is
"org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory".  Information
gathered previously in this thread told me that this is DBCP code,
repackaged into the tomcat package space to avoid conflicting with the
official commons-dbcp package.  If this is effectively unmodified DBCP,
then what you wrote below likely applies.

> details of what is going on, look at the removeAbandoned code in
> DBCP's AbandonedObjectPool.  It calls
> o.a.c.pool.GenericObjectPool#invalidateObject, which calls
> o.a.c.dbco.PoolableConnectionFactory#destroyObject to close the
> connection.  If an exception occurs, it is swallowed by
> removeAbandoned, but it dumps a stack trace.
>
> So connections should in fact be closed if they are detected as
> abandoned.  As I said on commons-user, in your setup, that won't
> happen unless borrows are attempted when there are 57+ open
> connections.  The removeAbandoned method is called *only* by
> borrowObject in DBCP 1.x, with this test:

It would not surprise me to learn that on the pool with maxActive=60,
the pool is managing less than 57 connections.  Until I can get some
logging in place on production to show me the acive and idle connection
counts, I do not know what's actually happening.

If I can successfully get a config using
"org.apache.tomcat.jdbc.pool.DataSourceFactory" operational (which seems
to be failing right now with "too many connections" on startup), is it
true that this pool does not require maxActive-3 connections before
abandoned removal kicks in?  The description for
abandonWhenPercentageFull in the tomcat documentation implies that this
is the case.

So now I have one person telling me that removeAbandoned DOES close
connections, and another saying that it does NOT close connections.  Is
there a conflict here, or are both of these statements correct for
different pool implementations?  Keep in mind that the current config
uses "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory" and that I
would like to try a new config with
"org.apache.tomcat.jdbc.pool.DataSourceFactory" ... unless there is a
good reason to NOT use that factory.  Which, by the way, is the factory
that tomcat's documentation SAYS to use.

The new config with the new factory fails to start on our staging
server, but aside from seeing "too many connection" exceptions in the
catalina log, I have no concrete information about what happened.  I
didn't do the restart, and wasn't watching the system when it happened. 
Switching back to the old config fixed the tomcat startup.  What the
developer described to me shouldn't have been possible.  I need to do
the restart myself and watch the system.

I've come up with another question, related to this, but headed in a
different direction.  I'll write a new email to the list for that.

Thanks,
Shawn


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

Re: Granting permission to a single application-supplied JAR

[George S.]

Chris,

One thing that has bitten me is that the entire stack/call chain is 
examined, not just permissions on a specific piece of code as you would 
expect. This comes into play when you're trying to make calls into 
trusted code from a JSP.


My experience has been that JSPs are not trusted. So, even if you grant 
some code permissions to a specific codebase, the JSP making the call is 
untrusted and things fail. I ran into this recently using the Apache 
LDAP library with a JSP. A bunch of reads would fail.


I see the tomcat security manager howto makes a reference to 
"pre-compiled jsp" but it's pretty vague (to my simple mind anyhow). I 
think the intention was to have pre-compiled JSPs live in a trusted 
codebase path. There's probably a way that you can mark all JSPs as 
trusted (I'm thinking a grant to $CATALINA_BASE/work/Catalina), but that 
kind of defeats the point. If you mark standard JSPs as trusted, then 
anyone that can get a file in the context path can bypass your security 
model.


What I ended up doing on the last project was putting all of the code 
that made the calls into the Apache LDAP directory into a specific jar, 
and signing that jar with a certificate. Then I have a grant that trusts 
anything signed with that certificate.


The security manager can be maddening to work with. Just as a tip for my 
specific usage, I have a skeleton policy file and the tomcat startup 
script merges my policy file into Tomcat's policy file. I just found 
there's another way of doing that, but it doesn't look any better since 
it requires modifying a file in $JDK/JRE_HOME.



On 3/22/2018 3:39 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm working on getting my application working under a SecurityManager.
It's actually been a little less painful than I thought it would be.

I'm using Solr for some index searching. I'm using SolrJ for the
library to communicate via HTTP to a localhost Solr server. When using
this grant:

grant {
   permission "java.util.PropertyPermission"
"solr.httpclient.builder.factory", "read";
   permission "java.net.SocketPermission", "localhost:8983",
"resolve,connect";
}

My application can can contact Solr without any errors.

If I change the "grant" to include a codeBase to restrict those
connections to the Solr library, I get a AccessControlException:
access denied to the system property. Here is the modified grant:


grant codeBase
"file:${catalina.base}${file.separator}webapps${file.separator}myapp${fi
le.separator}WEB-INF${file.separator}lib${file.separator}solr-solrj-7.2.
1.jar"
{
   permission "java.util.PropertyPermission"
"solr.httpclient.builder.factory", "read";
   permission "java.net.SocketPermission" "localhost:8983",
"resolve,connect";
};

I have verified that the file exists under the path specified above. I
tried both ${file.separator} and '/' as the file separator. I also
tried "jar:/path/to/jar!/-" as the codeBase. No luck.

These grants are added to the end of the stock catalina.policy file
that ships with Tomcat.

What am I missing, here?

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq0IpkdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFj/og//dsN0nnYfal37ceL5
pEtIUtOGq87vwHRRMvTuWwxGmm5DqqfC+ZC07IWnJJt5Ap9ir8mYRiYluoCvx0yx
LdmUVEesygbhOmyLm6EX3deJ7ozaO5MkFcDx0084y/dHfx+L3mg2n/ysG/qnqoxS
69RvbQNh7ByRsDOnhlSXLc0ZSSB6L9GtE9UpgGdCdyvyBXKS5X3/XOvygJ13lHZH
lZH1/iXEUzatZtR7wSySfVdEXSx2JjSagClPmYVi4Lj4Fi9qugbwnpakT8Sr3mJx
A/lK/KLPA3NqH/T91fzZBzlmLXqZ6L5GFz2P9iOaQ+1QfcCiMktFxJ2tXzqYDQm1
g0OtE/k2Jf3+QZtpUDJ+cDzLjWdUXs/6oa0Uo37ZXTRU1wowPeX+PHsKr9aqQB+T
rx7OXTL/ZLh+bQobaQV4oyiF+mSRLZfrtI7cHoF8ZiwwsXpo4y+4CQqxzsWR6w4A
9wYV/lKecONJnwNey6JujapbcFcWmCZps5crvUyi/YNx/Rl/szdI2vWOevCJwnvQ
LgyvbNF8AglERID8bL0fT9RL9Ws5/taII3egavGBMUGi+VYu/qjY2c9unP3W7UR6
42NNGkDxQlum8M3uu3FpDMmsfcRcYzQSZ1yCEharMLzKR6zn0c4odnJpUWmVzLnO
brtsSvTBTsIlH3F7dlocMV63W+U=
=xlk2
-END PGP SIGNATURE-

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



--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: HOME user folder change & tomcat HOME

[George S.]

Did you edit /etc/passwd and change the home directory for your user xnat?


On 3/27/2018 9:27 AM, Jérôme Redouté wrote:

Hello,

I've installed tomcat8 on Debian 9, to run a web App (XNAT)

I've a proble concerning the HOME directory of my user "xnat".

Before the HOME was, as expected, in /home/xnat

but now (after deploying XNAT app), it moved to /var/lib/tomcat8

and I can't reverse back the the original HOME.

I suspect it is related to misconfiguration of tomcat, but I can't 
find wher.


Can you help me?

few infos concerning my tomcat install:


Using CATALINA_BASE:   /usr/share/tomcat8
Using CATALINA_HOME:   /usr/share/tomcat8
Using CATALINA_TMPDIR: /usr/share/tomcat8/temp
Using JRE_HOME:    /usr
Using CLASSPATH: 
/usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar

Server version: Apache Tomcat/8.5.14 (Debian)
Server built:   Sep 3 2017 17:51:58 UTC
Server number:  8.5.14.0
OS Name:    Linux
OS Version: 4.9.0-6-amd64
Architecture:   amd64
JVM Version:    1.8.0_162-8u162-b12-1~deb9u1-b12
JVM Vendor: Oracle Corporation




Thanks



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



--
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: database pool and minIdle support in 8

[Pawel Veselov]

Apologies for reviving a zombie.

On Sat, Feb 3, 2018 at 8:43 AM, Pawel Veselov  wrote:
 What is the problem with failures during pool initialization?
>>> ConnectionPool.init() attempts to borrow initialSize worth of
>>> connections. Imagine your database server is having problems at
>>> this time. This will make init() fail, and the pool creation fail,
>>> and your webapp is dead in the water after that
>> Is it? Does init() in fact fail? Which pol are you talking about?
> org.apache.tomcat.jdbc.pool.ConnectionPool. And actually, it doesn't.
> I'm sure it did at some point before, that's why I set initialSize to
> 0 (it's an old application), but I tested it on 8.0.49 and in 8.0.9
> just now, and the pool does come up and binds. So this is a non-issue.

I thought I tested this, by shutting down the DB and restarting the
application. But now I see that initialization does fail if a
connection can not be created during pool creation. Running this on
8.0.39. Full exception is pasted into https://pastebin.com/SShyhdix
The initialization errors can be controlled by
isIgnoreExceptionOnPreLoad JMX property. I'll have to see how to set
that before creating the pool.

Thank you.

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

How to offer a link correction for the Tomcat docs?

[charlie arehart]

Greetings. I’m a new list member, though a fairly long-time Tomcat user. 

I found a broken link in the Tomcat User Guide (8 and 7), on its left nav bar.  
How would I best go about reporting such a broken link in the Tomcat docs?

To be clear, while there is a comments section at the bottom of the doc pages, 
that points folks to https://tomcat.apache.org/tomcat-8.0-doc/comments.html to 
learn more, which in turn points to https://comments.apache.org/help.html. But 
that gets a 503 service unavailable error. I find a jira discussion indicating 
this is a long-standing issue, which was hoped to be solved by now: 
https://issues.apache.org/jira/browse/INFRA-15947.



Until that’s resolved, is this or another TC list a good place to report such a 
broken link, or other doc suggestion? Thanks.

/charlie

Re: Tomcat 8.0.38 to 9.0.6 -- Default Class Loader and Naming InitialContext

[Behrooz Nobakht]

Managed to narrow down to a regression:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

On Tue, Mar 27, 2018 at 2:09 PM, Behrooz Nobakht  wrote:

> Hi Chris,
>
> Thanks for the reply. Comments inline:
>
> On Tue, Mar 27, 2018 at 4:31 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Behrooz,
>>
>> On 3/26/18 12:26 AM, Behrooz Nobakht wrote:
>> > Hi,
>> >
>> > I am migrating a code base from Tomcat 8.0.38 to 9.0.6. There are a
>> > few things I'd like to confirm based on observations so far and ask
>> > for advice:
>> >
>> > 1. Default Class Loader
>> >
>> > In 9, it seems that the default is ParallelWebAppClassLoader
>> > compared with WebAppClassLoader in 8.0. What behavior changes does
>> > the new class loader bring esp. now that it seems to use
>> > "concurrent" approach?
>> >
>> > One specific observation so far is that the code
>> >
>> > Thread.currentThread().getContextClassLoader()
>> >
>> > used to give out "a" class loader in 8.0 but it returns null in
>> > 9.0. Any advice on this?
>>
>> What code is fetching the TCCL? Something like a ServletContextListener?
>>
>
> This is a business object trying to resolve a resource using
> ClassLoader#gerResource
> and class loader is retrieved via above way. The call stack comes from a
> REST request
> and it's not part of container/context life cycle.
>
>
>>
>> > 2. ClassNotFoundException:
>> > org.apache.naming.java.javaURLContextFactory
>> >
>> > Having the code:
>> >
>> > InitialContext ic = new InitialContext()
>>
>> What data type is InitialContext in your code, here? Can you post the
>> complete stack trace?
>>
>
> InitialContext is javax.naming.InitialContext.
> As I traced this, by default this is enabled by Tomcat itself at
> Catalina.java
> 
> .
> We might be having implicit class loader conflicts which I am tracing now.
> I event tried to install a custom Loader
>  inside the
> Context with WebappClassLoader
> to see anything changes in comparison with ParallelWebappClassLoader.
> Tomcat 8 works but Tomcat 9 fails with ClassNotFoundException:
>
> javax.naming.NoInitialContextException: Cannot instantiate class:
> org.apache.naming.java.javaURLContextFactory [Root exception is 
> java.lang.ClassNotFoundException:
> org.apache.naming.java.javaURLContextFactory]
> at javax.naming.spi.NamingManager.getInitialContext(
> NamingManager.java:674)
> at javax.naming.InitialContext.getDefaultInitCtx(
> InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.(InitialContext.java:192)
>
> And, we're not explicitly bundling tomcat-catalina.jar with the webapp.
>
> Thanks,
> Behrooz
>
>
>
>>
>> > used to work on Tomcat 8.0 but now yields the above exception in
>> > Tomcat 9. It seems that catalina.jar is not exposed by default to a
>> > webapp class loader.
>>
>> Nor should it. It should not have been available to applications in
>> Tomcat 8, either. Are you bundling catalina.jar with your application?
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq5LncdHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhSiBAArOCcZ0okwbEp1ag+
>> gCJw3jXcndN3JfmcEoIjNddR8/P2BvGSpZrvNX3b/hECrmlMV7hUl0SpORl7afL5
>> zrP1liEdRlZ50EmpQJULG+yjktc298Ip6eXWQLa6oX9OOLbkZyknlGeI249j6syo
>> FXomtb6ZQ4F0WP9wC14N/keAHL2nqTOk7+1p1khfIYPVUM1MfT9EtVnW3weL9kHd
>> sn1FZIV3TNkOiukQm9znIeed00YlH0kaS2V9l/GNOvkhwH66xROxiJukm3dUzTQe
>> djsigv/mHrEWZDG9rhteJbt9RB6XMsaQogfXh8JlZsfxt2i7Yy12O2LOOHFIMaTl
>> 4fjKxiuQl0iOi52rfvrp+CTO/0y0TklPh3gYcNa2dpZm/UGkLrRty199Qs9+KIgy
>> d0L5zT9pwFusTwKt/wiVyGcm+Jg2Lq13fD8WNMmElk1h78ceVbM3NFDxZqqaSHK2
>> p3S3xrMsTeFfyFI2BRdUXlV/+HGwwLYnmHWPVSEUhV448WXdOd0kehYSJGLmfXBM
>> UrYiZksVTYjsJc5zCADtp4xNm/At9T/Ktcfp67Rm97bR8ityQBuf9xKpJ7eo5Gzj
>> Ecl4kFz2W4sRxli0H5zX8lcoO7A9AAk7P0bR1ooMZ/8d6nx1WrIx19zNXz1ou8me
>> qI6/uYGGZX23quqgKXKP9g2basE=
>> =DOWh
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
> --
> -- Behrooz Nobakht
>



-- 
-- Behrooz Nobakht

Re: Trying to chase down "too many connection" problems with DB

[Phil Steitz]

On 3/26/18 10:28 AM, Christopher Schultz wrote:
> Shawn,
>
> On 3/25/18 12:17 AM, Shawn Heisey wrote:
> > On 3/24/2018 5:04 PM, Mark Thomas wrote:
> >> Regarding your configuration:  >> auth="Container"
> >> factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
> >> driverClassName="com.mysql.jdbc.Driver"
> >> type="javax.sql.DataSource" maxActive="60" maxIdle="10"
> >> maxWait="3" removeAbandoned="true"
> >> removeAbandonedTimeout="30" username="REDACTED"
> >> password="REDACTED" testOnBorrow="true" validationQuery="select
> >> 1"
> >>
> url="jdbc:mysql://REDACTED.REDACTED.com:3306/REDACTED?autoReconnect=t
> ruezeroDateTimeBehavior=round"
> >>
> >>
> >>
> />
> >>
> >> Generally, that looks OK but I'd strongly recommend that you use
> >> "autoReconnect=false" in the URL. autoReconnect is known to be
> >> problematic with connection pools.
> >>
> >> The removeAbandonedTimeout looks low but if all the queries are
> >> expected to be well under 30s then that should be OK.
>
> > Somehow I did not see this part of your email at all when I read it
> > the first time.  I just noticed it.  My previous reply probably has
> > you scratching your head a little bit.  I'm sorry about that!
>
> > The timeout of 30 seconds is EXTREMELY low.  And if it were being
> > honored, we would have customers lining up outside the office with
> > pitchforks.  The webapp has reporting ability for users with
> > elevated privileges, and a lot of those reports take a minute or
> > two to run, sometimes even longer.  So if the pool were killing
> > connections after 30 seconds, the reporting mechanism would be
> > failing a LOT.  If you check the *planned* configuration, you'll
> > see that I have increased this timeout to 3600.  I wanted to make
> > it 900, but some of the developers are worried that 900 is too
> > aggressive.
>
> The pool doesn't kill abandoned connections. It simply removes them
> from the pool. Otherwise, you're right: you'd have torches and
> pitchforks everywhere.

Not exactly, if what you are using is the DBCP pool.  To see the
details of what is going on, look at the removeAbandoned code in
DBCP's AbandonedObjectPool.  It calls
o.a.c.pool.GenericObjectPool#invalidateObject, which calls
o.a.c.dbco.PoolableConnectionFactory#destroyObject to close the
connection.  If an exception occurs, it is swallowed by
removeAbandoned, but it dumps a stack trace.

So connections should in fact be closed if they are detected as
abandoned.  As I said on commons-user, in your setup, that won't
happen unless borrows are attempted when there are 57+ open
connections.  The removeAbandoned method is called *only* by
borrowObject in DBCP 1.x, with this test:

if (config != null
    && config.getRemoveAbandoned()
    && (getNumIdle() < 2)
    && (getNumActive() > getMaxActive() - 3) ) {
    removeAbandoned();
 }

Another thing you should do is to set logAbandoned to true so you
get a stack trace if / when abandoned connections are detected and
close.

Phil


>
> Sounds like you need to raise that timeout by a LOT.
>
> Also, set logAbandoned="true" and you'll get a helpful message every
> time a connection is considered abandoned and you'll find out if you
> have a connection leak (as opposed to simply a too-short "abandoned"
> setting).
>
> > Because there are no pitchforks, I know that abandoned connection
> > removal is NOT happening, even though it IS configured.
>
> It's probably happening, just not meeting your expectations. Those
> abandoned connections will pretty much live forever, no longer being
> managed by the pool and yet still counting as being used by the
> server. Maybe lower your idle-timeout on the server to help with this.
>
> Hope that helps,
> -chris
> >
-
> 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: HOME user folder change & tomcat HOME

[Coty Sutherland]

Hi,

This sounds like a problem specific to the distribution's tomcat
package, which is usually better served by the distribution's
community rather than Tomcat's (they repackage what we provide). You
may want to ask on their users list/support forum/etc, but I will try
and help though :)

On Tue, Mar 27, 2018 at 11:27 AM, Jérôme Redouté  wrote:
> Hello,
>
> I've installed tomcat8 on Debian 9, to run a web App (XNAT)
>
> I've a proble concerning the HOME directory of my user "xnat".
>
> Before the HOME was, as expected, in /home/xnat

Before what? Before you installed the Debain tomcat package? Or did
you install the xnat package? Something else?

> but now (after deploying XNAT app), it moved to /var/lib/tomcat8

When you say deploy, do you mean install xnat's package? Or copy a war
into place? I ask because /var/lib/tomcat8 isn't CATALINA_BASE or
CATALINA_HOME (which were my first thoughts), so it seems to have some
configuration elsewhere.

>
> and I can't reverse back the the original HOME.
>
> I suspect it is related to misconfiguration of tomcat, but I can't find
> wher.

That output looks pretty standard for a distro's tomcat package
(follows FHS with /usr/share/tomcat8, etc).

>
> Can you help me?
>
> few infos concerning my tomcat install:
>
>> Using CATALINA_BASE:   /usr/share/tomcat8
>> Using CATALINA_HOME:   /usr/share/tomcat8
>> Using CATALINA_TMPDIR: /usr/share/tomcat8/temp
>> Using JRE_HOME:/usr
>> Using CLASSPATH:
>> /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar
>> Server version: Apache Tomcat/8.5.14 (Debian)
>> Server built:   Sep 3 2017 17:51:58 UTC
>> Server number:  8.5.14.0
>> OS Name:Linux
>> OS Version: 4.9.0-6-amd64
>> Architecture:   amd64
>> JVM Version:1.8.0_162-8u162-b12-1~deb9u1-b12
>> JVM Vendor: Oracle Corporation
>
>
>
>
> Thanks
>
>
>
> -
> 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

HOME user folder change & tomcat HOME

[Jérôme Redouté]

Hello,

I've installed tomcat8 on Debian 9, to run a web App (XNAT)

I've a proble concerning the HOME directory of my user "xnat".

Before the HOME was, as expected, in /home/xnat

but now (after deploying XNAT app), it moved to /var/lib/tomcat8

and I can't reverse back the the original HOME.

I suspect it is related to misconfiguration of tomcat, but I can't find 
wher.


Can you help me?

few infos concerning my tomcat install:


Using CATALINA_BASE:   /usr/share/tomcat8
Using CATALINA_HOME:   /usr/share/tomcat8
Using CATALINA_TMPDIR: /usr/share/tomcat8/temp
Using JRE_HOME:    /usr
Using CLASSPATH: 
/usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar

Server version: Apache Tomcat/8.5.14 (Debian)
Server built:   Sep 3 2017 17:51:58 UTC
Server number:  8.5.14.0
OS Name:    Linux
OS Version: 4.9.0-6-amd64
Architecture:   amd64
JVM Version:    1.8.0_162-8u162-b12-1~deb9u1-b12
JVM Vendor: Oracle Corporation




Thanks



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

tomcat Realm formatting

[Frank, Jon]

Hi I need to encrypt the password for tomcat console access..

I've encrypted it using the digest.sh script, and I've added it to the 
tomcat-users.xml file. See below...I've X'd out the actual password.

I also need to edit the Realm tag in the server.xml file but there is already a 
Realm for Lockout and DataSource  in it.

My question is how do I add the UserDatabase Realmis it correct how I have 
it below?

I added the Combined Realm along with the UserDatabase Realm I can't test this 
out since we only have a production environment.



##

Tomcat-users.xml

  

  

  

  

  





Server.xml

 

 

 



 

 

  


cheers,
jon frank
middleware infrastructure
w: 651-662-8216h: 952-226-3059c: 612-715-6522route: m125cube: 
m1-g9-03



This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

Re: Thread state differences according to Tomcat 7, 8 version.

[이의준]

Thank you for answer.
​
As a further explanation, after a certain amount of time has elapsed after 
applying the same load to both groups, all threads in the tomcat7 group are in 
the TIME-WAITING state, and TOMCAT8 is in the RUNNABLE state.
So I guess there is a difference in THREAD behavior between Tomcat versions.
​
-Original Message-
From: "Rainer Jung"
To: "Tomcat Users List"; "이의준";
Cc:
Sent: 2018-03-27 (화) 22:16:20
Subject: Re: Thread state differences according to Tomcat 7, 8 version.
 
See below

Am 27.03.2018 um 07:50 schrieb 이의준:
> Hi !
>
> English is not my native language; please excuse typing errors.
>
> Why is Tomcat not handling requests with 8 versions, but in the RUNNABLE
> state, not the TIME_WAITING state of the Tomcat 7 version?
>
> Please confirm that this operation works normally.
>
>  
>
> #Tomcat 7.0.75  jdk 1.7.0.65
>
>  
>
> #server.xml
>
>  
>
>   URIEncoding="UTF-8"
>
>acceptCount="200" acceptorThreadCount="2" maxThreads="300"
>
>minSpareThreads="50" connectionTimeout="15000"/>
>
>  
>
> #There are more than 40 threads with the following stacks:
>
>  
>
> "ajp-apr-7009-exec-111" #10247 daemon prio=5 os_prio=0
> tid=0x7fa6b811f000 nid=0x2f51 waiting on condition [0x7fa6aa7b8000]
>
> java.lang.Thread.State: TIMED_WAITING (parking)
>
> at sun.misc.Unsafe.park(Native Method)
>
> - parking to wait for  <0x83769178> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitN
> anos(AbstractQueuedSynchronizer.java:2078)
>
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
>
> at
> org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)
>
> at
> org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)
>
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066
> )
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
> 27)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
> 17)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
> va:61)
>
> at java.lang.Thread.run(Thread.java:745)

These are thread idle in the thread pool.

> Tomcat 8.0.44 jdk 1.8.0.131
>
>  
>
> #server.xml
>
>  
>
>   URIEncoding="UTF-8"
>
>acceptCount="200" acceptorThreadCount="2" maxThreads="300"
>
>minSpareThreads="50" connectionTimeout="15000"/>
>
>  
>
> There are more than 50 threads with the following stacks:
>
>  
>
> "ajp-apr-7009-exec-1083" #19321 daemon prio=5 os_prio=0
> tid=0x7fcd1405d800 nid=0x19fe runnable [0x7fcc373f2000]
>
> java.lang.Thread.State: RUNNABLE
>
> at org.apache.tomcat.jni.Socket.recvbb(Native Method)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.readSocket(AjpAprProcessor.java:256)
>
> at
> org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:197)
>
> at
> org.apache.coyote.ajp.AbstractAjpProcessor.readMessage(AbstractAjpProcessor.
> java:1091)
>
> at
> org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java
> :804)
>
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac
> tProtocol.java:684)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEnd
> point.java:2458)
>
> - locked <0xf6bce3a0> (a
> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
> 42)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
> 17)
>
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
> va:61)
>
> at java.lang.Thread.run(Thread.java:748)


These are threads which are busy from the point of view of the thread
pool, but what they are doing is waiting for more data to arrive on a
connection they handle.

So the two groups of threads you have chosen are really in a different
state, not only Tomcat or Java version wise.

Regards,

Rainer

Re: Thread state differences according to Tomcat 7, 8 version.

[Rainer Jung]

See below

Am 27.03.2018 um 07:50 schrieb 이의준:

Hi !

English is not my native language; please excuse typing errors.

Why is Tomcat not handling requests with 8 versions, but in the RUNNABLE
state, not the TIME_WAITING state of the Tomcat 7 version?

Please confirm that this operation works normally.

  


#Tomcat 7.0.75  jdk 1.7.0.65

  


#server.xml

 

 

  


#There are more than 40 threads with the following stacks:

  


"ajp-apr-7009-exec-111" #10247 daemon prio=5 os_prio=0
tid=0x7fa6b811f000 nid=0x2f51 waiting on condition [0x7fa6aa7b8000]

java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for  <0x83769178> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitN
anos(AbstractQueuedSynchronizer.java:2078)

at
java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)

at
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)

at
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)

at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066
)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
27)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
va:61)

at java.lang.Thread.run(Thread.java:745)


These are thread idle in the thread pool.


Tomcat 8.0.44 jdk 1.8.0.131

  


#server.xml

 

 

  


There are more than 50 threads with the following stacks:

  


"ajp-apr-7009-exec-1083" #19321 daemon prio=5 os_prio=0
tid=0x7fcd1405d800 nid=0x19fe runnable [0x7fcc373f2000]

java.lang.Thread.State: RUNNABLE

at org.apache.tomcat.jni.Socket.recvbb(Native Method)

at
org.apache.coyote.ajp.AjpAprProcessor.readSocket(AjpAprProcessor.java:256)

at
org.apache.coyote.ajp.AjpAprProcessor.read(AjpAprProcessor.java:197)

at
org.apache.coyote.ajp.AbstractAjpProcessor.readMessage(AbstractAjpProcessor.
java:1091)

at
org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.java
:804)

at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac
tProtocol.java:684)

at
org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEnd
point.java:2458)

- locked <0xf6bce3a0> (a
org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper)

at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:11
42)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
17)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.ja
va:61)

at java.lang.Thread.run(Thread.java:748)



These are threads which are busy from the point of view of the thread 
pool, but what they are doing is waiting for more data to arrive on a 
connection they handle.


So the two groups of threads you have chosen are really in a different 
state, not only Tomcat or Java version wise.


Regards,

Rainer

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

Re: Trying to chase down "too many connection" problems with DB

[tomcat]

On 26.03.2018 23:36, Shawn Heisey wrote:

On 3/26/2018 2:39 PM, André Warnier (tomcat) wrote:

Just a question, more to satisfy my curiosity : when you have these
hundreds of "pending" connections, in what state are they, TCP/IP-wise ?


Not sure where you got "pending".  I don't recall mentioning anything
like that.

The TCP state is ESTABLISHED.  Entries in the TCP table on port 3306
with the ESTABLISHED state is how we have Xymon keeping track of the
connection count.

Slightly redacted screenshot:

https://www.dropbox.com/s/4yj8y2hzfrnr2aj/xymon-port-monitoring-mysql.png?dl=0

It's not a low-level networking issue.



Sorry for my use of the vague "pending". I meant "unused", "just sitting there".

I wasn't thinking of a low-level networking issue, but more like a case like the 
following. I am not a java expert, so I'll do this in text :


Some code creates a new object, which implicitly opens a connection to a 
back-end server.
Then this code returns, and the created object is now out of scope (including its 
underlying connection). The unreachable object at some point will be destroyed, giving the 
programmer a warm feeling that all is well.
But with java this does not necessarily happen right away : it will happen when there is a 
garbage collection. And only at that point will the underlying connection be closed and 
disappear.
So if you have a very comfortable Heap, it may take a very long time for these "abandoned" 
connections to be closed, as part of the destruction of the objects which contain them.
And in the meantime they accumulate (without being used, because they can only be used via 
the object, and the object is now unreachable).
The non-intutive part is that, the bigger the available Heap, the more such connections 
accumulate, because the interval between GCs is longer.


In my case, it was a bit more tricky still, in the sense that the connection was closed on 
one side and not on the other, so these connections appeared in the "CLOSE_WAIT" state. 
But under Linux, when reaching several hundreds such CLOSE_WAIT connections, the TCP/IP 
stack for some reason stops being responsive, leading to system paralysis.

(So we had the problem on the front-end client, not on the back-end server).

A forced java garbage collection cleared things up (which gave us a hint about what was 
happening), but it nevertheless took us a while to diagnose this properly (we also did not 
have the source code of the application doing this, so we had to guess).


The above is probably not your case exactly, but it may give you some hint as to how to 
find the underlying issue quicker.



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