sebb wrote:
On 09/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
On 10/8/07, sebb <[EMAIL PROTECTED]> 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
di
On 09/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> On 10/8/07, sebb <[EMAIL PROTECTED]> 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
> > diffe
On 10/8/07, sebb <[EMAIL PROTECTED]> 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.
Yes, I sort of figured that out for myself already wh
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 <[EMAIL PROTECTED]> wrote:
> And, a simple map would suffice in
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 <[EMAIL PROTECTED]> wrote:
> Whi
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 <[EMAIL PROTECTED]> wrote:
> The SLA of the project I am working on is 2000 t
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
That's kind of what I said on the JIRA issue, too.
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 q
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
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=F6
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 ju
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
> 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 co
David J. Biesack wrote on Monday, October 08, 2007 4:40 PM:
>> Date: Mon, 8 Oct 2007 16:23:59 +0200
>> From: =?iso-8859-1?Q?J=F6rg_Schaible?=
> <[EMAIL PROTECTED]>
>>
>> David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:
>>
Date: Sat, 6 Oct 2007 23:31:19 -0500
From: "Qingtian
On 10/8/07, sebb <[EMAIL PROTECTED]> wrote:
> On 08/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> > On 10/7/07, sebb <[EMAIL PROTECTED]> wrote:
> > > On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> > > > Ok, I got the point.
> > > >
> > > > So let's say I wanted to work on this. Wha
> Date: Mon, 8 Oct 2007 16:23:59 +0200
> From: =?iso-8859-1?Q?J=F6rg_Schaible?= <[EMAIL PROTECTED]>
>
> David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:
>
> >> Date: Sat, 6 Oct 2007 23:31:19 -0500
> >> From: "Qingtian Wang" <[EMAIL PROTECTED]>
> >>
> >> Well, it's pick-your-poison kin
David J. Biesack wrote on Monday, October 08, 2007 3:02 PM:
>> Date: Sat, 6 Oct 2007 23:31:19 -0500
>> From: "Qingtian Wang" <[EMAIL PROTECTED]>
>>
>> Well, it's pick-your-poison kind of a deal. Either block on one
>> instance and take a performance hit, or burn up the memory with lots
>> of inst
> Date: Sat, 6 Oct 2007 23:31:19 -0500
> From: "Qingtian Wang" <[EMAIL PROTECTED]>
>
> Well, it's pick-your-poison kind of a deal. Either block on one
> instance and take a performance hit, or burn up the memory with lots
> of instances.
Why not compromise? Create a ThreadPoolExecutor of some
On 08/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> On 10/7/07, sebb <[EMAIL PROTECTED]> wrote:
> > On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> > > Ok, I got the point.
> > >
> > > So let's say I wanted to work on this. What's the most effective way to
> > > do it?
> >
> > You
simon wrote on Monday, October 08, 2007 8:19 AM:
> On Sun, 2007-10-07 at 15:23 -0500, Qingtian Wang wrote:
>> Ok, I got the point.
>>
>> So let's say I wanted to work on this. What's the most effective way
>> to do it?
>>
>> Search the entire code base line by line trying to ID all the thread
>
On Sun, 2007-10-07 at 15:23 -0500, Qingtian Wang wrote:
> Ok, I got the point.
>
> So let's say I wanted to work on this. What's the most effective way to do it?
>
> Search the entire code base line by line trying to ID all the thread
> unsafe points by myself? I guess that's very ineffective com
On 10/7/07, sebb <[EMAIL PROTECTED]> wrote:
> On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> > Ok, I got the point.
> >
> > So let's say I wanted to work on this. What's the most effective way to do
> > it?
>
> You could try running some of the code checking utilities on the library.
>
On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> Ok, I got the point.
>
> So let's say I wanted to work on this. What's the most effective way to do it?
You could try running some of the code checking utilities on the library.
For example Findbugs and PMD.
I've done a quick check with F
Ok, I got the point.
So let's say I wanted to work on this. What's the most effective way to do it?
Search the entire code base line by line trying to ID all the thread
unsafe points by myself? I guess that's very ineffective compared to
have an issue open, and have the individual developers who
Can the dev team make that happen? - a humble request from a user.
The think about open source is that there is no distinction between
developer and user.
That's interesting. Why then almost all open source projects have
"users doc vs. developer doc", "users mailing list vs. developers
mailing
On 10/7/07, simon <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-06 at 23:31 -0500, Qingtian Wang wrote:
> > Well, it's pick-your-poison kind of a deal. Either block on one
> > instance and take a performance hit, or burn up the memory with lots
> > of instances.
> >
> > But in the case of BCodec
On 07/10/2007, simon <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-10-06 at 23:31 -0500, Qingtian Wang wrote:
> > Well, it's pick-your-poison kind of a deal. Either block on one
> > instance and take a performance hit, or burn up the memory with lots
> > of instances.
> >
> > But in the case of BCo
On Sat, 2007-10-06 at 23:31 -0500, Qingtian Wang wrote:
> Well, it's pick-your-poison kind of a deal. Either block on one
> instance and take a performance hit, or burn up the memory with lots
> of instances.
>
> But in the case of BCodec, I think encode/decode is thread safe.
> Unfortunately
Well, it's pick-your-poison kind of a deal. Either block on one
instance and take a performance hit, or burn up the memory with lots
of instances.
But in the case of BCodec, I think encode/decode is thread safe.
Unfortunately per Henri, that's not generally true for others.
Well, let me make
How about...
MyStringCodec {
BCodec delegate = new BCodec();
String encode(String in) {
String result = null;
synchronized(delegate)
{
result = delegate.encode(in);
}
return result;
}
}
On 10/6/07, Qingtian Wang <[EMAIL PROTECTE
Henri,
That was an unpleasant surprise.
So what would be the general suggested program pattern to use the API
if one wants to be thread safe?
Is it 1:
MyStringCodec {
String encode(String in) {
return new BCodec().encode(in);
}
}
or 2:
MyStringCodec {
BCodec delegate = new
On 9/29/07, Qingtian Wang <[EMAIL PROTECTED]> wrote:
> I apologize for this question as it must have been asked a million
> times: I was unable to search the mailing list archive for this.
>
> Are all the "encode/decode" methods in commons-codec intended to be thread
> safe?
>
> I peeked into the
32 matches
Mail list logo