Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 16 Mar 2013 20:14:26 -0000 Issue 11300

users-digest-help

2013-03-16


Author LoginPost Reply

users Digest 16 Mar 2013 20:14:26 -0000 Issue 11300

Topics (messages 240453 through 240474)

Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
 240453 by: Christopher Schultz

Re: AW:AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
 240454 by: Christopher Schultz

Re: Embedded Tomcat JavaDoc Not Complete
 240455 by: Nick Williams
 240458 by: Christopher Schultz
 240463 by: Nick Williams

SSL Best Practices
 240456 by: Jeffrey D. Fisher
 240461 by: Christopher Schultz

Unix domain socket leak using NIO connector
 240457 by: Lucian I
 240462 by: Christopher Schultz
 240467 by: Lucian I

Re: tomcat 6.0.35 in production maintaince
 240459 by: Christopher Schultz
 240460 by: Christopher Schultz

ThreadLocal variables and BIO/NIO/APR
 240464 by: Nick Williams
 240465 by: Konstantin Kolinko
 240466 by: Mark Thomas
 240468 by: Nick Williams

Re: Deadlock when using jetty 8 JDBCSessionManager and Tomcat 7 JDBC Connector
 240469 by: Colin Ingarfield

Register static JNDI env entry dynamically
 240470 by: Michael-O
 240471 by: Konstantin Kolinko
 240472 by: Michael-O
 240473 by: Konstantin Kolinko
 240474 by: Michael-O

Administrivia:

---------------------------------------------------------------------
To post to the list, e-mail: users@(protected)
To unsubscribe, e-mail: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-digest-help@(protected)

----------------------------------------------------------------------


Attachment: users_240453.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

DAvid,

On 3/13/13 3:01 PM, David Kumar wrote:
> Hey,
>
> right no we're having our Problem. I tried gc through jconsole -->
> no changes and still a lot CLOSE_WAIT. So it is not a GC Problem
> and disablereuse doesn't work either.. Any other ideas?
>
> What do you guy think about proxy_ajp instead of jk? What are the
> advantages of proxy_ajp?

mod_proxy_ajp uses the identical protocol to mod_jk: they both use
AJP, and the code on the Tomcat side is identical. So, if you think
this is a Java problem, switching from mod_jk -> mod_proxy_ajp is
unlikely to change anything at all.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDemcACgkQ9CaO5/Lv0PAt0ACZAZg5UqqAeyEhpuOcssa02p4d
DjYAn0IwtT+RJ6pdw+jMX0cy6A8gDhai
=A38V
-----END PGP SIGNATURE-----


Attachment: users_240454.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 3/14/13 11:02 AM, André Warnier wrote:
> But this is the request/response connection, so I doubt that there
> would be a bug there, otherwise we'd have problems reports filling
> this list every day.
>
> Might there be that there is somewhere a discrepancy between the
> keep-alive settings, between Apache and Tomcat ?

I'd take a look at the connection timeout settings between mod_jk and
Tomcat: if they are mismatched, you might get some weirdness where
connections are going stale on the Apache side and not the Tomcat side
(or vice-versa). It's easy to do since one side expresses timeouts in
ms and the other side in seconds. :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDfBsACgkQ9CaO5/Lv0PD+ggCguhh5KOW+hoxxhwRFIY0AsH8N
/30AoJ2sfyMb+xSqewoI0iOSBJRXq0hg
=Up57
-----END PGP SIGNATURE-----


Attachment: users_240455.eml (zipped)

On Mar 15, 2013, at 2:15 PM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Nick,
>
> On 3/13/13 2:19 PM, Nicholas Williams wrote:
>> On Wed, Mar 13, 2013 at 12:10 PM, Christopher Schultz
>> <chris@(protected):
>>> You mean addWebapp methods? They seem fairly self-explanatory.
>>
>> Yes. I meant addWebapp methods. That was a typo.
>>
>> There are three of them. Only one is documented. Unfortunately,
>> the other two are not "self explanatory." I have no idea what the
>> "url," "path," and "name" parameters are (although "host" makes
>> sense). The documentation for the lone method that IS documented
>> only has "contextPath" and "baseDir" ... that doesn't line up with
>> the other two methods.
>
> Yup, it's ugly.
>
>>> Tomcat.addWebapp(String,String) says that the first argument is
>>> the context path. The context path for the ROOT webapp is "", not
>>> "/".
>>
>> I didn't know this. I will change it. By the way, I got this code
>> from the tutorial at
>> https://devcenter.heroku.com/articles/create-a-java-web-application-using-embedded-tomcat.
>
> They
>>
> should probably update their HOWTO: "/" isn't a valid context
> path, though it might actually work since "//" ~= "/" in the URL world.

Yep.

>
>>> The second argument is a "baseDir" which says (via
>>> Context.setDocBase) it can be an absolute pathname, a relative
>>> pathname (to the cwd I suppose, or maybe relative to the hosts's
>>> appbase), or a URL.
>>
>> Well there's part of the problem with the documentation. The
>> documentation for the method says "Add a webapp using normal
>> WEB-INF/web.xml if found." and the documentation for the "baseDir"
>> parameter says nothing. There's no information here that would
>> have led me to look at the Context#setDocBase() method. Nada. I
>> will try out making it a URL.
>
> I was reading the code, not the Javadoc: it makes it a lot easier.
> Since the "baseDir" gets passed into Context.setDocBase, I read the
> javadoc for that method to get the real story.

That's how I ended up getting it running: I starting reading code instead of documentation.

>
>>> You are passing a relative path name which probably won't
>>> resolve to a resource "inside" the JAR file you are using. Try
>>> fetching a resource URL for the "web/" path from the ClassLoader
>>> and pass that instead of just "web/".
>>
>> I will give this a try.
>>
>>> You didn't say what actually happens: just stated your
>>> requirements and showed your code. Does Tomcat fail to start?
>>> Does it fail to listen on your port? Does it fail to respond to
>>> requests?
>>
>> My bad. I'm always seeing y'all tell people to explain the
>> problem, and here I go not explaining the problem just like all the
>> rest of them. :-P ... When I ran the application using the batch
>> file generated by the mojo plugin, almost everything was good
>> (Tomcat started up, started listening on the right port, found all
>> the classes it was supposed to find, etc.). However, I got a
>> "severe" error that the web application directory
>> (webAppDirLocation) did not exist and the application could not be
>> deployed. Understandable, since I didn't know what to use for
>> this.
>
> The likely problem is that your appBase was just "web" and Tomcat was
> trying to load that from the disk (directly) instead of looking inside
> your JAR file. Using a JAR-URL (which the ClassLoader should give you)
> should work. The URL should look something like /path/to/your.jar!/web
> or something like that.

I tried using a JAR URL. (If I remember correctly, it ended up looking something like jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.) I tried it as both a directory and a WAR file. Tomcat did not like it. It said "Could not deploy web application to [temporary webapps directory location]" or something like that. I ended up, at runtime, extracting the war file from the JAR file to a temporary directory and deploying from there. That worked great, and it's how the Tomcat Maven plugin executable war works, too.

