commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: codec - thread safe
Date Mon, 08 Oct 2007 23:31:27 GMT
Or take a copy of QCodec and fix it to remove the offending code...

The change would be more difficult to make in the codec library,
because removing the offending method would not be backwards
compatible.

On 09/10/2007, James Carman <james@carmanconsulting.com> wrote:
> 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
>
>

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


Mime
View raw message