Re: Connection closed error and certificateVerification="required"

[Mark Thomas]

On 22/03/18 15:27, Richard Tearle wrote:
> On 22 March 2018 at 14:49, Mark Thomas  wrote:



>> What we have so far is:
>>
>> 8.0.x, http-nio- (this is always JSSE in 8.0.x), clientAuth="true"
>> This works.
> 
> Yes this works.
> 
>> 8.5.x, http-nio-openssl-, certificateVerification="required"
>> This fails intermittently
> 
> Its https-openssl-nio- and yes this fails intermittently.
> 
>> 8.5.x, http-nio-jsse-,  certificateVerification="required"
>> This works
> 
> Its https-jsse-nio-, and yes this works
> 
>> Is this correct?
>>
>> Thanks,
>>
>> Mark
>>
> 
> Also working is 8.5.x, https-openssl-nio-, certificateVerification="none"

OK. Time to think about this. NIO + JSSE works whereas NIO + OpenSSL
doesn't with the same configuration apart from the presence of the
native library.

That points to something OpenSSL specific.

Disabling client verification fixes the problem.

So it looks to be something to do with how OpenSSL handles client
verification. It feels like configuration at this point rather than a
bug but it needs some more thought.

There will probably be some configuration combinations to experiment
with but if they fail, something we can use to reproduce this is going
to be the next step.

Mark

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

Re: Granting permission to a single application-supplied JAR

[Konstantin Kolinko]

2018-03-23 1:32 GMT+03:00 Christopher Schultz :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Konstantin,
>
> Thanks for the reply.
>
> On 3/22/18 6:12 PM, Konstantin Kolinko wrote:
>> 2018-03-23 0:39 GMT+03:00 Christopher Schultz
>> :
>>> All,
>>>
>>> I'm working on getting my application working under a
>>> SecurityManager. It's actually been a little less painful than I
>>> thought it would be.
>>>
>>> I'm using Solr for some index searching. I'm using SolrJ for the
>>> library to communicate via HTTP to a localhost Solr server. When
>>> using this grant:
>>>
>>> grant { permission "java.util.PropertyPermission"
>>> "solr.httpclient.builder.factory", "read"; permission
>>> "java.net.SocketPermission", "localhost:8983",
>>> "resolve,connect"; }
>>>
>>> My application can can contact Solr without any errors.
>>>
>>> If I change the "grant" to include a codeBase to restrict those
>>> connections to the Solr library, I get a AccessControlException:
>>> access denied to the system property. Here is the modified
>>> grant:
>>>
>>>
>>> grant codeBase
>>> "file:${catalina.base}${file.separator}webapps${file.separator}myapp$
> {fi
>>>
>>>
> le.separator}WEB-INF${file.separator}lib${file.separator}solr-solrj-7.2.
>>> 1.jar" { permission "java.util.PropertyPermission"
>>> "solr.httpclient.builder.factory", "read"; permission
>>> "java.net.SocketPermission" "localhost:8983", "resolve,connect";
>>> };
>>>
>>> I have verified that the file exists under the path specified
>>> above. I tried both ${file.separator} and '/' as the file
>>> separator. I also tried "jar:/path/to/jar!/-" as the codeBase. No
>>> luck.
>>
>> 1) The "grant" clause uses an URL, with '/'.
>>
>> ${file.separator} is used in file paths for a file system: in
>> java.io.FilePermission
>
> Thanks for pointing that out. I tried both ways and it did not make a
> difference.
>
>>> These grants are added to the end of the stock catalina.policy
>>> file that ships with Tomcat.
>>>
>>> What am I missing, here?
>>
>> 2) Tomcat version=? ;)
>
> 8.5.29, but this is a JVM security policy problem and should not be
> affected by the Tomcat version.
>
>> See "Troubleshooting" recipe here:
>>
>> http://tomcat.apache.org/tomcat-8.5-doc/security-manager-howto.html#Tr
> oubleshooting
>>
>>  You need to know the actual permission that failed.
>
> It's java.util.PropertyPermission to "read" the system property
> "solr.httpclient.builder.factory". Specifying no codeBase allows the
> code to execute.
>
>> You need to know java.security.CodeSource.getLocation() for all
>> classes in stacktrace up to the failing point (starting from the
>> nearest AccessController.doPrivileged()).
>
> Umm... how in the word do I determine that?
>
>> All those CodeSources should have that permission. If you missed
>> one, you will fail.
>
> So I'm going to assume that there are no doPrivileged() calls anywhere
> in the call stack. Does that mean that I have two options:
>
> 1. Grant the privilege to the whole JVM (as I have confirmed does work)
>
> 2. Add a doPrivileged() call somewhere that eventually attempts to
> read this system property?

Reads of a system property are usually wrapped in doPrivileged().

E.g. see java.io.PrintWriter constructor in Java 8u162:

lineSeparator = java.security.AccessController.doPrivileged(
new sun.security.action.GetPropertyAction("line.separator"));

The code above assumes that sun.* classes cannot be accessed by untrusted code.
(In case of Tomcat this is true thanks to "package.access" setting in
catalina.properties.)

>
> I also attempted to give the permission to me web application as a
> whole like this:
>
> grant codeBase
> "file:${catalina.base}/webapps/mywebapp/WEB-INF/classes/-" {
>   // same privileges
> };

The above grants permission to "WEB-INF/classes" directory, The
libraries are in "lib". There are also JSPs.

Example in catalina.policy:

// The permissions granted to the context root directory apply to JSP pages.
// grant codeBase "file:${catalina.base}/webapps/examples/-" {
//  permission java.net.SocketPermission
"dbhost.mycompany.com:5432", "connect";
//  permission java.net.SocketPermission "*.noaa.gov:80", "connect";
// };


Best regards,
Konstantin Kolinko

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