>
>>>> tomcat.start();
>>>
>>> You should probably call tomcat.init() first, though some of the
>>> Tomcat test cases don't do it so you're probably okay.
>>
>> Yea, the tutorial I was using didn't say anything about that.
>> Interesting that "init" and "start" are separate. If "init" was
>> required and "start" didn't call "init" I would think that "start"
>> would throw an IllegalStateException. Since it doesn't, my guess
>> is that calling "start" is sufficient, though I will certainly add
>> "init." I would love to now the semantic difference between "init"
>> and "start." The documentation just says "Initialize the server"
>> and "Start the server."
>
> Take a look at the Javadoc for LifecycleListener, one of the
> interfaces that the Tomcat class implements. The Javadoc for any
> implemented yet not documented method from that interface gets
> inherited in the javadoc for the implementation class, but the
> interface-level documentation is, of course, ignored. Go look at the
> javadoc for that interface and you'll see some nice ASCII art that
> describes the full lifecycle.

Yep. Found that. Last time I saw ASCII art was the late 1990s or something. ;-)

>
>>>> tomcat.getServer().await(); } }
>>>
>>> I don't think you configured any logging. You might want to set
>>> up something to at least dump to the console, and crank-up the
>>> log level to DEBUG or something like that. Then you might be able
>>> to see what Tomcat is actually doing.
>>
>> It does seem to automatically dump to the console automatically. I
>> got plenty of messages, most of them good (listening on 8973,
>> etc.). I will look into logging more, of course. This was just a
>> first pass at proof-of-concept.
>
> Cool. Obviously, you're going to want to log to a log file eventually.
> If you configure commons-logging at the top-level (that is, your own
> code), I think everything will flow through that.

Yep. I used the standard logging.properties that ships with Tomcat and got Tomcat logging to a temporary directory I set up. Works great now.

>
>> Since sending this email, I've discovered the "Executable WAR" [2]
>> capability of the Tomcat Maven plugin. I'm kind of confused about
>> the difference between Embedded Tomcat and Executable WAR. Which
>> one do I need? Will they both do what I need, but one might be
>> better than the other based on more exact requirements?
>
> I dunno anything about the Tomcat Maven plugin, but I think that an
> executable WAR file is exactly what you are trying to build.

It is. There are some issues (not bugs) with the Tomcat Maven plugin executable war, the first one being that it's not very easy to customize without using command-line arguments (makes it kind of hard to "double-click" and run the executable war effectively). Also, while there are snapshots for the Tomcat 8.0 embedded artifacts, there is no Tomcat 8.0 version of the Tomcat Maven plugin yet, so I literally can't use it. I ended up using a few maven modules and the embedded Tomcat artifacts to create my own executable WAR. Working great now.

