tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Braun <>
Subject Re: [OT] Best way to log requests from a servlet and to a database?
Date Sun, 27 Jan 2013 04:29:45 GMT
Hi chuck,

I finally found this, implemented it and works great!

However, if I get significantly more requests, this may not be enough
because MySQL will get slower and the queue will get full. I think I could
start using this queue, and if it gets full I could failover to Amazons
Queue service. What do you think?

On Sat, Jan 26, 2013 at 9:06 AM, Caldarale, Charles R <> wrote:

> > From: Brian Braun []
> > Subject: Re: Best way to log requests from a servlet and to a database?
> (Marking this off-topic, since it has nothing to do with Tomcat.)
> > My current method can hold about 3000 threads until memory collapses. I'm
> > looking to replace this method with something more efficient in terms of
> > RAM usage. Something like a buffer, where each item needs far less RAM
> than
> > the kind of threads I'm creating now. Then when it gets full I will use
> > Amazon's queue as a failover mechanism.Any ideas?  :-)
> Instead of using one additional thread per log entry, use just _one_
> additional logging service thread.  When each request processing thread has
> prepared the object representing the log entry to be made, that object
> should be placed on a synchronized FIFO queue.  If the logging service
> thread is idle, the request processing thread should mark the logging
> service thread as active and wake it up before unlocking the queue; if the
> logging service thread is already active, the request processing thread
> just unlocks the queue after enqueuing its entry.  When the logging service
> thread wakes up, it must lock the queue, remove _all_ the entries currently
> on the queue, unlock the queue, and send all the removed entries to the
> database in as few calls as possible.  Once that's done, the logging
> service thread relocks the queue, checks for any new arrivals and repeats
> as needed.  If no new arrivals, it marks itself as inactive, and goes to
> sleep on the queue.  No polling required.
> You can use the standard synchronization methods (wait(), notify(), etc.)
> for all this (safest), or the newer but easier to abuse
> java.util.concurrent operations.
>  - Chuck
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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