tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David A. Rush" <da...@rushtone.com>
Subject Re: Login Delay
Date Wed, 05 Sep 2012 12:29:57 GMT
Felix:

Thanks for the suggestions, they look promising.  But are these 
parameters for the Resource element?  I'll give that a shot....

David
On 2012-09-05 02:50, Felix Schumacher wrote:
> 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
>
>
>


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


Mime
View raw message