Re: Granting permission to a single application-supplied JAR

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

Thanks for the reply.

On 3/22/18 6:12 PM, Konstantin Kolinko wrote:
> 2018-03-23 0:39 GMT+03:00 Christopher Schultz
> :
>> All,
>> 
>> I'm working on getting my application working under a
>> SecurityManager. It's actually been a little less painful than I
>> thought it would be.
>> 
>> I'm using Solr for some index searching. I'm using SolrJ for the 
>> library to communicate via HTTP to a localhost Solr server. When
>> using this grant:
>> 
>> grant { permission "java.util.PropertyPermission" 
>> "solr.httpclient.builder.factory", "read"; permission
>> "java.net.SocketPermission", "localhost:8983", 
>> "resolve,connect"; }
>> 
>> My application can can contact Solr without any errors.
>> 
>> If I change the "grant" to include a codeBase to restrict those 
>> connections to the Solr library, I get a AccessControlException: 
>> access denied to the system property. Here is the modified
>> grant:
>> 
>> 
>> grant codeBase 
>> "file:${catalina.base}${file.separator}webapps${file.separator}myapp$
{fi
>>
>> 
le.separator}WEB-INF${file.separator}lib${file.separator}solr-solrj-7.2.
>> 1.jar" { permission "java.util.PropertyPermission" 
>> "solr.httpclient.builder.factory", "read"; permission
>> "java.net.SocketPermission" "localhost:8983", "resolve,connect"; 
>> };
>> 
>> I have verified that the file exists under the path specified
>> above. I tried both ${file.separator} and '/' as the file
>> separator. I also tried "jar:/path/to/jar!/-" as the codeBase. No
>> luck.
> 
> 1) The "grant" clause uses an URL, with '/'.
> 
> ${file.separator} is used in file paths for a file system: in 
> java.io.FilePermission

Thanks for pointing that out. I tried both ways and it did not make a
difference.

>> These grants are added to the end of the stock catalina.policy
>> file that ships with Tomcat.
>> 
>> What am I missing, here?
> 
> 2) Tomcat version=? ;)

8.5.29, but this is a JVM security policy problem and should not be
affected by the Tomcat version.

> See "Troubleshooting" recipe here:
> 
> http://tomcat.apache.org/tomcat-8.5-doc/security-manager-howto.html#Tr
oubleshooting
>
>  You need to know the actual permission that failed.

It's java.util.PropertyPermission to "read" the system property
"solr.httpclient.builder.factory". Specifying no codeBase allows the
code to execute.

> You need to know java.security.CodeSource.getLocation() for all 
> classes in stacktrace up to the failing point (starting from the 
> nearest AccessController.doPrivileged()).

Umm... how in the word do I determine that?

> All those CodeSources should have that permission. If you missed
> one, you will fail.

So I'm going to assume that there are no doPrivileged() calls anywhere
in the call stack. Does that mean that I have two options:

1. Grant the privilege to the whole JVM (as I have confirmed does work)

2. Add a doPrivileged() call somewhere that eventually attempts to
read this system property?

I also attempted to give the permission to me web application as a
whole like this:

grant codeBase
"file:${catalina.base}/webapps/mywebapp/WEB-INF/classes/-" {
  // same privileges
};

And this does not work, either.

Do I have to put everything in doPrivileged() calls in order to
actually access the permissions I'm trying to grant using the "grant
codeBase" in my policy? THAT is going to be ... inconvenient. :(

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq0Lv4dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjLDRAArruXzHe0C5Ra2tfw
NngUE9/lKmnh5XoefF+M8iaUxA6X3GICMxCJtO7tdK/thMj7VAmmTGNoxTXoQXAL
HYR7ERuVbUzvcgys08Mu3rxd/r8T4Fhy3LWO/7WhSiRAnEAQjan/Q07NqD98O9jf
Etvcw6I2iLdO7bGt00/O/lwTHfYiWZQK542RgoU4SV5JsC0V9rr/eOgr5M/mnYqY
C6Lqi9f1ewJNe//oxMBztN5gDxW8SnXt7XS8R9I39GA5f1Mnd5Q4Ex53h3CiSkgF
27WW/yA9D7lE+zIEwUdnNq3kSGLrArgclPtAarl5JuzxNpiOLU6jtG1Tp3N4PKum
HpORNTTJYVC/+TrblBk9zsLQjoHh8Aut+VlrmKVfzIDkET1p+xRWDSp/7kZnOUAY
eZGSXSJYNwqGahCjMWj3R6QR6x+IQre4Y+kauDFisoKqLO9gjakBOwBvIuAGFeOE
YjrZRZ4sndiAVji/5tcAWCJjS4NMGQ0uqswzZyhSEaJTXa3GWceaEmfULPLZ2CQr
n1UKxNlBcHk84M0ktXif6TxP6547oDoyB80+OxkgUsh1SeNqs5MyJ4JcKWjkfOUu
4efV40XpDlUPwcOev/PHlqSjqyz+pTY6iiDJjkahfgjKT7ICloSe+5SsqlzBJqYA
/CcgxZGu0IPUuwmm6XXmMaglj6s=
=j0wy
-END PGP SIGNATURE-

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

Re: Granting permission to a single application-supplied JAR

[Konstantin Kolinko]

