Re: Tomcat Connection Pool
Hello, As it is described in jdbc connection pool documentation: maxActive (int) The maximum number of active connections that can be allocated from this pool at the same time. The default value is 100 Best Regards, Kaloyan On Thu, Dec 8, 2016 at 9:47 AM, Михаил Ткаченко wrote: > Hi! Do you tell me what maxActive option means? Is it the amount of all > connection in the pool? Or is it max number of connection which in use at > the certain moment? Thanks. >
Tomcat Connection Pool
Hi! Do you tell me what maxActive option means? Is it the amount of all connection in the pool? Or is it max number of connection which in use at the certain moment? Thanks.
RE: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources
Hi, No. For the record: I didn't posted the issue on https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html. I merely stumbled upon somebody having the same issue. I wanted to file an enhancement request. But, as also noted by the "what to do before posting a bug/enhancement"-page, I wanted to be sure there is no solution to this problem yet. I was interested whether this was already fixed perhaps, even though I couldn't find anything. Also, maybe somebody knows a 'workaround', which would me because I don't have time to wait for the enhancement. Furthermore, I can't even use the newest version, unfortunately. That depends on the PAAS party. Kind Regards, -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, December 07, 2016 10:58 PM To: Tomcat Users List Subject: Re: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robin, On 12/7/16 4:01 AM, Berg, R. van den (Robin) wrote: > Hello! I have an issue that seems not supported anymore with Tomcat 8. > The same problem is also posted in the comments on: > https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html > > PROBLEM: We used the virtualWebAppLoader to get some extra libraries > and classes that were on the machine on the classloader. > The virtualClasspath-property of the virtualWebAppLoader was a > ';'-seperated list of directories. If one of them was empty, that was > not a problem. We used the fact that non-existing/empty directories > were not loaded, without any exception. MQ were imported on > Test-acceptance-production. However, in a local/dev-setup we do not > provide these libraries, since MQ-services are stubbed out. > > We used the {Jar|File|Dir}ResourceSet in the context.xml as > replacement for the virtualWebAppLoader, as recommended by the > migration guide. However, these fail when the base-property is > non-existent. Therefore, it breaks dev/local. > > In the comments in > https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a > solution was posted to extend the {Jar|File|Dir}ResourceSet. > However, that solution won't work for us, since we can't provide the > tomcat-instances on test-acc-prd with an extra class/library with the > extended class. (access-rights/cloud-solution only allows default > setup). > > PREFERRRED SOLUTION: Just like the tomcat 7 virtualWebAppLoader we > would like the ResourceSet to be optional/non-failing if the resource > is not available. Is there any configuration/property I can use to do > that? Did you file an enhancement request as suggested by Konstantin all those months ago? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYSIXzAAoJEBzwKT+lPKRYRlcP/ip62nstdty643NjIdy8ImN4 /lhGdpw9qUfGTDiGF/wtqfOeAcTOIfoH1f0ZmnNaP9lZFMu917IT6Z0y3+fOwwnE M3GPKBCZTQne3wY2oHqZujv4WVAiYzmcNlPDxeHljxP/aSiAf6DOyaWwGFLlUIml 7RiGBE+oJGQAMhohulPvSlh1ldSAsF637+xJA0O18DpRdSx9ikgDeeodRtA9Ei1d R8sbZ9atYTqMH9ee4GBkc8yJDfZqf3Fo1FUjKghB3S4M9yxyjKqLqJORrFm4fOLH PM4Oq7gkLEJNBWhkzABj6ruMw5/PHXrz4BV+K7rapdCSH7Bg5WXASiX0O0Z/rw1G nVgd4kVwLRqDnRANjyU8+BnzyDq0sQ0Ndp6EZ/Sw4xBnaopQyYX9jsaqkQ8tqSg2 md4LdkX4axn/w0EhnE/XtVLBmmsjC4L7ALuGFleG+Etp2gh3vKE1rmhphwHUqvXX GEKjR6HnXbCGKwJHkWt9lawpmK8N+VmI9FSbyx0vh4kheMjIUQmkH7uNnJhGOQc4 FO5GrS+zqEJwuDoBVZny2ZjSeOctu5bPJGfwd2nZa0uG8qra6Qhi8RCLSkG2ZPsq EABJEpoLZMeiB6U6TFNQrxUFUTn1dtLQgQxKdbq8hUxX4n5KMl/12pZNhyapfor4 /PvNObLiXIy6930k/0Ag =+++8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Is there a class or way in Tomcat to write org.apache.catalina.authenticator messages to a different logfile
Hello, Is there a class or way in Tomcat to write org.apache.catalina.authenticator messages to a different logfile? I'm using Tomcat 8.0.9 - I have logging turned on for the realm authentication but i cannot get authentication messages to write to a different log prefix file other than catalalina.out. Is there a way to do this and keep the normal server messages writing to catalina.out? In conf/logging.properties - this writes fine to catalina.out # Handler specific properties. # Describes specific configuration info for Handlers . org.apache.catalina.realm.level = FINE org.apache.catalina.realm.useParentHandlers = true org.apache.catalina.authenticator.level = FINE org.apache.catalina.authenticator.useParentHandlers = true I did not see any org.apache.catalina.authenticator.juli.AsyncFileHandler classes to do this - I need somthing like: org.apache.catalina.authenticator.juli.AsyncFileHandler.prefix = authuser. thanks for any information on how to configure this. -Larry - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Robin, On 12/7/16 4:01 AM, Berg, R. van den (Robin) wrote: > Hello! I have an issue that seems not supported anymore with Tomcat > 8. The same problem is also posted in the comments on: > https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html > > PROBLEM: We used the virtualWebAppLoader to get some extra > libraries and classes that were on the machine on the classloader. > The virtualClasspath-property of the virtualWebAppLoader was a > ';'-seperated list of directories. If one of them was empty, that > was not a problem. We used the fact that non-existing/empty > directories were not loaded, without any exception. MQ were > imported on Test-acceptance-production. However, in a > local/dev-setup we do not provide these libraries, since > MQ-services are stubbed out. > > We used the {Jar|File|Dir}ResourceSet in the context.xml as > replacement for the virtualWebAppLoader, as recommended by the > migration guide. However, these fail when the base-property is > non-existent. Therefore, it breaks dev/local. > > In the comments in > https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a > solution was posted to extend the {Jar|File|Dir}ResourceSet. > However, that solution won't work for us, since we can't provide > the tomcat-instances on test-acc-prd with an extra class/library > with the extended class. (access-rights/cloud-solution only allows > default setup). > > PREFERRRED SOLUTION: Just like the tomcat 7 virtualWebAppLoader we > would like the ResourceSet to be optional/non-failing if the > resource is not available. Is there any configuration/property I > can use to do that? Did you file an enhancement request as suggested by Konstantin all those months ago? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYSIXzAAoJEBzwKT+lPKRYRlcP/ip62nstdty643NjIdy8ImN4 /lhGdpw9qUfGTDiGF/wtqfOeAcTOIfoH1f0ZmnNaP9lZFMu917IT6Z0y3+fOwwnE M3GPKBCZTQne3wY2oHqZujv4WVAiYzmcNlPDxeHljxP/aSiAf6DOyaWwGFLlUIml 7RiGBE+oJGQAMhohulPvSlh1ldSAsF637+xJA0O18DpRdSx9ikgDeeodRtA9Ei1d R8sbZ9atYTqMH9ee4GBkc8yJDfZqf3Fo1FUjKghB3S4M9yxyjKqLqJORrFm4fOLH PM4Oq7gkLEJNBWhkzABj6ruMw5/PHXrz4BV+K7rapdCSH7Bg5WXASiX0O0Z/rw1G nVgd4kVwLRqDnRANjyU8+BnzyDq0sQ0Ndp6EZ/Sw4xBnaopQyYX9jsaqkQ8tqSg2 md4LdkX4axn/w0EhnE/XtVLBmmsjC4L7ALuGFleG+Etp2gh3vKE1rmhphwHUqvXX GEKjR6HnXbCGKwJHkWt9lawpmK8N+VmI9FSbyx0vh4kheMjIUQmkH7uNnJhGOQc4 FO5GrS+zqEJwuDoBVZny2ZjSeOctu5bPJGfwd2nZa0uG8qra6Qhi8RCLSkG2ZPsq EABJEpoLZMeiB6U6TFNQrxUFUTn1dtLQgQxKdbq8hUxX4n5KMl/12pZNhyapfor4 /PvNObLiXIy6930k/0Ag =+++8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat listener not coming up - no stuck threads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 12/7/16 7:19 AM, John D. Ament wrote: > On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas > wrote: > >> On 06/12/2016 02:59, John D. Ament wrote: >> >> >> >>> So I was able to identify my issue. It's not specifically a >>> tomcat problem, but tomcat's bootstrapping makes it unique. >>> >>> one of the issues I've observed is that Tomcat's use of >>> multithreading causes some thread deadlocking with some >>> synchronized blocks. I was wondering if there's a way to turn >>> that off? Make tomcat's bootstrap happen in the same thread as >>> the original invocation? >> >> What exactly do you mean by Tomcat's bootstrapping? Can you give >> an example of concurrent execution that is causing issues? >> > > I instantiate the Tomcat object and invoke start() on the "main" > thread. The invocation of ServletContextListeners happens on a > "localhost-startStop-1" thread. I would like to have that > invocation happen on the main thread instead. Hmm... there is the "startStopThreads" setting on the Engine, but unfortunately there is not (currently available) setting that says "don't use multiple threads at all". It looks like Tomcat is always going to use at least one (separate) thread to launch the various Hosts (and webapps). > Its nothing within tomcat that is deadlocking, but under the covers > weld has a synchronized block, its inside that synchronized block > where Tomcat is instantiated. There's a later point where Weld > tries getting a lock again. In that case, when its single threaded > (in other containers) it passes since it has a lock, but in this > case it can't get that lock. Is there any way for you to remove the required monitor on your own code? Or is Weld so intricately-involved in the whole process that unwinding it isn't possible? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYSCkWAAoJEBzwKT+lPKRYIUcP/2lSnNrqoW4XXUKuFVLJXijl w/+TiQz58pjo7KCpXzRC6ubBPIQNO5Hj5HbukXuglNJfaWbEnoIdf9zlSOElg13a t+Pc4OFvdFYc0uzMf5E824AvXeLR5A4SAuMxzzg86DEdJZiAW4MwEoY/UduPN1b6 PQM74JS5iXNTGQjaNZQfonS26Gsrwi69fnC+evcJ/RDGZxUIq/NAZVU1zD0wjAAh p0dzvRqkO5XjirCF8xyUgoUIHn1LdygZrOMkDby3XY23/nQVN+JxmlPDc/Lwl+nt a2Ywkw0D5ATkHBzqZC8ksmkFVWIiGKMZacOBKci5sv+APdTzohpAUicleZ+bQB6l tYkTwhmqkAn27B1Zj+ev7efAz+LbjyKzBGHLztD3r+lhkfBRJrotprEIA5MWXLiD SLrBwXcJqSLkipoKDpCwrkBHrMnHTUi1M7NyLDXSgRw/ynJfoUnN/FjssNft7K09 RtxMktXqD3FBX74tIbEUmdU5OmEGAuSIiOrjKyYgH8vXmyqo44kIw9c8EapY1mVS FQurOjEOXO+rk5TnWWOvT22pcH3sgfH486YaaiUJ0tW7DraQFOIqVq2jlb/tSwW7 Yai218JiEQJRR1ps+ZZyXqhsSVfTJ8CSnGDsWROJuMSO7roBJQXbutftAJjxHC0M V7Mfo/Q2YhRhrL1fPcuW =jiLD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat listener not coming up - no stuck threads
On Wed, Dec 7, 2016 at 3:58 AM Mark Thomas wrote: > On 06/12/2016 02:59, John D. Ament wrote: > > > > > So I was able to identify my issue. It's not specifically a tomcat > > problem, but tomcat's bootstrapping makes it unique. > > > > one of the issues I've observed is that Tomcat's use of multithreading > > causes some thread deadlocking with some synchronized blocks. I was > > wondering if there's a way to turn that off? Make tomcat's bootstrap > > happen in the same thread as the original invocation? > > What exactly do you mean by Tomcat's bootstrapping? Can you give an > example of concurrent execution that is causing issues? > I instantiate the Tomcat object and invoke start() on the "main" thread. The invocation of ServletContextListeners happens on a "localhost-startStop-1" thread. I would like to have that invocation happen on the main thread instead. Its nothing within tomcat that is deadlocking, but under the covers weld has a synchronized block, its inside that synchronized block where Tomcat is instantiated. There's a later point where Weld tries getting a lock again. In that case, when its single threaded (in other containers) it passes since it has a lock, but in this case it can't get that lock. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Migration to Tomcat 8.0 Post/PreResources vs VirtualWebappLoader with optional resources
Hello! I have an issue that seems not supported anymore with Tomcat 8. The same problem is also posted in the comments on: https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html PROBLEM: We used the virtualWebAppLoader to get some extra libraries and classes that were on the machine on the classloader. The virtualClasspath-property of the virtualWebAppLoader was a ';'-seperated list of directories. If one of them was empty, that was not a problem. We used the fact that non-existing/empty directories were not loaded, without any exception. MQ were imported on Test-acceptance-production. However, in a local/dev-setup we do not provide these libraries, since MQ-services are stubbed out. We used the {Jar|File|Dir}ResourceSet in the context.xml as replacement for the virtualWebAppLoader, as recommended by the migration guide. However, these fail when the base-property is non-existent. Therefore, it breaks dev/local. In the comments in https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html a solution was posted to extend the {Jar|File|Dir}ResourceSet. However, that solution won't work for us, since we can't provide the tomcat-instances on test-acc-prd with an extra class/library with the extended class. (access-rights/cloud-solution only allows default setup). PREFERRRED SOLUTION: Just like the tomcat 7 virtualWebAppLoader we would like the ResourceSet to be optional/non-failing if the resource is not available. Is there any configuration/property I can use to do that? Thanks, Kind Regards, ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat listener not coming up - no stuck threads
On 06/12/2016 02:59, John D. Ament wrote: > So I was able to identify my issue. It's not specifically a tomcat > problem, but tomcat's bootstrapping makes it unique. > > one of the issues I've observed is that Tomcat's use of multithreading > causes some thread deadlocking with some synchronized blocks. I was > wondering if there's a way to turn that off? Make tomcat's bootstrap > happen in the same thread as the original invocation? What exactly do you mean by Tomcat's bootstrapping? Can you give an example of concurrent execution that is causing issues? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector bindOnInit=false not behaving as expected
On 06/12/2016 16:25, Christopher Schultz wrote: > On 12/6/16 4:17 AM, Mark Thomas wrote: >> It should be as simple as: > >> 1. Construct a new SSLContext > >> 2. Replace the old SSLContext with the new one. > > So if there were a reloadTLSConfiguration method on the Connector (or > similar component), it could simply call setSSLContext() on the > SSLHostConfigCertificate and wait for the next request to come in? In theory, yes. I haven't tested that though. >> I think what we need is a refreshTLSConfig() method. > > Perfect. > > If such a method were to be on the Connector (at least for the JMX > bean representing the Connector), it looks like a fairly simple call > (or calls.. for each SSLHostConfig) to > AbstractEndpoint.createSSLContext would do the trick. That method > seems to not only create the SSLContext but also set that new context > on the certificate (SSLHostConfigCertificate) object. > > I think there might be some thread-safety issues though with the > changing configuration of e.g. sslHostConfig.enabledProtocols and > sslHostConfig.enabledCiphers before the certificate is updated. As it > stands, the code seems to expect that, once initialized, no later > re-initializations occur. We'd need to make sure that we swap-out that > configuration in an atomic way. The SSLContext is built separately and > dropped-onto the certificate object. sslHostConfigs is a ConcurrentHashMap. It might be possible to construct the whole new SSLHostConfig (and associated SSLHostConfigCertificate and SSLContext objects) and then do an atomic update of the mapping in sslHostConfigs. > Finally, even for JSSE, there is a releaseSSLContext() that looks like > it should probably be called[1]. So I think for both OpenSSL and JSSE, > we'd want to use the same technique. Something like a list of > currently in-use SSLContext objects (it should be fairly limited) and > when one of them drops-out of the "in-use" list, we properly-dispose > of it. > > That essentially requires reference-counting around > connection-management: check-out an SSLContext and then release it > afterward. The last release for a shutting-down SSLContext will > release that context. > > Does that sound ... overly complicated or foolish? I'm sensitive to > the fact that there will be a performance impact for something like this > . I don't see any option other than reference counting. That could also get very tricky. It is worth considering keeping a list of all SSLContexts used and shutting them all down when the Connector stops. i.e. trade memory for complexity. > WDYT? Certainly worth exploring. > [1] After a little more reading, I see that the JSSESSLContext has a > no-op implementation of destroy(). So we could be a bit lazy for a > first implementation. The destroy() method is only there because APR/native needs it. It is certainly easier to try this out with JSSE but any solution is going to have to cover APR as well in the end. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org