Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <user@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <f2e8eedf0710081444x4f4b70eahcb41255d401e37af@mail.gmail.com>
Date: Mon, 8 Oct 2007 17:44:30 -0400
From: "James Carman" <james@carmanconsulting.com>
Sender: jcarman@carmanconsulting.com
To: "Jakarta Commons Users List" <user@commons.apache.org>
Subject: Re: codec - thread safe
In-Reply-To: <470A98F4.5070802@sourcelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <49645ccf0709292130ud20383y756f33415e224e31@mail.gmail.com>
	 <20071008130151.0FA1E724886@athena.apache.org>
	 <F0D7281DAB048B438E8F5EC4ECEFBDDC01E502EA@esmail.elsag.de>
	 <20071008144000.4168B724881@athena.apache.org>
	 <F0D7281DAB048B438E8F5EC4ECEFBDDC01E502F2@esmail.elsag.de>
	 <20071008151647.2B58E72486B@athena.apache.org>
	 <470A5A32.1010402@sourcelabs.com>
	 <25aac9fc0710080956k23d8cb06ye68c3a00bb9800ec@mail.gmail.com>
	 <f2e8eedf0710081058o52c8a458k5a98d2ae4ec2be7e@mail.gmail.com>
	 <470A98F4.5070802@sourcelabs.com>

That's kind of what I said on the JIRA issue, too.

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: =3D?iso-8859-1?Q?J=3DF6rg_Schaible?=3D <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 commo=
n 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 sho=
uld
> >>> 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 tru=
st
> >>> 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 te=
sts
> >>> 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 assu=
re
> >>> thread-safety (especially if we could get someone to volunteer runnin=
g
> >>> them on a big beefy multi-proc machine :).
> >>>
> >> Indeed.
> >>
> >>
> >>>>> - J=F6rg
> >>>>>
> >>>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> 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