>
>> This may be premature (getting it working is my priority), but I
>> should mention that performance is important to what I'm doing
>> here. I'd like to enable the native code. Some applications and
>> libraries include native DLLs/SOs/JNILIBs in their JAR files, copy
>> them to a temporary directory at runtime and load them from the
>> temporary location (to avoid having to actually "install" the
>> native libraries in the OS or JVM directory structure). Is there a
>> way to do this with an embedded/executable Tomcat application so
>> that the Tomcat classes can take advantage of the native library?
>
> I'm almost sure Java won't load a shared library out of a JAR file, so
> you'll have to use this same technique: extract some shared libraries
> out of your JAR file and throw them into java.io.tmpdir/pid/shared/*
> or whatever and then instruct the JVM to load them from there (or
> modify the java.library.path system property to point to that and let
> them load naturally).

Yea. I got that working. Embedded the DLLs in the JAR file and then extracted at runtime. Learned a lot about how Tomcat loads the native library and filed and created a patch for improvement request #54700 as a result. This is a prototype for now, but if we use it for real we'll probably compile and include statically-linked Linux .so and Mac .jnilib files as well, and let the other platforms just run without APR.

>
> Just be aware that if you want an executable JAR/WAR that will run
> anywhere, you'll have to bundle all possible combinations of
> architecture, OS, etc. in order to rely on APR (and it will be a
> mess). If you provide a statically-linked tcnative (includes APR and
> OpenSSL), you may be able to survive this process, but if you want to
> support shared libraries, you're in for a world of hurt.

Understood.

>
> Also, if APR doesn't load for some reason, you'll have to configure
> your SSL Connectors completely differently (using trustStore instead
> of SSLCertificateKeyFile, etc.), which could be a real pain.

Not using SSL, so not concerned here.

>
> As for performance itself, you may not actually need APR: if you need
> SSL, then APR is probably the way to go. If you don't need SSL, stick
> to the NIO connector which provides comparable performance (from the
> testing I've done). I dunno if APR provides a faster PRNG than
> whatever the JVM provides, but I believe the AprLifecycleListener
> configures Tomcat to use the OpenSSL PRNG which may have some
> advantages -- I don't actually know.

Interesting. My reading on the Tomcat site seemed to indicate APR was better in ALL cases, not just OpenSSL. I will keep this in mind.

>
> If it were me, I'd forget about tcnative entirely.

Thanks. Consider me advised.

Attachment: users_240458.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nick,

On 3/15/13 3:56 PM, Nick Williams wrote:
> I tried using a JAR URL. (If I remember correctly, it ended up
> looking something like
> jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.

That
>
doesn't look right.

> I tried it as both a directory and a WAR file. Tomcat did not like
> it. It said "Could not deploy web application to [temporary webapps
> directory location]" or something like that. I ended up, at
> runtime, extracting the war file from the JAR file to a temporary
> directory and deploying from there. That worked great, and it's how
> the Tomcat Maven plugin executable war works, too.

Don't build your own URL. Instead, do this in your driver that calls
Tomcat:

String docBase = getClass().getResource("/web);
String ROOT = "";
tomcat.addWebapp(ROOT, docBase);

It's probably worth dumping-out the URL just to see what it looks
like. Note that your CLASSPATH can affect what getResource() will
return, so make sure you don't have too much classpath pollution.

>> I dunno anything about the Tomcat Maven plugin, but I think that
>> an executable WAR file is exactly what you are trying to build.
>
> It is. There are some issues (not bugs) with the Tomcat Maven
> plugin executable war, the first one being that it's not very easy
> to customize without using command-line arguments (makes it kind of
> hard to "double-click" and run the executable war effectively).
> Also, while there are snapshots for the Tomcat 8.0 embedded
> artifacts, there is no Tomcat 8.0 version of the Tomcat Maven
> plugin yet, so I literally can't use it. I ended up using a few
> maven modules and the embedded Tomcat artifacts to create my own
> executable WAR. Working great now.

Cool.

>>> This may be premature (getting it working is my priority), but
>>> I should mention that performance is important to what I'm
>>> doing here. I'd like to enable the native code. Some
>>> applications and libraries include native DLLs/SOs/JNILIBs in
>>> their JAR files, copy them to a temporary directory at runtime
>>> and load them from the temporary location (to avoid having to
>>> actually "install" the native libraries in the OS or JVM
>>> directory structure). Is there a way to do this with an
>>> embedded/executable Tomcat application so that the Tomcat
>>> classes can take advantage of the native library?
>>
>> I'm almost sure Java won't load a shared library out of a JAR
>> file, so you'll have to use this same technique: extract some
>> shared libraries out of your JAR file and throw them into
>> java.io.tmpdir/pid/shared/* or whatever and then instruct the JVM
>> to load them from there (or modify the java.library.path system
>> property to point to that and let them load naturally).
>
> Yea. I got that working. Embedded the DLLs in the JAR file and
> then extracted at runtime. Learned a lot about how Tomcat loads the
> native library and filed and created a patch for improvement
> request #54700 as a result.

That bug report offers a silly suggestion: use a system property to
configure where tcnative can be found because setting system
properties at startup is inconvenient? I suppose that system property
would be writable at runtime and so marginally more useful. What about
a setting where the native library wasn't loaded *at all* so an
embedded driver can load it however it wants?

> This is a prototype for now, but if we use it for real we'll
> probably compile and include statically-linked Linux .so and Mac
> .jnilib files as well, and let the other platforms just run without
> APR.

This won't work without a whole lot of work like sniffing the
architecture at runtime and then extracting only the right libraries
(or just giving them all different names).

>> Also, if APR doesn't load for some reason, you'll have to
>> configure your SSL Connectors completely differently (using
>> trustStore instead of SSLCertificateKeyFile, etc.), which could
>> be a real pain.
>
> Not using SSL, so not concerned here.
>
>> As for performance itself, you may not actually need APR: if you
>> need SSL, then APR is probably the way to go. If you don't need
>> SSL, stick to the NIO connector which provides comparable
>> performance (from the testing I've done). I dunno if APR provides
>> a faster PRNG than whatever the JVM provides, but I believe the
>> AprLifecycleListener configures Tomcat to use the OpenSSL PRNG
>> which may have some advantages -- I don't actually know.
>
> Interesting. My reading on the Tomcat site seemed to indicate APR
> was better in ALL cases, not just OpenSSL. I will keep this in
> mind.

Nope: from my testing, NIO was a better bet given the additional setup
and configuration required by APR. Plus there's a bit of overhead
managing the same resources twice (once on the Java side, once on the
native side) when using APR. Also a bug in APR can bring-down the
whole JVM instead of maybe just throwing an exception for a single
request.

Basically, if you aren't using SSL, you can abandon tcnative.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDgUcACgkQ9CaO5/Lv0PD3sgCgnEEo8iBKOUZu4nFLbPoIEhTl
5W4AoLlKo0Gi9kFzvfcaU/OAnIWo6IA+
=IjbF
-----END PGP SIGNATURE-----


Attachment: users_240463.eml (zipped)

On Mar 15, 2013, at 3:15 PM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Nick,
>
> On 3/15/13 3:56 PM, Nick Williams wrote:
>> I tried using a JAR URL. (If I remember correctly, it ended up
>> looking something like
>> jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.
>
> That
>>
> doesn't look right.

That's what Class#getResource() returned.

>
>> I tried it as both a directory and a WAR file. Tomcat did not like
>> it. It said "Could not deploy web application to [temporary webapps
>> directory location]" or something like that. I ended up, at
>> runtime, extracting the war file from the JAR file to a temporary
>> directory and deploying from there. That worked great, and it's how
>> the Tomcat Maven plugin executable war works, too.
>
> Don't build your own URL. Instead, do this in your driver that calls
> Tomcat:
>
> String docBase = getClass().getResource("/web);
> String ROOT = "";
> tomcat.addWebapp(ROOT, docBase);

I was using Class#getResource() just like this. However, Class#getResource() does not return a String. It returns a java.net.URL. I can't just pass that to addWebapp(), I had to toString() it. Just to be accurate, I ran it again and dumped the URL again (I was doing this before for debugging, but I had removed it). It's "jar:file:/C:/Users/Nicholas/Desktop/PeripheralProxy/TomcatRunner/target/Peripher
alProxy-1.0.0.SNAPSHOT.jar!/PeripheralProxy.war". So my memory was close, but not exact.

>
> It's probably worth dumping-out the URL just to see what it looks
> like. Note that your CLASSPATH can affect what getResource() will
> return, so make sure you don't have too much classpath pollution.
>
>>> I dunno anything about the Tomcat Maven plugin, but I think that
>>> an executable WAR file is exactly what you are trying to build.
>>
>> It is. There are some issues (not bugs) with the Tomcat Maven
>> plugin executable war, the first one being that it's not very easy
>> to customize without using command-line arguments (makes it kind of
>> hard to "double-click" and run the executable war effectively).
>> Also, while there are snapshots for the Tomcat 8.0 embedded
>> artifacts, there is no Tomcat 8.0 version of the Tomcat Maven
>> plugin yet, so I literally can't use it. I ended up using a few
>> maven modules and the embedded Tomcat artifacts to create my own
>> executable WAR. Working great now.
>
> Cool.
>
>>>> This may be premature (getting it working is my priority), but
>>>> I should mention that performance is important to what I'm
>>>> doing here. I'd like to enable the native code. Some
>>>> applications and libraries include native DLLs/SOs/JNILIBs in
>>>> their JAR files, copy them to a temporary directory at runtime
>>>> and load them from the temporary location (to avoid having to
>>>> actually "install" the native libraries in the OS or JVM
>>>> directory structure). Is there a way to do this with an
>>>> embedded/executable Tomcat application so that the Tomcat
>>>> classes can take advantage of the native library?
>>>
>>> I'm almost sure Java won't load a shared library out of a JAR
>>> file, so you'll have to use this same technique: extract some
>>> shared libraries out of your JAR file and throw them into
>>> java.io.tmpdir/pid/shared/* or whatever and then instruct the JVM
>>> to load them from there (or modify the java.library.path system
>>> property to point to that and let them load naturally).
>>
>> Yea. I got that working. Embedded the DLLs in the JAR file and
>> then extracted at runtime. Learned a lot about how Tomcat loads the
>> native library and filed and created a patch for improvement
>> request #54700 as a result.
>
> That bug report offers a silly suggestion: use a system property to
> configure where tcnative can be found because setting system
> properties at startup is inconvenient? I suppose that system property
> would be writable at runtime and so marginally more useful.

That was exactly the point. For my purposes, I have to sniff out the architecture at runtime (really not as hard as you suggest below, only took me about 10 minutes to write) and THEN determine which library to use. System#setProperty() makes it easy to then tell Tomcat where the library is. But you can't change the java.library.path at runtime with setProperty() (you can, it has just already been cached, so you have to use reflection on a JVM class to clear the cache, which isn't pretty). Even specifying this property on the command line at JVM startup is STILL easier than changing the java.library.path property at startup, because java.library.path isn't always constructed the same way across platforms, and changing it has some inherent risk.

> What about
> a setting where the native library wasn't loaded *at all* so an
> embedded driver can load it however it wants?

I'm not sure what you're suggesting here.

>
>> This is a prototype for now, but if we use it for real we'll
>> probably compile and include statically-linked Linux .so and Mac
>> .jnilib files as well, and let the other platforms just run without
>> APR.
>
> This won't work without a whole lot of work like sniffing the
> architecture at runtime and then extracting only the right libraries
> (or just giving them all different names).

Like I said above, it was easy. Had it working in a few minutes. Several libraries and applications use a similar approach for loading the right native library for the running platform. First one that comes to mind is NRJavaSerial [1], a fork of RXTX, a fork of Java Communications API.

>
>>> Also, if APR doesn't load for some reason, you'll have to
>>> configure your SSL Connectors completely differently (using
>>> trustStore instead of SSLCertificateKeyFile, etc.), which could
>>> be a real pain.
>>
>> Not using SSL, so not concerned here.
>>
>>> As for performance itself, you may not actually need APR: if you
>>> need SSL, then APR is probably the way to go. If you don't need
>>> SSL, stick to the NIO connector which provides comparable
>>> performance (from the testing I've done). I dunno if APR provides
>>> a faster PRNG than whatever the JVM provides, but I believe the
>>> AprLifecycleListener configures Tomcat to use the OpenSSL PRNG
>>> which may have some advantages -- I don't actually know.
>>
>> Interesting. My reading on the Tomcat site seemed to indicate APR
>> was better in ALL cases, not just OpenSSL. I will keep this in
>> mind.
>
> Nope: from my testing, NIO was a better bet given the additional setup
> and configuration required by APR. Plus there's a bit of overhead
> managing the same resources twice (once on the Java side, once on the
> native side) when using APR. Also a bug in APR can bring-down the
> whole JVM instead of maybe just throwing an exception for a single
> request.
>
> Basically, if you aren't using SSL, you can abandon tcnative.

That is indeed useful information. I had no idea. I will keep that under advisement. I still think my improvement suggestion is an improvement, though. :-)

[1] http://code.google.com/p/nrjavaserial/



Attachment: users_240456.eml (zipped)
Gentlemen (Ladies):



I am looking for a published "best practice" on editing the SERVER.XML
configuration file to use SSL/HTTPS. The key are imported into the
keystore.



Any input is appreciated.



Jeff Fisher

Omaha, NE


Attachment: users_240461.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,

On 3/15/13 4:02 PM, Jeffrey D. Fisher wrote:
> I am looking for a published "best practice" on editing the
> SERVER.XML configuration file to use SSL/HTTPS. The key are
> imported into the keystore.
>
> Any input is appreciated.

What documentation have you read so far? What steps have you taken?
What kind of Connector are you using?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDg3kACgkQ9CaO5/Lv0PBxwgCgtvWSU8gJGyvt+3BqADImfLyI
DMwAni+NRXYq6F31B7lWFrb4Vbrzv3hc
=20Dg
-----END PGP SIGNATURE-----


Attachment: users_240457.eml (zipped)
Hi,

We are seeing a leak of Unix domain sockets in Tomcat 7.0.26 configured to
run with Http11NioProtocol connector.
This is running in Ubuntu Linux 12.04.1 LTS with OpenJDK 6u24.

The leak is about 15 Unix domain sockets per hour (based on our typical
request rate), and is reaching the 4096 file limit we configured in 10 days.
These Unix domain sockets tied to the Tomcat process can be seen by issuing
lsof command (e.g. lsof | grep tomcat7 | grep socket).

The leak is absent when Tomcat runs using the BIO connector, and this would
indicate a problem in the NIO connector implementation.

I've seen the same situation indicated by someone else in the past, but
with no response:
http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=QOVmPH1dXeXOvcr+3mCgu05cqpT7Zjg@(protected)

Thanks, Luca

Attachment: users_240462.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Lucian,

On 3/15/13 4:03 PM, Lucian I wrote:
> We are seeing a leak of Unix domain sockets in Tomcat 7.0.26
> configured to run with Http11NioProtocol connector. This is running
> in Ubuntu Linux 12.04.1 LTS with OpenJDK 6u24.
>
> The leak is about 15 Unix domain sockets per hour (based on our
> typical request rate), and is reaching the 4096 file limit we
> configured in 10 days. These Unix domain sockets tied to the Tomcat
> process can be seen by issuing lsof command (e.g. lsof | grep
> tomcat7 | grep socket).

Can we get a sample of that output?

I'm fairly sure that Java does not provide access to UNIX domain
sockets, so this would have to be at the JVM implementation layer.
Obviously, Tomcat could be mismanaging some resource which ultimately
leaks these things at the native level, but it's not like we can grep
the Tomcat code for "new UNIXDomainSocket" or anything like that.

> The leak is absent when Tomcat runs using the BIO connector, and
> this would indicate a problem in the NIO connector implementation.
>
> I've seen the same situation indicated by someone else in the past,
> but with no response:
> http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=QOVmPH1dXeXOvcr+3mCgu05cqpT7Zjg@(protected)

There
>
certainly was a response:
http://markmail.org/message/wvurlmltc4mxtrcp

If you can provide more information, I'm sure it will help to diagnose
any problem. Are you able to upgrade to the current version of Tomcat 7?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDhS8ACgkQ9CaO5/Lv0PAr8gCgvAAXZkMQetf2UpsxlPfei9BC
YesAnjeYavpJsW5cN4sOuj/nowE7ODs/
=5nyS
-----END PGP SIGNATURE-----


Attachment: users_240467.eml (zipped)
Hi Christopher,

My bad for not seeing the response to the similar question posted last year.

Using lsof:

$ lsof | grep tomcat7 | grep socket | head -2
java    1341 tomcat7  74u   unix 0xffff88007a26a3c0    0t0
16985 socket
java    1341 tomcat7  98u   unix 0xffff88007a26a3c0    0t0
16985 socket
......

The count of these unix domain sockets keeps increasing and they
belong to the same Tomcat process with PID 1341.

I've talked to someone that is able to run a "load" test again and
he's going to use Tomcat 7.0.37 now and see if it makes a difference.
I'll know that next Tuesday and let you know.

I know there is no JDK API to create a Unix domain socket, but,
apparently, the JVM may create them when the application is using NIO
API, and that was a surprise for me as well.
Something that caught my eye was posted here:
http://stackoverflow.com/questions/7038688/java-nio-causes-file-descriptor-leak
That guy implemented his own server using Java NIO and ran into the
same leak by cancelling the selection key in one thread and closing
the socket channel in another thread.
I don't know whether this is the case in Tomcat, but it's something to
consider if someone familiar with the implementation is willing to do
a bit of code inspection.

Thanks for looking at it,
Lucian


On Fri, Mar 15, 2013 at 4:31 PM, Christopher Schultz
<chris@(protected):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Lucian,
>
> On 3/15/13 4:03 PM, Lucian I wrote:
>> We are seeing a leak of Unix domain sockets in Tomcat 7.0.26
>> configured to run with Http11NioProtocol connector. This is running
>> in Ubuntu Linux 12.04.1 LTS with OpenJDK 6u24.
>>
>> The leak is about 15 Unix domain sockets per hour (based on our
>> typical request rate), and is reaching the 4096 file limit we
>> configured in 10 days. These Unix domain sockets tied to the Tomcat
>> process can be seen by issuing lsof command (e.g. lsof | grep
>> tomcat7 | grep socket).
>
> Can we get a sample of that output?
>
> I'm fairly sure that Java does not provide access to UNIX domain
> sockets, so this would have to be at the JVM implementation layer.
> Obviously, Tomcat could be mismanaging some resource which ultimately
> leaks these things at the native level, but it's not like we can grep
> the Tomcat code for "new UNIXDomainSocket" or anything like that.
>
>> The leak is absent when Tomcat runs using the BIO connector, and
>> this would indicate a problem in the NIO connector implementation.
>>
>> I've seen the same situation indicated by someone else in the past,
>> but with no response:
>> http://mail-archives.apache.org/mod_mbox/tomcat-users/201201.mbox/%3CCAJkSUv-DDKTCQ-pD7W=QOVmPH1dXeXOvcr+3mCgu05cqpT7Zjg@(protected)
>
> There
>>
> certainly was a response:
> http://markmail.org/message/wvurlmltc4mxtrcp
>
> If you can provide more information, I'm sure it will help to diagnose
> any problem. Are you able to upgrade to the current version of Tomcat 7?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEAREIAAYFAlFDhS8ACgkQ9CaO5/Lv0PAr8gCgvAAXZkMQetf2UpsxlPfei9BC
> YesAnjeYavpJsW5cN4sOuj/nowE7ODs/
> =5nyS
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


Attachment: users_240459.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eugène,

On 3/14/13 10:40 AM, Eugène Adell wrote:
> Sure,
>
> you can block any IP by configuring a VALVE in the main config
> file (server.xml) :
> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter

This
>
requires a server restart. You can also block at the context level,
but this requires a context restart.

> Or if you are running Linux, you can configure the IPTABLES. This
> one is more expensive to do.

iptables is more expensive? Sorry, no: it is much cheaper in terms of
OPs time, CPU time, and (lack of) downtime.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDgn4ACgkQ9CaO5/Lv0PBWNACgnKQg+xdERJ6sAYmo+0McYeww
01AAoMEtyOf4OcmEXrs/M5cmQl8J3vtd
=48/M
-----END PGP SIGNATURE-----


Attachment: users_240460.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Fachhoch,

On 3/14/13 8:01 AM, fachhoch wrote:
> I added all my jsp  with <%@(protected)
> session count is increasing , is there any session listner which
> will debug all session creation  ,time ,ipaddress etc and session
> destroy

You can write your own: they are trivial to write if you just want to
log what code is creating the session. Capturing information about the
request is less easy: you have to write a Filter that wraps the
requests and instruments them. That's also fairly easy but does
require a certain amount of familiarity with the Servlet API.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFDgvoACgkQ9CaO5/Lv0PBf1QCfUBkcFdHEli8Wzfb6MGS1fwn3
tLkAn2xcApmBBmr7wIvoGio6hiqy99ic
=MAAO
-----END PGP SIGNATURE-----


Attachment: users_240464.eml (zipped)
I know, I know. "Don't use ThreadLocals." I've seen it on this list at least 100 times. But avoiding ThreadLocal variables can be hard:

1) Spring Framework uses ThreadLocals for things like the RequestContext. You can't just turn that off.
2) Spring Security uses ThreadLocals for things like the security context. Can't turn that off, either.
3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't always useable replacements for ThreadLocal variables. Doing this couples all aspects of your application to ServletRequests and/or HttpSessions. For example, in a multi-tenant environment, you need to establish some context that identifies which persistence location to use for obtaining and persisting data. Having to pass a request or session from servlet to service to repository is not ideal. Neither, for that matter, is having to have a "tenant" parameter (or any other type of identifying parameter) added to every single method in the entire application. And, when you're dealing with existing interfaces (Spring, Hibernate) that you have to implement, this isn't even an option sometimes.

So, with that in mind, the logical question is, how does one use ThreadLocals safely and reliably? The obvious first step is, "don't let them leak." That's easily solved. We have a filter that performs the setting of all of our ThreadLocals on the way in, and it also clears them on the way back out. The ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where they were still leaking, and we fixed those, too. But, reading about the differences between BIO/NIO/APR, I'm concerned that may not be enough.

If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen?

I don't really understand how any of this works, so some advice is greatly appreciated.

Attachment: users_240465.eml (zipped)
2013/3/16 Nick Williams <nicholas@(protected)>:
> I know, I know. "Don't use ThreadLocals." I've seen it on this list at least 100 times. But avoiding ThreadLocal variables can be hard:
>
> 1) Spring Framework uses ThreadLocals for things like the RequestContext. You can't just turn that off.
> 2) Spring Security uses ThreadLocals for things like the security context. Can't turn that off, either.
> 3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't always useable replacements for ThreadLocal variables. Doing this couples all aspects of your application to ServletRequests and/or HttpSessions. For example, in a multi-tenant environment, you need to establish some context that identifies which persistence location to use for obtaining and persisting data. Having to pass a request or session from servlet to service to repository is not ideal. Neither, for that matter, is having to have a "tenant" parameter (or any other type of identifying parameter) added to every single method in the entire application. And, when you're dealing with existing interfaces (Spring, Hibernate) that you have to implement, this isn't even an option sometimes.
>
> So, with that in mind, the logical question is, how does one use ThreadLocals safely and reliably? The obvious first step is, "don't let them leak." That's easily solved. We have a filter that performs the setting of all of our ThreadLocals on the way in, and it also clears them on the way back out. The ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where they were still leaking, and we fixed those, too. But, reading about the differences between BIO/NIO/APR, I'm concerned that may not be enough.
>
> If I understand this correctly (which I may not), BIO dedicates a thread to a request from beginning to end and then recycles that thread only when the request has completed (which is perfect), but NIO and APR do not do that. More than one request may use a given thread at (kind of) the same time. So my concern is that ThreadLocals from one request could pollute ThreadLocals in another request. Is this a concern, or are there reasons that won't happen?
>
> I don't really understand how any of this works, so some advice is greatly appreciated.


Java call chain belongs to a single thread. That is how the language
works, regardless of connectors. As long as you clear it in the same
place where you set it (a-la try/finally) you should not worry.


Attachment: users_240466.eml (zipped)
On 15/03/2013 20:53, Nick Williams wrote:
> If I understand this correctly (which I may not), BIO dedicates a
> thread to a request from beginning to end and then recycles that
> thread only when the request has completed (which is perfect), but
> NIO and APR do not do that. More than one request may use a given
> thread at (kind of) the same time. So my concern is that ThreadLocals
> from one request could pollute ThreadLocals in another request. Is
> this a concern, or are there reasons that won't happen?

Normally, all three connectors dedicate a thread to the processing of a
request from beginning to end. You can safely use ThreadLocals in the
manner you describe with any connector.

However, if you start to use Servlet 3.0 Async then you need to be a
little more careful. Once you enter async mode ThreadLocals are almost
certainly going to start causing problems. The same goes for Servlet 3.1
non-blocking IO.

Mark


Attachment: users_240468.eml (zipped)

On Mar 15, 2013, at 4:05 PM, Mark Thomas wrote:

> On 15/03/2013 20:53, Nick Williams wrote:
>> If I understand this correctly (which I may not), BIO dedicates a
>> thread to a request from beginning to end and then recycles that
>> thread only when the request has completed (which is perfect), but
>> NIO and APR do not do that. More than one request may use a given
>> thread at (kind of) the same time. So my concern is that ThreadLocals
>> from one request could pollute ThreadLocals in another request. Is
>> this a concern, or are there reasons that won't happen?
>
> Normally, all three connectors dedicate a thread to the processing of a
> request from beginning to end. You can safely use ThreadLocals in the
> manner you describe with any connector.
>
> However, if you start to use Servlet 3.0 Async then you need to be a
> little more careful. Once you enter async mode ThreadLocals are almost
> certainly going to start causing problems. The same goes for Servlet 3.1
> non-blocking IO.
>

Ahh. That makes sense. We are not currently using Async or non-blocking IO. We may at some point in the future. We will be sure to be careful with how we handle ThreadLocals at that point. Thanks!

Attachment: users_240469.eml (zipped)
On Fri, Mar 15, 2013 at 2:21 PM, Christopher Schultz
<chris@(protected):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Colin,
>
> On 3/14/13 3:41 PM, Colin Ingarfield wrote:
>> (Sorry I cannot reply correctly b/c I was on the digest list)
>>
>> The deadlocked threads: Deadlock Detection:
>>
>> Found one Java-level deadlock: =============================
>>
>> "qtp1840392480-3740": waiting to lock Monitor@(protected)
>> (Object@(protected)),
>> which is held by "PoolCleaner[2009981184:1363034108768]"
>> "PoolCleaner[2009981184:1363034108768]": waiting to lock
>> Monitor@(protected)
>> com/mysql/jdbc/JDBC4ResultSet), which is held by
>> "qtp1840392480-3740"
>>
>> Found a total of 1 deadlock.
>>
>> Here are the stack traces: Thread 12820: (state = BLOCKED) -
>> com.mysql.jdbc.ConnectionImpl.getCharacterSetMetadata() @bci=0,
>> line=2851 (Compiled frame) -
>> com.mysql.jdbc.Field.getStringFromBytes(int, int) @bci=37,
>> line=717 (Compiled frame) - com.mysql.jdbc.Field.getName() @bci=17,
>> line=631 (Interpreted frame) -
>> com.mysql.jdbc.ResultSetImpl.buildIndexMapping() @bci=78, line=752
>> (Compiled frame) -
>> com.mysql.jdbc.ResultSetImpl.findColumn(java.lang.String) @bci=12,
>> line=1110 (Interpreted frame) -
>> com.mysql.jdbc.ResultSetImpl.getString(java.lang.String) @bci=3,
>> line=5609 (Interpreted frame) -
>> org.eclipse.jetty.server.session.JDBCSessionManager$1.run()
>> @bci=111, line=844 (Interpreted frame) -
>> org.eclipse.jetty.server.handler.ContextHandler.handle(java.lang.Runnable)
>>
>>
> @bci=53, line=1119 (Interpreted frame)
>> -
>> org.eclipse.jetty.server.session.JDBCSessionManager.loadSession(java.lang.String,
>>
>>
> java.lang.String, java.lang.String) @bci=61, line=884 (Interpreted
>> frame) -
>> org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String)
>>
>>
> @bci=345, line=518 (Interpreted frame)
>> -
>> org.eclipse.jetty.server.session.JDBCSessionManager.getSession(java.lang.String)
>>
>>
> @bci=2, line=69 (Interpreted frame)
>> -
>> org.eclipse.jetty.server.session.AbstractSessionManager.getHttpSession(java.lang.String)
>>
>>
> @bci=13, line=272 (Interpreted frame)
>> -
>> org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(org.eclipse.jetty.server.Request,
>>
>>
> javax.servlet.http.HttpServletRequest) @bci=192, line=277 (Interpreted
>> frame) -
>> org.eclipse.jetty.server.session.SessionHandler.doScope(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=47, line=158
>> (Interpreted frame) -
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=416, line=999
>> (Interpreted frame) -
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=13, line=117
>> (Interpreted frame) -
>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=399, line=250
>> (Interpreted frame) -
>> org.eclipse.jetty.server.handler.HandlerCollection.handle(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=42, line=149
>> (Compiled frame) -
>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(java.lang.String,
>>
>>
> org.eclipse.jetty.server.Request,
>> javax.servlet.http.HttpServletRequest,
>> javax.servlet.http.HttpServletResponse) @bci=23, line=111
>> (Compiled frame) -
>> org.eclipse.jetty.server.Server.handle(org.eclipse.jetty.server.AbstractHttpConnection)
>>
>>
> @bci=134, line=350 (Compiled frame)
>> - org.eclipse.jetty.server.AbstractHttpConnection.handleRequest()
>> @bci=228, line=454 (Compiled frame) -
>> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete()
>> @bci=448, line=890 (Interpreted frame) -
>> java.util.HashMap.get(java.lang.Object) @bci=74, line=320 (Compiled
>> frame) -
>> org.eclipse.jetty.io.BufferCache.get(org.eclipse.jetty.io.Buffer)
>> @bci=5, line=59 (Compiled frame) -
>> org.eclipse.jetty.http.HttpParser.parseNext() @bci=625, line=371
>> (Compiled frame) -
>> org.eclipse.jetty.http.HttpParser.parseAvailable() @bci=1,
>> line=230 (Compiled frame) -
>> org.eclipse.jetty.server.AsyncHttpConnection.handle() @bci=80,
>> line=77 (Compiled frame) -
>> org.eclipse.jetty.io.nio.SslConnection.handle() @bci=36, line=191
>> (Compiled frame) -
>> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle() @bci=10,
>> line=606 (Compiled frame) -
>> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run() @bci=4,
>> line=46 (Interpreted frame) -
>> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(java.lang.Runnable)
>>
>>
> @bci=1, line=603 (Compiled frame)
>> - org.eclipse.jetty.util.thread.QueuedThreadPool$3.run() @bci=47,
>> line=538 (Compiled frame) - java.lang.Thread.run() @bci=11,
>> line=679 (Interpreted frame)
>>
>> Locked ownable synchronizers: - None
>>
>> Thread 890: (state = BLOCKED) -
>> com.mysql.jdbc.ResultSetImpl.realClose(boolean) @bci=0, line=7195
>> (Interpreted frame) - com.mysql.jdbc.ResultSetImpl.close() @bci=2,
>> line=909 (Interpreted frame) -
>> com.mysql.jdbc.StatementImpl.realClose(boolean, boolean) @bci=126,
>> line=2478 (Interpreted frame) -
>> com.mysql.jdbc.PreparedStatement.realClose(boolean, boolean)
>> @bci=71, line=3098 (Interpreted frame) -
>> com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements() @bci=90,
>> line=1628 (Interpreted frame) -
>> com.mysql.jdbc.ConnectionImpl.realClose(boolean, boolean, boolean,
>> java.lang.Throwable) @bci=176, line=4388 (Interpreted frame) -
>> com.mysql.jdbc.ConnectionImpl.close() @bci=32, line=1601
>> (Interpreted frame) -
>> org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(boolean)
>> @bci=47, line=330 (Interpreted frame) -
>> org.apache.tomcat.jdbc.pool.PooledConnection.release() @bci=2,
>> line=489 (Interpreted frame) -
>> org.apache.tomcat.jdbc.pool.ConnectionPool.release(org.apache.tomcat.jdbc.pool.PooledConnection)
>>
>>
> @bci=10, line=573 (Interpreted frame)
>> -
>> org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(org.apache.tomcat.jdbc.pool.PooledConnection)
>>
>>
> @bci=82, line=532 (Interpreted frame)
>> - org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned()
>> @bci=130, line=950 (Interpreted frame) -
>> org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run()
>> @bci=70, line=1340 (Interpreted frame) -
>> java.util.TimerThread.mainLoop() @bci=221, line=534 (Compiled
>> frame) - java.util.TimerThread.run() @bci=1, line=484 (Interpreted
>> frame)
>>
>> Locked ownable synchronizers: - <0x00000006c01b3860>, (a
>> java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync)
>>
>>
>> Once I dug up these stack traces I started to wonder if the mysql
>> driver was the problem (or contributing to the problem.) I was
>> using Connector/J version 5.1.19 when the deadlock occurred. I
>> found this bug: http://bugs.mysql.com/bug.php?id=61247 which
>> sounds a lot like what appears to have happened. I'm interested in
>> your thoughts on this.
>>
>> In the meantime I have upgraded to latest Connector/J which
>> includes a fix for this bug. I was running the old driver for
>> months before this deadlock, though, so it will be difficult to
>> know if it fixes the issue or not.
>
> Looking at that MySQL Connector/J problem and your stack traces above,
> I would think that both problems stem from multi-threaded access of
> the same java.sql.Connection object... are you grabbing a single
> connection from the pool and using it in multiple places? If so, you
> are just asking for problems like this.
>
> Your code should:
>
> 1. Check-out a connection from the pool
> 2. Use it
> 3. Return it to the pool
>
> If you do the above for every request, then you should never have any
> connections that suffer deadlock like this.
>
> Hope that helps,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEAREIAAYFAlFDdKUACgkQ9CaO5/Lv0PDveACgjyOc0C4xjDMYLlNeaEAPYvZL
> LQAAoLYigRP5nekQjINlCPjCSzLTS1zb
> =6Eto
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>

Chris,

My database access code is built on Spring 3's JDBC APIs, so I do not
do any explicit connection management in my code. Its Spring's job to
get connections and release them, and I assume its JDBC APIs is
well-tested. So I don't think my code is the problem here.

The Jetty session manager is storing HTTP session data in the
database, and it does acquire connections directly from the pool. I
haven't dug through the Jetty source to see if they are doing anything
questionable, tho I did email their user list about this issue.

The issue appears to me that a jetty worker thread had retrieved a
connection from the pool and the pool PoolCleaner thread fired up and
tried to do something w/ the same connection. Neither of these
threads "belong" to my code, which is why I'm emailing this list :)

Thanks for taking a look at it.

-- Colin


Attachment: users_240470.eml (zipped)
Hi,

I'd like to make a string available as an env entry via JNDI. The string
is static but must be created dynamically at startup time of the webapp.

I have evaluated and implemented a listener which I have added to my
context.xml. It listens for startup and shutdown events. It works pretty
well. Rethinking this makes me ask whether a listener is the right thing
to do.

Would an object factory a better approach for this?
Did I abuse the listener concept?

Code is available for inspection.

Thanks,

Michael


Attachment: users_240471.eml (zipped)
2013/3/16 Michael-O <1983-01-06@(protected)>:
> Hi,
>
> I'd like to make a string available as an env entry via JNDI. The string is
> static but must be created dynamically at startup time of the webapp.
>
> I have evaluated and implemented a listener which I have added to my
> context.xml. It listens for startup and shutdown events. It works pretty
> well. Rethinking this makes me ask whether a listener is the right thing to
> do.
>
> Would an object factory a better approach for this?
> Did I abuse the listener concept?
>
> Code is available for inspection.
>

1. Tomcat version =?
2. Looking at docs,
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
I do not see factory as an allowed attribute for environment entries.
3. Do you have control over code that uses the value?
4. Listeners are OK. I wonder though whether JNDI is modifiable or
read-only at that point in time. If it works for you, then it is has
to be modifiable.

Best regards,
Konstantin Kolinko


Attachment: users_240472.eml (zipped)
Am 2013-03-16 10:46, schrieb Konstantin Kolinko:
> 2013/3/16 Michael-O <1983-01-06@(protected)>:
>> Hi,
>>
>> I'd like to make a string available as an env entry via JNDI. The string is
>> static but must be created dynamically at startup time of the webapp.
>>
>> I have evaluated and implemented a listener which I have added to my
>> context.xml. It listens for startup and shutdown events. It works pretty
>> well. Rethinking this makes me ask whether a listener is the right thing to
>> do.
>>
>> Would an object factory a better approach for this?
>> Did I abuse the listener concept?
>>
>> Code is available for inspection.
>>
>
> 1. Tomcat version =?

I am on Tomcat 6.0.35.

> 2. Looking at docs,
> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
> I do not see factory as an allowed attribute for environment entries.

That was not my intent. I was referring to <Resource> instead of
<Environment>.

> 3. Do you have control over code that uses the value?

No(t really), it's Logback. I retrieve the value from JNDI in the
logback.xml.

> 4. Listeners are OK. I wonder though whether JNDI is modifiable or
> read-only at that point in time. If it works for you, then it is has
> to be modifiable.

It is modifiable. See my implementation please:
http://tinyurl.com/a79jdgt

And the usecase for:
http://tinyurl.com/afu9ppl

I have this in production for almost a year now but decided finally to
make it publically available under ASLv2. That's the reason for my doubts.

Michael



Attachment: users_240473.eml (zipped)
2013/3/16 Michael-O <1983-01-06@(protected)>:
> Am 2013-03-16 10:46, schrieb Konstantin Kolinko:
>
>> 2013/3/16 Michael-O <1983-01-06@(protected)>:
>>>
>>> Hi,
>>>
>>> I'd like to make a string available as an env entry via JNDI. The string
>>> is
>>> static but must be created dynamically at startup time of the webapp.
>>>
>>> I have evaluated and implemented a listener which I have added to my
>>> context.xml. It listens for startup and shutdown events. It works pretty
>>> well. Rethinking this makes me ask whether a listener is the right thing
>>> to
>>> do.
>>>
>>> Would an object factory a better approach for this?
>>> Did I abuse the listener concept?
>>>
>>> Code is available for inspection.
>>>
>>
>> 1. Tomcat version =?
>
>
> I am on Tomcat 6.0.35.
>
>
>> 2. Looking at docs,
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
>> I do not see factory as an allowed attribute for environment entries.
>
>
> That was not my intent. I was referring to <Resource> instead of
> <Environment>.
>
>
>> 3. Do you have control over code that uses the value?
>
>
> No(t really), it's Logback. I retrieve the value from JNDI in the
> logback.xml.
>
>
>> 4. Listeners are OK. I wonder though whether JNDI is modifiable or
>> read-only at that point in time. If it works for you, then it is has
>> to be modifiable.
>
>
> It is modifiable. See my implementation please:
> http://tinyurl.com/a79jdgt
>
> And the usecase for:
> http://tinyurl.com/afu9ppl
>
> I have this in production for almost a year now but decided finally to make
> it publically available under ASLv2. That's the reason for my doubts.
>

Generally I do not see anything substantially wrong with the code.

Some comments on the code:

1. In logback-test.xml you use ${CONTEXT_NAME}
I think it is a typo, as you are using "contextName" elsewhere.

2. In LogbackContextNameListener.java
Dependency on commons-lang is a bad thing here, as the class has to go
into ${catalina.base}/lib and it would be better to minimize
dependencies. You should not use libraries that might be included into
webapps, or you will be open to classloader issues, memory leaks etc.
The method you are using is trivial to be implemented inline.

3. I prefer to use "constantString.equals(value)" instead of
"value.equals(constantString)" because of nulls. Not an issue here
though. Just style.

(in "le.getType().equals( Lifecycle.eventname)" calls).

4. You are not really changing JNDI. You are changing context
configuration that JNDI is populated from later.
(NamingContextListener registers itself as PropertyChangeListener on
NamingResources and propagates your changes to JNDI)

5. I would not clear the value on stop event. It causes unnecessary
work (propagating the value to JNDI) and shutdown is supposed to be
fast.

Double assignments during repeated starts should not be an issue, but
if they are then you can call
context.getNamingResources().removeEnvironment(name) before adding.

6. A Factory will not have access to Context. A Listener is better here.

Best regards,
Konstantin Kolinko


Attachment: users_240474.eml (zipped)
Am 2013-03-16 11:43, schrieb Konstantin Kolinko:
> 2013/3/16 Michael-O <1983-01-06@(protected)>:
>> Am 2013-03-16 10:46, schrieb Konstantin Kolinko:
>>
>>> 2013/3/16 Michael-O <1983-01-06@(protected)>:
>>>>
>>>> Hi,
>>>>
>>>> I'd like to make a string available as an env entry via JNDI. The string
>>>> is
>>>> static but must be created dynamically at startup time of the webapp.
>>>>
>>>> I have evaluated and implemented a listener which I have added to my
>>>> context.xml. It listens for startup and shutdown events. It works pretty
>>>> well. Rethinking this makes me ask whether a listener is the right thing
>>>> to
>>>> do.
>>>>
>>>> Would an object factory a better approach for this?
>>>> Did I abuse the listener concept?
>>>>
>>>> Code is available for inspection.
>>>>
>>>
>>> 1. Tomcat version =?
>>
>>
>> I am on Tomcat 6.0.35.
>>
>>
>>> 2. Looking at docs,
>>>
>>> http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment%20Entries
>>> I do not see factory as an allowed attribute for environment entries.
>>
>>
>> That was not my intent. I was referring to <Resource> instead of
>> <Environment>.
>>
>>
>>> 3. Do you have control over code that uses the value?
>>
>>
>> No(t really), it's Logback. I retrieve the value from JNDI in the
>> logback.xml.
>>
>>
>>> 4. Listeners are OK. I wonder though whether JNDI is modifiable or
>>> read-only at that point in time. If it works for you, then it is has
>>> to be modifiable.
>>
>>
>> It is modifiable. See my implementation please:
>> http://tinyurl.com/a79jdgt
>>
>> And the usecase for:
>> http://tinyurl.com/afu9ppl
>>
>> I have this in production for almost a year now but decided finally to make
>> it publically available under ASLv2. That's the reason for my doubts.
>>
>
> Generally I do not see anything substantially wrong with the code.

First of all, thank you for your valuable inspection. It is highly
appreciated. I will comment inline.

> Some comments on the code:
>
> 1. In logback-test.xml you use ${CONTEXT_NAME}
> I think it is a typo, as you are using "contextName" elsewhere.

No, it's not. ${CONTEXT_NAME} is a context scoped, by default predefined
variable with the context name. Please see here:
http://logback.qos.ch/manual/configuration.html#variableSubstitution

> 2. In LogbackContextNameListener.java
> Dependency on commons-lang is a bad thing here, as the class has to go
> into ${catalina.base}/lib and it would be better to minimize
> dependencies. You should not use libraries that might be included into
> webapps, or you will be open to classloader issues, memory leaks etc.
> The method you are using is trivial to be implemented inline.

I am fully aware of that and always keep that in mind. In that case,
there is no need to worry for the extra dependency. I am shading all
necessary classes in an internal package in the JAR. They won't collide
with deployed webapps. See http://tinyurl.com/cx7tzne

> 3. I prefer to use "constantString.equals(value)" instead of
> "value.equals(constantString)" because of nulls. Not an issue here
> though. Just style.

I have seen this approach already in several spots in some Apache
projects but haven't yet grasped the advantages because I always check
input for validity.

> 4. You are not really changing JNDI. You are changing context
> configuration that JNDI is populated from later.
> (NamingContextListener registers itself as PropertyChangeListener on
> NamingResources and propagates your changes to JNDI)

Wow, that's new. But this
"context.getNamingResources().addEnvironment(ce);" does add objects to
the context? So, if I understand correctly, startup phase has a staging
set of objects from which the final, read-only JNDI context will be build?

> 5. I would not clear the value on stop event. It causes unnecessary
> work (propagating the value to JNDI) and shutdown is supposed to be
> fast.
>
> Double assignments during repeated starts should not be an issue, but
> if they are then you can call
> context.getNamingResources().removeEnvironment(name) before adding.

Thanks, I will remove the if loop. But reading your comment, I should
add a checker on startup which verifies whether that env entry is
already set?

Something like:

if (le.getType().equals(Lifecycle.START_EVENT)) {
check for presence;
if yes
remove;

add value;
}

> 6. A Factory will not have access to Context. A Listener is better here.

Yes, but it would spit out the same string which will be cached and
returned to the app. The outcome would be the same, at least from the
app's point of view.


Michael


©2008 junlu.com - Jax Systems, LLC, U.S.A.