David,
while you should still look for a firewall or similar thing, that
invalidates your network connections to the database, you might want to
mitigate the problems by extending the configuration for your database
connection as shown below:
Am 04.09.2012 22:03, schrieb David A. Rush:
Felix:
Windows seems to be conspiring against my efforts to get a thread
dump.
For configuration, in my webapp's context config file:
Under <Context>:
<Resource name="jdbc/myoracle"
auth="Container"
type="javax.sql.DataSource"
description="Connection to the database"
driverClassName="oracle.jdbc.OracleDriver"
url="[DB_URL]"
username="[DB_USERNAME]" password="[DB_PASS]"
maxActive="20" maxIdle="10" maxWait="-1" />
As shown in http://commons.apache.org/dbcp/configuration.html you can
set the following parameters:
* validationQuery ( for oracle set it to "select 1 from dual" )
* testOnBorrow ( set it to true and your login will succeed, even if
it will still take 20 seconds )
* testWhileIdle ( set it to true, to test your connection while it is
idle. By using this configuration you might be able to reset the
firewall counter, which is probably your real problem )
* timeBetweenEvictionRunsMillis ( set it to positive value quite below
your 90 minute interval, which kills the database connections )
* minEvictableIdleTimeMillis ( might also have to be adjusted )
Hope this helps
Felix
Under a CombinedRealm (that's under <Context>):
<Realm className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/myoracle"
localDataSource="true"
digest="SHA-384"
digestEncoding="UTF-8"
userTable="[USERS_TABLE]" userNameCol="USER_NAME"
userCredCol="PASSWORD_HASHED"
userRoleTable="[USERS_ROLES_TABLE]"
roleNameCol="ROLE_NAME"
/>
When doing a deployment, I have an ant task that replaces the
[THINGS_IN_BRACKETS] with real values.
We're using a CombinedRealm for historical reasons, but there's no
other Realm inside it that isn't commented out.
David
On 2012-09-04 15:12, Felix Schumacher wrote:
Am 04.09.2012 20:30, schrieb David A. Rush:
Felix:
Well, it still takes over an hour of "cold" time (no logins) before
I can reproduce the problem.
Ok, I misread it.
More info.... in logging.2012-09.04.log I found:
Sep 4, 2012 12:03:57 PM org.apache.catalina.realm.DataSourceRealm
getPassword
SEVERE: Exception retrieving password for "david"
Sep 4, 2012 12:03:57 PM org.apache.catalina.realm.DataSourceRealm
close
SEVERE: Exception closing database connection
java.sql.SQLException: Already closed.
at
org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:114)
Looks like this exception may be causing the authentication process
to fail, even when the username and password are good.
You still haven't shown us your configuration. You could try to
setup the datasource close all connections.
Felix
I'll see if I can get a thread dump....
David
On 2012-09-04 14:25, Felix Schumacher wrote:
Am 04.09.2012 19:13, schrieb David A. Rush:
Well, drat. I swapped the application over to using a
DataSourceRealm (instead of JDBCRealm) to support the JDBC
connection that Tomcat's using for authentication, but it doesn't
seem to have helped. Seems to have made it a bit worse.
Originally when using a JDBCRealm, after some time of inactivity
(no one logging in for 90 minutes or more) a "cold" login would
always take about 20 seconds and then succeed. Subsequent "warm"
logins were very fast.
Now, with DataSourceRealm, a "cold" login (no other logins over
the past 90 minutes or more) takes 20 seconds to FAIL. Subsequent
login (same username/password) succeeds.
Actually it is a good thing, that you can produce it that fast :)
Now you can
* do stack traces in that 20 seconds interval
(http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F)
* enable logging for the realms
and you could give more information about your setup. Tomcat
version, DataSource and Realm setup (without passwords).
Regards
Felix
David
On 2012-08-31 08:50, David A. Rush wrote:
Felix:
Aha, you're suggesting a firewall issue, which I've been
speculating on. Thanks for confirmation about the persistent
connection that JDBCRealm tries to keep.
I'll look into the DataSourceRealm. Thanks for the tip.
David
On 2012-08-31 03:16, Felix Schumacher wrote:
Am 31.08.2012 04:01, schrieb David A. Rush:
We've got two different machines (both Windows Server
something)
running Tomcat 7.0.22, and each running a webapp that uses
user
authentication. We're using a couple of different schemes
(LDAP and
database using JDBCRealm with hashed pwords, just database
with hashed
pwords).
When no one has logged in for a while (90 minutes seems to do
the
trick), the next login takes almost exactly 40 seconds on one
host and
almost exactly 20 seconds on the other one.
You might want to check for a firewall between tomcat and your
database.
It could drop packets of a database session after a certain
period of inactivity.
JDBCRealm keeps its (one and only) connection open and closes
it only in case of
an exception (which might be a timeout).
You should really consider using DataSourceRealm
(http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#DataSourceRealm)
instead.
It will close connections (give it back to a pool) after usage
and can be
configured to check the connection before it is used for
authentication/authorization.
Hitting a page in one of the webapps that hits the database
for
application data, without requiring login, works fast even if
it's
been idle for hours. But then try to login and I get a 40
second
delay after whacking the "Log in" button on the login form.
Looking
at it in more detail, the host and app with a 40-second delay
has two
JDBCRealms configured, both inside of a combined realm.
You haven't told us, how you configured your application
database connections,
so we can only guess.
If you are using standard tomcat connection pooling, you can
transfer that
configuration to a pool, that can be used by the mentioned
DataSourceRealm.
Regards
Felix
Are we seeing a 20-second delay in getting authentication via
JDBCRealm?
Suggestions on troubleshooting this?
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
