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
different charset.
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
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 compared
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 could try running some
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
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 instances.
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 kind of a deal. Either
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. What's the most effective
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 Wang [EMAIL
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
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
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.
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
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
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
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
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:
Which
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
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 when I
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 BCodec, I think
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, I think
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
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
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
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.
For example
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
26 matches
Mail list logo
