tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: Login Delay
Date Wed, 05 Sep 2012 06:50:43 GMT
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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


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


Mime
View raw message