The SLA of the project I am working on is 2000 transactions per second. And I need to decode a 1K string on each request.....
-Q On 10/8/07, Will Pugh <[EMAIL PROTECTED]> wrote: > Ya know. Just to put this in a little perspective. > > These objects are pretty small (QCodec has only two members in it), and > have practically no instantiation cost. Instantiating these and quickly > throwing them out is probably not such a bad idea, and may give you > better performance that doing anything with ThreadLocal. Java VMs are > fairly well tuned for dealing with short-lived, small objects (which > these are). > > I can't imagine that many people are using thousands of these per > request, probably, more on the order of one or two a request? > > --Will > > James Carman wrote: > > Try using a ThreadLocal variable to store your Encoder/Decoder that > > you need to be thread safe. > > > > On 10/8/07, sebb <[EMAIL PROTECTED]> wrote: > > > >> On 08/10/2007, Will Pugh <[EMAIL PROTECTED]> wrote: > >> > >>> David J. Biesack wrote: > >>> > >>>>> Date: Mon, 8 Oct 2007 17:01:02 +0200 > >>>>> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]> > >>>>> > >>>>> > >>>>> > >>>>>> The java.util.concurrent backport > >>>>>> http://backport-jsr166.sourceforge.net/ runs on 1.3, for just this > >>>>>> kind of use. > >>>>>> > >>>>>> > >>>>> I know this, but I doubt that we wanna start to depend Apache common > >>>>> components on it ;-) > >>>>> > >>>>> > >>>> Agreed; I, like you, was merely suggesting to what Commons consumers > >>>> might do to deal with non-threadsafe codecs. > >>>> > >>>> > >>>> > >>> Might seem like a silly question, but has anyone found anything that > >>> looks like a threading issue in Codec? > >>> > >> Yes - QCodec has a public method that sets an instance variable (see > >> my comments on CODEC-55). > >> > >> > >>> The code is pretty simple. I did a quick look through the code, and it > >>> seemed like everything was pretty thread safe. It looks like you should > >>> be O.K. as long as: > >>> 1) You don't change the parameters to a codec while it's running, > >>> e.g. changing charsets, etc. > >>> > >> See above. > >> > >> Having said that, I think it would not be too difficult to fix the > >> classes so that they are thread-safe. Most of the ones I looked at > >> could even be made invariant. > >> > >> So their thread-safety would only depend on any external calls they > >> made; this could presumably be fixed by providing synchronised > >> versions as suggested earlier. > >> > >> > >>> 2) You should not use a MessageDigest returned by DigestUtils by > >>> multiple threads. This should be clear given the API (it's a SUN api) > >>> > >>> It also seems to me that the difference between code that you can trust > >>> as being thread safe, and code you cannot trust as being thread safe has > >>> a lot to do with whether it is tested for thread safety. Seems to me > >>> like another way of helping out here would be to build concurrency tests > >>> for whichever APIs you are interested using on multiple threads. Not > >>> sure where we would put them yet, but seems like the only way to assure > >>> thread-safety (especially if we could get someone to volunteer running > >>> them on a big beefy multi-proc machine :). > >>> > >> Indeed. > >> > >> > >>>>> - Jörg > >>>>> > >>>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
