logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Stauffer <jstau...@spscommerce.com>
Subject RE: Strange behaviour with JDBCAppender -- long time lags before control returns to code
Date Mon, 19 Jul 2004 12:05:01 GMT
Can you profile the code to determine what is taking so long?

James Stauffer


-----Original Message-----
From: Donald Larmee [mailto:dlarmee@alterthought.com] 
Sent: Saturday, July 17, 2004 12:08 PM
To: 'Log4J Users List'
Subject: RE: Strange behaviour with JDBCAppender -- long time lags before
control returns to code


I would attach the JDBCAppender to an AsyncAppender. You would then log to
the AsyncAppender which would buffer the event and return control
immediately to your application.... As its name implies, the AsyncAppender
then logs the event asynchronously from the thread of control that submitted
the request.  The AsyncAppender has attributes that allow you control the
various aspects of how/when it flushes its internal queue of buffered
requests. 

Hope it helps.

-don

-----Original Message-----
From: Frank Burns [mailto:frankburns@the-hub.demon.co.uk] 
Sent: Saturday, July 17, 2004 7:45 AM
To: Log4J Users List
Subject: Re: Strange behaviour with JDBCAppender -- long time lags before
control returns to code

Hi James,

As you suggested, I've written some JDBC code to insert a record and it does
NOT hang. The response is very fast.

So it seems like it's a JDBCAppender-related thing only.

Any ideas on what might be happening here or how I can investigate further?

( I urgently need to solve this -- it's running on a live production system.
)-:

Frank.

----- Original Message -----
From: "James Stauffer" <jstauffe@spscommerce.com>
To: <log4j-user@jakarta.apache.org>
Sent: Thursday, July 15, 2004 9:29 PM
Subject: RE: Strange behaviour with JDBCAppender -- long time lags before
control returns to code


> If you write your own JDBC code to insert a record does it hang that 
> long?
>
> -----Original Message-----
> From: Frank Burns [mailto:frankburns@the-hub.demon.co.uk]
> Sent: Thursday, July 15, 2004 9:54 AM
> To: log4j-user@jakarta.apache.org
> Subject: Strange behaviour with JDBCAppender -- long time lags before 
> control returns to code
>
>
> Hi,
>
> Can anyone shed some light on what might be happening here?
>
> I was using the JDBCAppender that comes with log4j 1.2.8 to perform
logging
> to database tables.
>
> This worked well except if no logging events occurred for some time 
> then
the
> database logging ceased. I believe this was because the connection to 
> the database was timing out.
>
> In an attempt to cure this I used the JDBCAppender from Thomas Fenner 
> and updated by Danko Mannhaupt -- see .
>
> This now works fine for my app running on my development linux
installation,
> where it is logging to a mySQL database located on the same machine.
>
> However, on the live linux implementation, where the database is on a 
> different server, when no events occur for some time, the logging to 
> the database still takes place immediately (the timestamp logged in 
> the
database
> shows this) BUT it takes up to FIFTEEN MINUTES for control to return 
> to
the
> code following this logging statement
>
>     successfulLoginLogger.info(username.toUpperCase() + " logged 
> in.");
>
> Any ideas what's happening and how to solve it?
>
> Thanks.
>
> Frank Burns.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

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