Suggestion for improving threading, async etc.

[Holger Hoffstätte <ho...@wizards.de>]

Hi,

I just saw that 3.0 aka the streaming branch is getting much love recently
and looking a lot better already - great work! :)
I'd like to make a suggestion that I had in mind for some time, way back
when I looked through the 2.0 code. Some of the threading and async
handling could really benefit from a more consistent design and less
reinvention. One nice thing might be to use the util.concurrent framework
which provides much better building blocks for anything threaded -
unfortunately it's only available for JDK 1.5+. For previous JDKs many
projects used Doug Lea's edu.oswego.util.concurrent library but that is
unmaintained now; luckily there's a solution: the "quasi-official"
backport-util-concurrent library (see:
http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent) which is
seeing increased use in many projects (the license is Apache-compatible
afaik). It contains a close-as-possible port of util.concurrent to 1.4+
JVMs and allows one to migrate to "native" JDK 1.5 by simply changing the
imports.
Is there some interest in patches for this? If so I could take on a
incremental migration towards a better design & implementation for the
thread & async handling. It might really be beneficial especially since
util.concurrent has adaptable threading strategies (block, wait, grow..)
instead of the current behaviour of just bombing out when workers are
exhausted. Other benefits might come from using the concurrent data
structures - these are usually the biggest contributors to scalability and
performance.
I'd really like to see 3.0 become a high-performance, low-memory,
low-latency screamer. :)

Comments?

Holger

PS: I thought the "streaming" branch would also incorporate a StAX parser
- is that still the goal or did I misunderstand? It still seems everything
is using SAX. In any case streaming the requests/responses themselves is a
great start though.

Re: Suggestion for improving threading, async etc.

[Jochen Wiedmann <jo...@gmail.com>]

Holger Hoffstätte wrote:

> I didn't realize the next version ("3.0") was supposed to run on <1.4, or
> even 1.2+ - my misunderstanding.

The streaming branches target platform is, of course, a matter of 
dicussion. To me, it looks like this: 1.2 plus JAXB 1.1 is completely 
upwards compatible, allows to use the collections framework and any 
modern SAX parser. On the other hands, I do not see a true benefit for 
XML-RPC on later versions. (The use of java.util.concurrent doesn't seem 
to me to be that important.)


Jochen

Re: Suggestion for improving threading, async etc.

[Holger Hoffstätte <ho...@wizards.de>]

Jochen Wiedmann wrote:
> Besides, do not forget, that your patches should include Unit tests
> for the added features and that these Unit tests should work on
> 1.2-1.5 (by again detecting, whether java.util.concurrent is in
> place).

I didn't realize the next version ("3.0") was supposed to run on <1.4, or
even 1.2+ - my misunderstanding. I really don't have enough time to write
some commons-concurrent wrapper, let alone test it on a pre-1.5 VM. I will
take a look at the WorkerFactory however; maybe we can then use the
current implementation as fallback or a backport-util-concurrent /
1.5-util.concurrent factory depending on the VM we run on. However this is
not going to give any benefits in terms of locks or concurrent data
structures in the est of the code so I'm not sure if it's worth the
trouble. We'll see - thanks for the suggestions.

Holger

Re: Suggestion for improving threading, async etc.

[Jochen Wiedmann <jo...@gmail.com>]

On 11/11/05, Holger Hoffstätte <ho...@wizards.de> wrote:

> Is there some interest in patches for this?

Sure, if your patches are made in a way, that

  a) automatically detects the presence of java.util.concurrent and chooses
      the proper implementation depending on the detections results or
  b) makes the current model the default and allows the user to select the
      1.5 version. (I do believe, that this should already be possible by
      choosing the WorkerFactory, but I did not actually try.)

Besides, do not forget, that your patches should include Unit tests
for the added features and that these Unit tests should work on
1.2-1.5 (by again detecting, whether java.util.concurrent is in
place).

> I'd really like to see 3.0 become a high-performance, low-memory,
> low-latency screamer. :)

Thanks. However, I'd clearly prefer the term "streaming" branch,
because so far this is my private work and was never reviewed or
accepted by the other developers on this list.

But that brings me to another point: If you want this thing to go on,
how about contributing some docs? That's definitely the part that's
lacking most before presenting the work on this mailing list and
allowing others to review the result.

> PS: I thought the "streaming" branch would also incorporate a StAX parser
> - is that still the goal or did I misunderstand? It still seems everything
> is using SAX. In any case streaming the requests/responses themselves is a
> great start though.

I see absolutely no reason for using a StAX parser. The parsing we do
is typically relatively easy. Did you have a look at the parser
classes? They really aren't overly complex.

Now, having two implementations with the same complexity, we should
really use that one, which doesn't add dependencies.


Jochen

--
Often it does seem a pity that Noah and his party did not miss the
boat. (Mark Twain)