Shoving those parameters into the Resource element seems to have done
the trick. It'll take a while to get a few verification tests done
(what with the 90 minute idle requirement and pesky users actually USING
the app), but it looks promising so far.
Thanks, Felix.
David
On 2012-09-05 08:29,
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 connect
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
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
Felix:
Windows seems to be conspiring against my efforts to get a thread dump.
For configuration, in my webapp's context config file:
Under :
Under a CombinedRealm (that's under ):
userTable="[USERS_TABLE]" userNameCol="USER_NAME"
userCredCol="PASSWORD_HASHED"
us
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
getPasswo
Felix:
Well, it still takes over an hour of "cold" time (no logins) before I
can reproduce the problem.
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, 201
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
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 in
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 0
Joseph:
I've bumped up application logging in a couple of places as early in the
login process as I can, but nothing's shown up. The delay occurs
between the submit on the login page but before any more of the
application's code gets run.
I'm looking into enabling logging on my Oracle JDBC
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 datab
probably a log level FINE or DEBUG might help if the app had any,and you
might be able to turn on debug level log with your JDBC driver,so that you
could capture SQLs.after all this ,you got lots of info with
timestamps,those might help you find the problem.
it might have a SQL performance problem
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
14 matches
Mail list logo