2018-03-23 0:39 GMT+03:00 Christopher Schultz :
> All,
>
> I'm working on getting my application working under a SecurityManager.
> It's actually been a little less painful than I thought it would be.
>
> I'm using Solr for some index searching. I'm using SolrJ for the
> library to communicate via HTTP to a localhost Solr server. When using
> this grant:
>
> grant {
>   permission "java.util.PropertyPermission"
> "solr.httpclient.builder.factory", "read";
>   permission "java.net.SocketPermission", "localhost:8983",
> "resolve,connect";
> }
>
> My application can can contact Solr without any errors.
>
> If I change the "grant" to include a codeBase to restrict those
> connections to the Solr library, I get a AccessControlException:
> access denied to the system property. Here is the modified grant:
>
>
> grant codeBase
> "file:${catalina.base}${file.separator}webapps${file.separator}myapp${fi
> le.separator}WEB-INF${file.separator}lib${file.separator}solr-solrj-7.2.
> 1.jar"
> {
>   permission "java.util.PropertyPermission"
> "solr.httpclient.builder.factory", "read";
>   permission "java.net.SocketPermission" "localhost:8983",
> "resolve,connect";
> };
>
> I have verified that the file exists under the path specified above. I
> tried both ${file.separator} and '/' as the file separator. I also
> tried "jar:/path/to/jar!/-" as the codeBase. No luck.

1) The "grant" clause uses an URL, with '/'.

${file.separator} is used in file paths for a file system: in
java.io.FilePermission


> These grants are added to the end of the stock catalina.policy file
> that ships with Tomcat.
>
> What am I missing, here?

2) Tomcat version=? ;)

See "Troubleshooting" recipe here:

http://tomcat.apache.org/tomcat-8.5-doc/security-manager-howto.html#Troubleshooting

You need to know the actual permission that failed.

You need to know java.security.CodeSource.getLocation() for all
classes in stacktrace up to the failing point (starting from the
nearest AccessController.doPrivileged()).

All those CodeSources should have that permission. If you missed one,
you will fail.


Best regards,
Konstantin Kolinko

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

Re: Connection Pool only evicts closed connections when validator runs?

[Casey Merrill]

Here's my configuration for dropwizard
driverClass: com.mysql.jdbc.Driver
charSet: UTF-8
characterEncoding: UTF-8
  maxWaitForConnection: 1s
  validationQuery: "select case when @@read_only + @@innodb_read_only = 0 then 
1 else (select table_name from information_schema.tables) end as `1`"
  validationQueryTimeout: 3s
  initialSize: 5
  minSize: 5
  maxSize: 5
  checkConnectionWhileIdle: true
  evictionInterval: 10s
  minIdleTime: 1 minute
  checkConnectionOnBorrow: true

And the underlying tomcat-pool config looks like

