Caldarale, Charles R wrote:
From: Brian Braun [mailto:brianbr...@gmail.com]
Subject: Re: [OT] Best way to log requests from a servlet and to a database?
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?
I think it would be cheaper for you to just spool the excess logging objects to
your own local disk if the in-memory queue reaches some predetermined limit.
However, if your DB server really can't keep up, you'll need some strategy to
just discard log entries or reject requests until it can, even if you overflow
to local disk.
Not being myself a Java specialist, and given the expressed requirements and transactions
volume, my instinctive reaction would be to just write the log entries as some kind of
text line into a local disk file, and then process that disk file with a totally separate
program, to create the required log entries in the back-end database.
The idea is to make the action of writing the log entries as fast, simple and lightweight
as possible for the real-time process (the webapp), and leave the brunt of the work to a
separate process which can run at a more leisurely pace, deal with access contention to
the back-end db, only run at specified intervals and times etc.
The local disk file can be "rotated" regularly, to prevent each file instance from
becoming too large, and the process which reads the files could only process the rotated
ones (to avoid contention with the webapp on the current logfile).
Such a design would provide a kind of buffering automatically, with a predictable time and
memory overhead for the webapp writing each log entry to the local logfile.
Considering the disk capacities available nowadays, I believe that it would be quite
unlikely that one would ever reach the point where the logfiles volume would get too large
to fit.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
