tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph <wutong...@gmail.com>
Subject Re: Login Delay
Date Tue, 04 Sep 2012 21:03:59 GMT
do you think that maxwait should be tuned? and you can also monitor live
session in oracle by query db,what does it tell you (both before 20s and
after 20s)? and by using oracle 11g driver(use ojdbcXX_g.jar with log
enabled), you can turn on logging for driver and have a look when does the
request of opening connection and closing connection happened ? is that
opening and closing after 20s ? or right after hit of login button ? if
right after hitting button,then the problem might be configuration of pool
and db session handling,if after 20s,then put
Thread.getcurrentthread.printstack (something like this) in code befor code
hitting db,so that you know what is  the code doing at that time.

here is the link for how to turn on logging fo ojdbc
http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm#CIAIDFIC

On Wed, Sep 5, 2012 at 8:03 AM, David A. Rush <david@rushtone.com> wrote:

> 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" />
>
> 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<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<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<users-unsubscribe@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<users-unsubscribe@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Never trust your computer.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message