Re: Tomcat Connection Pool

2016-12-07 Thread Kaloyan Spiridonov 
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

2016-12-07 Thread Михаил Ткаченко 
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

2016-12-07 Thread Berg, R. van den (Robin) 
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

2016-12-07 Thread Taylor, Larry 

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

2016-12-07 Thread Christopher Schultz 
-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

2016-12-07 Thread Christopher Schultz 
-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

2016-12-07 Thread John D. Ament 
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

2016-12-07 Thread Berg, R. van den (Robin) 
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

2016-12-07 Thread Mark Thomas 
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

2016-12-07 Thread Mark Thomas 
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