Hi,

PROBLEM SOLVED (sort of)

It was because I failed to close the database connections. Well, I closed
them too late.

I had things set up so that when a user logs on, a "service" object is
created for them. The Action servlet calls the service and receive
business objects. The service talks to the database and creates
business objects to give back to the action servlets. I had been
fetching a new connection from the pool upon initialization of the
service, and returning the connection to the pool when the
user logged out and the service object was destroyed. 

When I change my code so that the "service" creates a new db
connection each time it interacts with the db, and returns the connection 
in the same method, the server no longer hangs. So I guess I will have to
change it to "one connection per query" instead of "one connection per
user". 

Does this sound right? 

Thanks all!

Heather Buch

On Tue, 6 Jan 2004, Anthony Martin wrote:

> I've had something like that happen when I call
> getDataSource(request).getConnection() and forget to close them.  After a
> finite number of requests, the server appears to hang.  Actually, depending
> on the settings, it will timeout.  But how you handle the exception could
> prevent it from being properly reported.
> 
> 
> On 1/6/04 11:38 AM, in article
> [EMAIL PROTECTED], "Heather Marie
> Buch" <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Manfred Wolff wrote:
> > 
> >> Heather.
> >> 
> >> Have you studied the tomcat logs?
> > 
> > Yes, I have. This is the only thing that is remotely interesting.
> > In localhost_log.2004-01-06.txt I get this:
> > 
> > 2004-01-06 03:38:41 action: null
> > 2004-01-06 03:40:08 action: null
> > 2004-01-06 03:40:12 action: null
> > 2004-01-06 03:40:14 action: null
> > 2004-01-06 03:40:16 action: null
> > 2004-01-06 03:40:18 action: null
> > 2004-01-06 03:40:21 action: null
> > 2004-01-06 03:40:23 action: null
> > 
> > (corresponding to the 8 times I try to log in). I don't really know where it
> > is
> > coming from. I would like to know what is generating the above, so I could to
> > in and modify the logging
> > statements to produce a bit more detail!
> > 
> > I also have log4j statements in my own code and have been testing this. But I
> > can't generate any error or anything beyond the normal output, 8 times.
> > 
> > What is interesting is that it always fails on the 9th try. I don't think it
> > is
> > a matter of seconds either. I have tested over a longer period (10 minutes),
> > but
> > it still gives me 8 requests before it hangs.
> > 
> > And Geeta Ramani - thanks. I will take another look at the jdbc stuff!
> > 
> > Best,
> > 
> > Heather Buch
> > 
> > 
> > 
> >> 
> >> Manfred Wolff
> >> 
> >> Heather Marie Buch wrote:
> >> 
> >>> Hi all,
> >>> 
> >>> If I submit the same page more than 8 times, my server dies and I have to
> >>> restart. For example, the first 8 times I enter the wrong password, struts
> >>> will simply return me to my original form with an error message. However,
> >>> the 9th time - the server hangs.
> >>> 
> >>> This also occurs if I enter the correct password, then press the
> >>> "back" button and return to the original login screen and submit again. I
> >>> can only repeat this 8 times. The server hangs on the 9th try.
> >>> 
> >>> I am using:
> >>> 
> >>> tomcat 4.1.12
> >>> httpd 2.0.43
> >>> mysql 3.23.53
> >>> struts 1.1
> >>> 
> >>> I am not even sure if this is a struts problem. I suspect it is because I
> >>> tried that back  button trick with a plain old servlet, and I was able to
> >>> do it more than 9 times.
> >>> 
> >>> Any help would be greatly appreciated! My boss wants users to be able to
> >>> try passwords more than 9 times!
> >>> 
> >>> Thanks,
> >>> 
> >>> Heather Buch
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to