Pid wrote:
> Peter Crowther wrote:
>   
>>> From: David Kerber [mailto:dckerber@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org