commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: codec - thread safe
Date Mon, 08 Oct 2007 23:05:30 GMT
And, a simple map would suffice in that case (lazy-initialized of
course).  If you need QCodec, then you'd have in incorporate the
encodeBlanks and the charset into the map's key (if you really have
cases where you do/do not want to encode blanks).

On 10/8/07, sebb <sebbaz@gmail.com> wrote:
> Which methods do you actually need?
>
> If you only need BCodec, then that (and Base64 which it calls) look to
> be thread-safe, so you only need to instantiate it once for each
> different charset.
>
> On 08/10/2007, Qingtian Wang <qingtian.wang@gmail.com> wrote:
> > 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 <willpugh@sourcelabs.com> 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 <sebbaz@gmail.com> wrote:
> > > >
> > > >> On 08/10/2007, Will Pugh <willpugh@sourcelabs.com> wrote:
> > > >>
> > > >>> David J. Biesack wrote:
> > > >>>
> > > >>>>> Date: Mon, 8 Oct 2007 17:01:02 +0200
> > > >>>>> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <Joerg.Schaible@Elsag-Solutions.com>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>> 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: user-unsubscribe@commons.apache.org
> > > >>> For additional commands, e-mail: user-help@commons.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: user-help@commons.apache.org
> > > >>
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > > For additional commands, e-mail: user-help@commons.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: user-help@commons.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> > For additional commands, e-mail: user-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message