tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <>
Subject Re: Performance with many small requests
Date Fri, 08 May 2009 11:39:23 GMT
Mark Thomas wrote:
> Xie Xiaodong wrote:
>> Hello,
>>   IMHO, it would be better to use java concurrency package now than to use
>> the old synchronize mechanism. The old mechanism is to low level and error
>> prone. I think you could have a thread pool and some handler pattern to
>> handle the request from your customer.
> That is a massive over complication for this use case.
That was my thought as well, but I don't know enough about the subject 
of concurrency and synchronization to be sure.
>>> On 7-May-2009, at 19:05, David Kerber wrote:
>>>> The synchronized section doesn't do a whole lot, so it doesn't take long
>>>> to process.  My question is, what kinds of operations need to be
>>>> synchronized?  All I do is decrypt the data from the POST,
> You should be able to easily write the decryption (if it isn't already) in a
> multi-threaded manner.
To that end, am I correct in understanding that any variables and 
objects that are declared locally to the method that does the work (such 
as the decryption routine) are going to be inherently thread safe?  And 
that variables and objects declared at the class level (such as my 
counters) may not be?  That's what the reading I did last night seemed 
to indicate, without explicitly stating so.

>>>> send a small acknowledgement response back to the site,
> Unlikely to have sync issues (but check to be sure)
>>>> and write the line to the log file.
> If you are using a logging framework (like log4j) this will handle the necessary
> sync for you. Otherwise you may have to write it yourself.
I'm doing it with the standard text file methods, but all the objects 
and variables are local to the method that processes the request.

> Incrementing the counters you are using needs to be synchronized. The simplest
> solution would be to use atomics.
I had never heard of them before I was reading about this yesterday, but 
it looks like a good possibility.

>>>>  Does that sound like something that would need to be
>>>> synchronized?
> So, some bits do must most don't.
> Getting rid of unnecessary syncs is a good thing but you really should find out
> where the bottleneck is before you start changing code.
That's my goal, but as far as I can tell right now, the bottleneck is 
narrowed down to either my code, or the customer's network, and testing 
some fixes to my code is pretty easy.

Thanks for the comments!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message