ConnectionPool[defaultAutoCommit=null; 
defaultReadOnly=null; 
defaultTransactionIsolation=-1; 
defaultCatalog=null; 
driverClassName=com.mysql.jdbc.Driver; 
maxActive=25; 
maxIdle=; 
minIdle=5; i
nitialSize=5; 
maxWait=1000;
 testOnBorrow=true; 
testOnReturn=false; 
timeBetweenEvictionRunsMillis=1; 
numTestsPerEvictionRun=0;
 minEvictableIdleTimeMillis=6;
 testWhileIdle=true;
 testOnConnect=true; 
password=; 
url=**; 
username=*; 
validationQuery=select case when @@read_only + @@innodb_read_only = 0 then 1 
else (select table_name from information_schema.tables) end as `1`; 
validationQueryTimeout=3; 
validatorClassName=null; 
validationInterval=3; 
accessToUnderlyingConnectionAllowed=true; 
removeAbandoned=false;
 removeAbandonedTimeout=60; 
logAbandoned=false;
 connectionProperties=null; 
initSQL=null;
 jdbcInterceptors=null; 
jmxEnabled=true; 
fairQueue=true; 
useEquals=true; 
abandonWhenPercentageFull=0; 
maxAge=0; 
useLock=false; 
dataSource=null; 
dataSourceJNDI=null; 
suspectTimeout=0; 
alternateUsernameAllowed=false; 
commitOnReturn=false; 
rollbackOnReturn=false; 
useDisposableConnectionFacade=true; 
logValidationErrors=false; 
propagateInterruptState=false; 
ignoreExceptionOnPreLoad=false;

On 3/22/18, 2:34 PM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Casey,

On 3/22/18 3:33 PM, Casey Merrill wrote:
> I’m currently using Dropwizard + Jooq and Tomcat jdbc for the 
> connection pool. I’m seeing issues when a connection dies it’s not
>  evicted from the connection pool until the validator runs. While
> I can turn the rate up at which the validator runs its seems odd
> that a closed connection is returned to the pool.
> 
> Example error: (repeats with different queries many times before
> the connection is killed) user`.`login` WHERE `session`.`id` =
> ?]; No operations allowed after connection closed. 
> 
> at org.jooq_3.9.1.MYSQL.debug(Unknown Source) ... Caused by: 
> com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
>
> 
No operations allowed after connection closed. ... Caused by:
> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: 
> Communications link failure The last packet successfully received 
> from the server was 11,618 milliseconds ago. The last packet sent 
> successfully to the server was 5,005 milliseconds ago. ... 1
> common frames omitted Caused by: java.net.SocketTimeoutException:
> Read timed out ... 28 common frames omitted
> 
> I’m able to fix this by getting a reference to the connection and 
> manually setting it to discarded, but his is quite hackey.
> 
> ConnectionListener extends DefaultExecuteListener { ...
> 
> public ConnectionListener() {}
> 
> @Override public void exception(ExecuteContext ctx) { try { if (ctx
> != null && ctx.exception() != null) { //Proceed to check if we
> recieved a DataAccessException if (ctx.exception() instanceof
> DataAccessException) { DataAccessException exception =
> (DataAccessException) ctx.exception();
> 
> //If the error is network related discard the connection if
> (isNetworkError(exception)) { //The underlying ProxyConnection
> which we need to call  setDiscarded is a few levels deep Connection
> conn = ctx.connection(); DefaultConnection dConn =
> (DefaultConnection) conn; SettingsEnabledConnection sConn =
> (SettingsEnabledConnection) dConn; ProviderEnabledConnection pConn
> = (ProviderEnabledConnection) sConn.getDelegate();
> 
> //Get the Proxy connection handler InvocationHandler handler =
> Proxy.getInvocationHandler(pConn.getDelegate());
> 
> //Get the Proxy connection ProxyConnection proxyConnection =
> (ProxyConnection) ((DisposableConnectionFacade)
> handler).getNext();
> 
> //Discard the connection 
> proxyConnection.getConnection().setDiscarded(true); } } } } catch
> (Exception e) { logger.error("ConnectionListener caught unexpected
> error", e); } }
> 

What does your tomcat-pool configuration look like?

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

Granting permission to a single application-supplied JAR

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

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

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

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

My application can can contact Solr without any errors.

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


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

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

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

What am I missing, here?

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

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

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

Re: Connection Pool only evicts closed connections when validator runs?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Casey,

On 3/22/18 3:33 PM, Casey Merrill wrote:
> I’m currently using Dropwizard + Jooq and Tomcat jdbc for the 
> connection pool. I’m seeing issues when a connection dies it’s not
>  evicted from the connection pool until the validator runs. While
> I can turn the rate up at which the validator runs its seems odd
> that a closed connection is returned to the pool.
> 
> Example error: (repeats with different queries many times before
> the connection is killed) user`.`login` WHERE `session`.`id` =
> ?]; No operations allowed after connection closed. 
> 
> at org.jooq_3.9.1.MYSQL.debug(Unknown Source) ... Caused by: 
> com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
>
> 
No operations allowed after connection closed. ... Caused by:
> com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: 
> Communications link failure The last packet successfully received 
> from the server was 11,618 milliseconds ago. The last packet sent 
> successfully to the server was 5,005 milliseconds ago. ... 1
> common frames omitted Caused by: java.net.SocketTimeoutException:
> Read timed out ... 28 common frames omitted
> 
> I’m able to fix this by getting a reference to the connection and 
> manually setting it to discarded, but his is quite hackey.
> 
> ConnectionListener extends DefaultExecuteListener { ...
> 
> public ConnectionListener() {}
> 
> @Override public void exception(ExecuteContext ctx) { try { if (ctx
> != null && ctx.exception() != null) { //Proceed to check if we
> recieved a DataAccessException if (ctx.exception() instanceof
> DataAccessException) { DataAccessException exception =
> (DataAccessException) ctx.exception();
> 
> //If the error is network related discard the connection if
> (isNetworkError(exception)) { //The underlying ProxyConnection
> which we need to call  setDiscarded is a few levels deep Connection
> conn = ctx.connection(); DefaultConnection dConn =
> (DefaultConnection) conn; SettingsEnabledConnection sConn =
> (SettingsEnabledConnection) dConn; ProviderEnabledConnection pConn
> = (ProviderEnabledConnection) sConn.getDelegate();
> 
> //Get the Proxy connection handler InvocationHandler handler =
> Proxy.getInvocationHandler(pConn.getDelegate());
> 
> //Get the Proxy connection ProxyConnection proxyConnection =
> (ProxyConnection) ((DisposableConnectionFacade)
> handler).getNext();
> 
> //Discard the connection 
> proxyConnection.getConnection().setDiscarded(true); } } } } catch
> (Exception e) { logger.error("ConnectionListener caught unexpected
> error", e); } }
> 

What does your tomcat-pool configuration look like?

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq0IUEdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhcuw/+OKuhKA4Wm5NjZFbN
ln5bYs39tDIXa+5/KkduS0/dm815LSbj7NPbRVPgk+oS5TxHmusjnnZ8Otud70B8
u30GzTRCTO+Cke2+qDFqe4hv/mBHhX+tQA2lFQgQfEb1dqhdT7eQEtcperIyxu7K
TnW+CelagSqPFHnl/KE1PRDtsG/MYD4XPNQ9XtQkSKFQd1MstOp6YfVg1uDVi6IH
mTaKOAU0ufZEMCtWfl3uH5hD54mDnq261G43ij8+ce33Xh7WZyq5hj5ZKhLWeuMT
PxxYaf21UI2hlvoL9whjznjNwju8FNRrBBDO3zO/I5zxpsTBTZtOKGA0a5V7n3zW
sYM7BwOx2wHGleGMTf6IncJIWjK/PRIjxwV7BFVkfLmtrF/9VBlHiux6U8/wVVhv
pl7oQ90C3F5op8SZQ2aUGT1wrYEdAB95xoyWSaasvTSnns/fSJFskxkz6WC7XZtS
RWj5HkrNmGnOyyBTFJCflmhbvi6AEGirTjCqmPrqBzWC/8/PTL/IfI5qluzsux6a
5purySIj9LU4wdp8dQNibw0h3ZUJtqYfbKI8rpc2crsTu+jHk8WvF1ppfwW1gsT9
vO0XW3SIc1k9vCAzQBhAQEuDYlcTSF6fKZFGbBPVFuSWCC+pC7Upp/6EWiY5vziN
he7o1AicRZBwR6gRttdzaz7V2+4=
=NAfD
-END PGP SIGNATURE-

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

Connection Pool only evicts closed connections when validator runs?

[Casey Merrill]

I’m currently using Dropwizard + Jooq and Tomcat jdbc for the connection pool.  
I’m seeing issues when a connection dies it’s not evicted from the connection 
pool until the validator runs.  While I can turn the rate up at which the 
validator runs its seems odd that a closed connection is returned to the pool.

Example error: (repeats with different queries many times before the connection 
is killed)
user`.`login` WHERE `session`.`id` = ?]; No operations allowed after 
connection closed.

at org.jooq_3.9.1.MYSQL.debug(Unknown Source) ... Caused by: 
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No 
operations allowed after connection closed. ... Caused by: 
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link 
failure The last packet successfully received from the server was 11,618 
milliseconds ago. The last packet sent successfully to the server was 5,005 
milliseconds ago. ... 1 common frames omitted Caused by: 
java.net.SocketTimeoutException: Read timed out ... 28 common frames omitted


I’m able to fix this by getting a reference to the connection and manually 
setting it to discarded, but his is quite hackey.

ConnectionListener extends DefaultExecuteListener {
...

public ConnectionListener() {}

@Override
public void exception(ExecuteContext ctx) {
try {
if (ctx != null && ctx.exception() != null) {
//Proceed to check if we recieved a DataAccessException
if (ctx.exception() instanceof DataAccessException) {
DataAccessException exception = (DataAccessException) 
ctx.exception();

//If the error is network related discard the connection
if (isNetworkError(exception)) {
//The underlying ProxyConnection which we need to call  
setDiscarded is a few levels deep
Connection conn = ctx.connection();
DefaultConnection dConn = (DefaultConnection) conn;
SettingsEnabledConnection sConn = 
(SettingsEnabledConnection) dConn;
ProviderEnabledConnection pConn = 
(ProviderEnabledConnection) sConn.getDelegate();

//Get the Proxy connection handler
InvocationHandler handler = 
Proxy.getInvocationHandler(pConn.getDelegate());

//Get the Proxy connection
ProxyConnection proxyConnection = (ProxyConnection)
((DisposableConnectionFacade) 
handler).getNext();

//Discard the connection
proxyConnection.getConnection().setDiscarded(true);
}
}
}
} catch (Exception e) {
logger.error("ConnectionListener caught unexpected error", e);
}
}

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 22 March 2018 at 14:49, Mark Thomas  wrote:
> On 22/03/18 07:46, Richard Tearle wrote:
>> On 21 March 2018 at 14:54, Mark Thomas  wrote:

[snip]

> Excellent.
>
> There have been a few moving parts here so I'd like to get some
> clarification on exactly where we are. I know from bitter personal
> experience that it is all too easy to end up using a slightly different
> TLS configuration to the one you think you are using so please could you
> confirm the following.
>
> The connector name can be obtained from the logs. You'll see lines that
> look like this:
>
> 22-Mar-2018 14:39:30.156 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["http-nio-8080"]
> 22-Mar-2018 14:39:30.161 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["https-jsse-nio-8443"]
> 22-Mar-2018 14:39:30.163 INFO [main]
> org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
> ["ajp-nio-8009"]
>
> The part I am using below is the bit in the square brackes. The format
> is ---.
>
> What we have so far is:
>
> 8.0.x, http-nio- (this is always JSSE in 8.0.x), clientAuth="true"
> This works.

Yes this works.

> 8.5.x, http-nio-openssl-, certificateVerification="required"
> This fails intermittently

Its https-openssl-nio- and yes this fails intermittently.

> 8.5.x, http-nio-jsse-,  certificateVerification="required"
> This works

Its https-jsse-nio-, and yes this works

> Is this correct?
>
> Thanks,
>
> Mark
>

Also working is 8.5.x, https-openssl-nio-, certificateVerification="none"

Thanks

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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

Silencing broken pipe I/O exceptions

[Claude Brisson]

Hi all.

I have set up a server-side events mechanism using tomcat (and 
https://github.com/byjg/jquery-sse), and everything is working smoothly.


But each time the server tries to send some data on an SSE channel which 
has just been closed on the client side, even though this exception is 
catched and handled in my SSE servlet, I see this exception in the 
webapp log:


java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[?:1.8.0_101]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) 
~[?:1.8.0_101]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) 
~[?:1.8.0_101]

at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_101]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) 
~[?:1.8.0_101]
at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:134) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:157) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.doWrite(NioEndpoint.java:1241) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.SocketWrapperBase.doWrite(SocketWrapperBase.java:670) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking(SocketWrapperBase.java:607) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.tomcat.util.net.SocketWrapperBase.flush(SocketWrapperBase.java:597) 
~[tomcat-coyote.jar:8.5.9]
at org.apache.coyote.ajp.AjpProcessor.flush(AjpProcessor.java:1096) 
~[tomcat-coyote.jar:8.5.9]
at 
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:279) 
[tomcat-coyote.jar:8.5.9]
at org.apache.coyote.Response.action(Response.java:168) 
[tomcat-coyote.jar:8.5.9]
at 
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:317) 
[catalina.jar:8.5.9]
at 
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:284) 
[catalina.jar:8.5.9]
at 
org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:118) 
[catalina.jar:8.5.9]
at 
info.macias.sse.servlet3.ServletEventTarget.send(ServletEventTarget.java:121) 
[jeasse-servlet3-0.11.1.jar:?]
at 
info.macias.sse.servlet3.ServletEventTarget.send(ServletEventTarget.java:35) 
[jeasse-servlet3-0.11.1.jar:?]
at 
info.macias.sse.EventBroadcast.broadcast(EventBroadcast.java:165) 
[jeasse-common-0.11.1.jar:?]

[...]

With a lot of users this can really pollute the logs. Is there any way 
to silence this stacktrace?


I'm using Java 1.8.0_101 on linux 64 bits, and Tomcat 8.5.9.

Thanks,

  Claude



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

Re: Connection closed error and certificateVerification="required"

[Mark Thomas]

On 22/03/18 07:46, Richard Tearle wrote:
> On 21 March 2018 at 14:54, Mark Thomas  wrote:



>> Please can you test your set-up with 8.5.x, the modified trust store and
>> the same configuration as 8.0.x (NIO, JSSE). That should help us track
>> down where the problem may lie.
>>
>> Thanks,
>>
>> Mark
>>
> 
> I created the PKCS12 as you showed above used my 8.0.x configuration and
> ran my test application for 8 hours without a single connection closed error .

Excellent.

There have been a few moving parts here so I'd like to get some
clarification on exactly where we are. I know from bitter personal
experience that it is all too easy to end up using a slightly different
TLS configuration to the one you think you are using so please could you
confirm the following.

The connector name can be obtained from the logs. You'll see lines that
look like this:

22-Mar-2018 14:39:30.156 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["http-nio-8080"]
22-Mar-2018 14:39:30.161 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["https-jsse-nio-8443"]
22-Mar-2018 14:39:30.163 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["ajp-nio-8009"]

The part I am using below is the bit in the square brackes. The format
is ---.

What we have so far is:

8.0.x, http-nio- (this is always JSSE in 8.0.x), clientAuth="true"
This works.

8.5.x, http-nio-openssl-, certificateVerification="required"
This fails intermittently

8.5.x, http-nio-jsse-,  certificateVerification="required"
This works

Is this correct?

Thanks,

Mark

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

Re: mod_jk: sessions connecting although worker is oset to DIS

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 3/22/18 10:11 AM, Rainer Jung wrote:
> Am 22.03.2018 um 15:07 schrieb Rainer Jung:
>> Am 22.03.2018 um 11:58 schrieb Martin Knoblauch:
>>> Hi,
>>> 
>>> we have this annoying problem that although Tomcat workers are
>>> set to DIS state in mod_jk, there are new connections being
>>> opened. This prevents us from "idle down" Tomcats in a timely
>>> fashion. This hurts when a restart is needed. While our empathy
>>> for human clients is pretty limited, we care a lot about our
>>> automated workloads :-)
>>> 
>>> Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer,
>>> sticky sessions -> a bunch of Tomcat 7 (yes I know. Oldie but
>>> Goldie :-) workers.
>>> 
>>> As far as I understand, the problem arises with HTTP(S)
>>> clients that cache the session cookies. If such a client tries
>>> to open a new connection to the backend, the old cookie passes
>>> to a DIS worker even if it is no longer valid on the Tomcat
>>> side. Tomcat/Application then sees that the cookie is not valid
>>> and doles out a new cookie which then allows the new 
>>> connection to be established.
>>> 
>>> My idea is now to delete existing session cookies for certain
>>> request pattern on the Apache frontend. If it works, it should
>>> force mod_jk to a new ACT Tomcat. But I am nor really fond of
>>> messing with the Apache configuration, as the reason lies on
>>> the mod_jk/Tomcat side.
>>> 
>>> So if anybody has another suggestion I would love to hear it.
>>> Before I forget, changing the application itself is not an
>>> option.
>> 
>> Either your idea, or - if those unwanted new request flows start
>> with a specific URL, e.g. a login - mark those URLs specifically
>> as not using the cookie. If you are using a
>> uriworkermap.properties, look for "sticky_ignore" below 
>> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#R
ule%20extensions.
>>
>> 
If you are instead using JkMount style maps, look for JK_STICKY_IGNORE
>> in 
>> http://tomcat.apache.org/connectors-doc/reference/apache.html#Advance
d%20Environment%20Variables.
>>
>>
>>
>> 
Whenever you set the Apache environment variable JK_STICKY_IGNORE
>> during a request execution, mod_jk will ignore the cookie and 
>> distribute like if it didn't see one. Such environment variables 
>> (different from Unix environment variables) can be set e.g. with 
>> mod_setenvif based on request properties and also with
>> mod_rewrite as a [E=] side effect.
>> 
>> But that would only help if you can describe request properties
>> that alow you to decide - based on the request alone - whether
>> the cookie needs to be ignored or not. You can use any request
>> info including all headers for that decision. What is not
>> possible, is to first check, whether the session is valid.
>> 
>> You could also write a filter that checks the cookie for validity
>> in Tomcat and if it is not valid, reply with a self-referential
>> redirect including a Set-Cookie-Header that deletes the cookie.
>> This filter should be written, such that it does not itself
>> create a new session.
> 
> Plus I vaguely remember Chris (Schultz) has written such code that
> yould be used pretty generic. Chris, am I right? If I am not
> mistaken, it is actually here:
> 
> http://home.apache.org/~schultz/lbdf/

Yup, that's it. I think the Valve might be better because it can
intercept the request before any potential authentication occurs.

The Filter may be easier to get into a Tomcat 7.0
environment/application, though.

There's coverage of the theory and pretty pictures starting on slide
41 here:
http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20T
omcat%20with%20mod_jk.pdf

I'm using the Filter in production and WOW does it make a difference.
We used to have to wait for almost a day for users to drain from a
node and now it's maybe 30-90 minutes.

I have not used the Valve in production because we are on Tomcat 8
(moving to 8.5) and neither version has the Valve in it, yet.

Martin, please take the valve for a test-drive if you can and let me
know how it goes. It it works for you I'll absolutely back-port it to
Tomcat 8.5.x and possibly 8.0.x and 7.0.x.

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqzvZkdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFj/5xAAtIb5XbXQj5YGMtVl
ZUjq0m2gfZ9C/p5Xtyumd1u5gXLrKLVwhxb9Zx4QF6pSOjvKY2mrbbPiLnILqn/w
B2izrvi8Xr8nsIInAcrKV6jwWuQT9rJVLwG7PfkdK6UXmXSxq+HcqW78zpD9y11+
O1QM0PijYDvCbDFY9JME6PJ2EuxNFNLllPsmrJ/Ad/UTOLnWBLCp0IgrE0EP6uUg
FAJVS+6EsItcuOL+OmgFnqVkJHkWFeRHC4mL4l9P/RCvgA6g2Hs2vW5uanXKORI4
6fiikmWrDdvoH9oEr01kOFaWGZuIjK6ASqenTsRY3uVIoLAkcrYMR/QCM0dyjq79
eVbhsGAWYACYo9Ah+2qa8kfeW2SzB/t2FOcrEn+VwfQlec7V8sOwvlxhsBTzxy9c
0eyCNi3g65y+oolSoYbap06mr6/8xIevoufhCDuRRFWsCOiDaTDcq5C1+nomWKts

Re: mod_jk: sessions connecting although worker is oset to DIS

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 3/22/18 6:58 AM, Martin Knoblauch wrote:
> we have this annoying problem that although Tomcat workers are set
> to DIS state in mod_jk, there are new connections being opened.
> This prevents us from "idle down" Tomcats in a timely fashion. This
> hurts when a restart is needed. While our empathy for human clients
> is pretty limited, we care a lot about our automated workloads :-)
> 
> Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer,
> sticky sessions -> a bunch of Tomcat 7 (yes I know. Oldie but
> Goldie :-) workers.
> 
> As far as I understand, the problem arises with HTTP(S) clients
> that cache the session cookies. If such a client tries to open a
> new connection to the backend, the old cookie passes to a DIS
> worker even if it is no longer valid on the Tomcat side.
> Tomcat/Application then sees that the cookie is not valid and doles
> out a new cookie which then allows the new connection to be
> established.
> 
> My idea is now to delete existing session cookies for certain
> request pattern on the Apache frontend. If it works, it should
> force mod_jk to a new ACT Tomcat. But I am nor really fond of
> messing with the Apache configuration, as the reason lies on the
> mod_jk/Tomcat side.
> 
> So if anybody has another suggestion I would love to hear it.
> Before I forget, changing the application itself is not an option.

My suggestion is to use the LoadBalancerDrainingValve[1][2]. It was
written for this exact purpose. It's currently only available in
Tomcat 9.0.x, but you should be able to use it for previous Tomcat
versions as the Valve/Request/Response interfaces shouldn't have
changed in any incompatible ways between those versions.

Hope that helps,
- -chris

[1]
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Load_Balancer
_Draining_Valve
[2]
https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/valves/
LoadBalancerDrainingValve.html
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqzurodHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjpfBAAyuM5kfF/ukIcnJjd
NRoxyMIZtuKrVOht8tXn3or5ONye71Q/iZ3vd8UVlbrGurHWdi3ADH2n7Cvss8oX
+02XSRzkW4EAmtu0Ailpc5PBDW0j3ASZTqnkymtNyBjQ8MDQkYtizPql51SU6tOp
CaG4RP8TlEP91qI+nldCWMT+YbnAmAlEHvGOAJ1MzEKjmi14AfT8e4guBu2dfRCt
QXderPV9imVveBmP53Z3WklPDCRMfEmGCdUf25Be/5ZnUGDZ5wmAZl3l/HLnUBAD
tOwEBBCsm2OeVpvbbWj815ngnB/NkCC6gleePGN8J3HysJY+fnmPUl6Cw0t8jV3T
CbqUlXJfH54QRvzie+1eGXGK1iwX3++icfecusC2Rea/9of+s65OVCFoJVkHj1qY
3T/tWZm0dbqLqAbadE7/2ihrOPBg3VnW/vdD+/lKXBEv/ECH/9nYNY3OkY6mJ3KS
ptaKCdojTh1KCqxqilxfYEBMc9YFh1AoW/GYoF41mqFKRWc0CMLakCuNrm2vT8L0
u+KiFo8bPnuJ9Sw4jjKS2a52yp1jcJCjXnsDyO3vn7t3MNvyfygcbQR6Jftdq441
imwYVdwJTwULiR45cL6/AtGDSgKr1L4LhtcyhCzfxBRJh24W8u3dataH0loEVCup
uAZ1f50984WWHJMJYmI6UrA7lKI=
=8fI4
-END PGP SIGNATURE-

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

Re: mod_jk: sessions connecting although worker is oset to DIS

[Rainer Jung]

Am 22.03.2018 um 15:07 schrieb Rainer Jung:

Am 22.03.2018 um 11:58 schrieb Martin Knoblauch:

Hi,

  we have this annoying problem that although Tomcat workers are set 
to DIS

state in mod_jk, there are new connections being opened. This prevents us
from "idle down" Tomcats in a timely fashion. This hurts when a 
restart is

needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)

Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) 
workers.


  As far as I understand, the problem arises with HTTP(S) clients that 
cache
the session cookies. If such a client tries to open a new connection 
to the

backend, the old cookie passes to a DIS worker even if it is no longer
valid on the Tomcat side. Tomcat/Application then sees that the cookie is
not valid and doles out a new cookie which then allows the new connection
to be established.

  My idea is now to delete existing session cookies for certain request
pattern on the Apache frontend. If it works, it should force mod_jk to a
new ACT Tomcat. But I am nor really fond of messing with the Apache
configuration, as the reason lies on the mod_jk/Tomcat side.

  So if anybody has another suggestion I would love to hear it. Before I
forget, changing the application itself is not an option.


Either your idea, or - if those unwanted new request flows start with a 
specific URL, e.g. a login - mark those URLs specifically as not using 
the cookie. If you are using a uriworkermap.properties, look for 
"sticky_ignore" below 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions. 
If you are instead using JkMount style maps, look for JK_STICKY_IGNORE 
in 
http://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables. 



Whenever you set the Apache environment variable JK_STICKY_IGNORE during 
a request execution, mod_jk will ignore the cookie and distribute like 
if it didn't see one. Such environment variables (different from Unix 
environment variables) can be set e.g. with mod_setenvif based on 
request properties and also with mod_rewrite as a [E=] side effect.


But that would only help if you can describe request properties that 
alow you to decide - based on the request alone - whether the cookie 
needs to be ignored or not. You can use any request info including all 
headers for that decision. What is not possible, is to first check, 
whether the session is valid.


You could also write a filter that checks the cookie for validity in 
Tomcat and if it is not valid, reply with a self-referential redirect 
including a Set-Cookie-Header that deletes the cookie. This filter 
should be written, such that it does not itself create a new session.


Plus I vaguely remember Chris (Schultz) has written such code that yould 
be used pretty generic. Chris, am I right? If I am not mistaken, it is 
actually here:


http://home.apache.org/~schultz/lbdf/

Regards,

Rainer

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

Re: mod_jk: sessions connecting although worker is oset to DIS

[Rainer Jung]

Am 22.03.2018 um 11:58 schrieb Martin Knoblauch:

Hi,

  we have this annoying problem that although Tomcat workers are set to DIS
state in mod_jk, there are new connections being opened. This prevents us
from "idle down" Tomcats in a timely fashion. This hurts when a restart is
needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)

Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) workers.

  As far as I understand, the problem arises with HTTP(S) clients that cache
the session cookies. If such a client tries to open a new connection to the
backend, the old cookie passes to a DIS worker even if it is no longer
valid on the Tomcat side. Tomcat/Application then sees that the cookie is
not valid and doles out a new cookie which then allows the new connection
to be established.

  My idea is now to delete existing session cookies for certain request
pattern on the Apache frontend. If it works, it should force mod_jk to a
new ACT Tomcat. But I am nor really fond of messing with the Apache
configuration, as the reason lies on the mod_jk/Tomcat side.

  So if anybody has another suggestion I would love to hear it. Before I
forget, changing the application itself is not an option.


Either your idea, or - if those unwanted new request flows start with a 
specific URL, e.g. a login - mark those URLs specifically as not using 
the cookie. If you are using a uriworkermap.properties, look for 
"sticky_ignore" below 
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Rule%20extensions. 
If you are instead using JkMount style maps, look for JK_STICKY_IGNORE 
in 
http://tomcat.apache.org/connectors-doc/reference/apache.html#Advanced%20Environment%20Variables.


Whenever you set the Apache environment variable JK_STICKY_IGNORE during 
a request execution, mod_jk will ignore the cookie and distribute like 
if it didn't see one. Such environment variables (different from Unix 
environment variables) can be set e.g. with mod_setenvif based on 
request properties and also with mod_rewrite as a [E=] side effect.


But that would only help if you can describe request properties that 
alow you to decide - based on the request alone - whether the cookie 
needs to be ignored or not. You can use any request info including all 
headers for that decision. What is not possible, is to first check, 
whether the session is valid.


You could also write a filter that checks the cookie for validity in 
Tomcat and if it is not valid, reply with a self-referential redirect 
including a Set-Cookie-Header that deletes the cookie. This filter 
should be written, such that it does not itself create a new session.


HTH,

Rainer



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

mod_jk: sessions connecting although worker is oset to DIS

[Martin Knoblauch]

Hi,

 we have this annoying problem that although Tomcat workers are set to DIS
state in mod_jk, there are new connections being opened. This prevents us
from "idle down" Tomcats in a timely fashion. This hurts when a restart is
needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)

Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) workers.

 As far as I understand, the problem arises with HTTP(S) clients that cache
the session cookies. If such a client tries to open a new connection to the
backend, the old cookie passes to a DIS worker even if it is no longer
valid on the Tomcat side. Tomcat/Application then sees that the cookie is
not valid and doles out a new cookie which then allows the new connection
to be established.

 My idea is now to delete existing session cookies for certain request
pattern on the Apache frontend. If it works, it should force mod_jk to a
new ACT Tomcat. But I am nor really fond of messing with the Apache
configuration, as the reason lies on the mod_jk/Tomcat side.

 So if anybody has another suggestion I would love to hear it. Before I
forget, changing the application itself is not an option.

TIA
Martin
-- 
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 21 March 2018 at 14:54, Mark Thomas  wrote:
>
>
> Progress.
>
> Tomcat 8.0.x is more relaxed about the content of PKCS12 trust stores
> then 8.5.x because of a change[1] made so that the effectiveness of the
> certificateVerificationDepth configuration attribute did not depend on
> the presence of a certificate revocation list.
>
> The PKCS12 store the scripts you provided creates includes the private
> key of the trusted certificate. This is ... unusual. 8.5.x skips this
> cert as it does not expect a trusted cert to include the private key.
>
> I've tried various ways to get openssl to create a PKCS12 file without
> the private key but with the certificate without success. In the end I
> used keytool to do this and that worked. Something along these lines:
>
> keytool -storetype pkcs12 -importcert -file ca-cert.pem \
> -keystore ca-truststore.p12
>
> With the modified trust store 8.5.x started with the same configuration
> as 8.0.x.
>
> Please can you test your set-up with 8.5.x, the modified trust store and
> the same configuration as 8.0.x (NIO, JSSE). That should help us track
> down where the problem may lie.
>
> Thanks,
>
> Mark
>

I created the PKCS12 as you showed above used my 8.0.x configuration and
ran my test application for 8 hours without a single connection closed error .

-- 
Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended recipient of this email you must: (i) not 
disclose, copy or distribute its contents to any other person nor use its 
contents in any way or you may be acting unlawfully;  (ii) contact 
Northgate Public Services immediately on +44(0)1442 768445 quoting the name 
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that 
no viruses are contained in this email, but does not accept any 
responsibility once this email has been transmitted.  You should scan 
attachments (if any) for viruses.

Northgate Public Services (UK) Limited, registered in England and Wales 
under number 00968498 with a registered address of Peoplebuilding 2, 
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2 
4NW.  Rave Technologies (India) Pvt Limited, registered in India under 
number 117068 with a registered address of 2nd Floor, Ballard House, Adi 
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 41.

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