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]
