Pid wrote:
Peter Crowther wrote:
From: David Kerber [mailto:dcker...@verizon.net]
The synchronized section doesn't do a whole lot, so it
doesn't take long to process.
Indeed. So take a thread dump and see what's happening before making *any*
changes to this key part.
My question is, what kinds of operations need to be
synchronized? All I do is decrypt the data from the POST,
send a small
acknowledgement response back to the site, and write the line
to the log
file. Does that sound like something that would need to be
synchronized? If not, pulling that out would be a really easy test to
see if it helps my performance issue.
Decrypt: parallel.
Send ack: parallel.
Increment counters: synced.
Write to log file: synced (or you'll have some very odd stuff happening).
Would a single thread executor service alongside an atomic counter be
useful here? (my concurrency knowledge isn't so hot).
I'm not sure if a) this is suitable or b) if it would solve the problem,
as you may still end up with a delayed write to the log during peaky
periods - at least they'd be in the right order though.
The order is the only thing that's important; a short delay (up to a few
tens of seconds) is no problem.
Also, right now I'm doing a .flush() after the .write() to the log
file. Is that usually necessary, other than to avoid losing data lines
in case of a system failure? A few lost lines, while not desirable,
isn't too big of a problem in this particular application. How would a
.flush() affect the speed of returning from a synchronized .write()?
You could be dumping runnables into it during the post which would
return quickly for the next request. You'd have to consider
You lost me here...
exec.shutdown() & exec.shutdownNow() in your servlet destroy to ensure
you didn't drop data during a shutdown or app restart
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
