Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <504636AC.7050207@rushtone.com>
Date: Tue, 04 Sep 2012 13:13:16 -0400
From: "David A. Rush" <david@rushtone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: Login Delay
References: <50401AFC.8090209@rushtone.com>
 <73183a8d35324ab4f6bddebc40a85307@www.internetallee.de>
 <5040B307.5070209@rushtone.com>
In-Reply-To: <5040B307.5070209@rushtone.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

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