On Fri, 17 Sep 2004 11:28:07 -0600, Kris Nuttycombe
<[EMAIL PROTECTED]> wrote:
> Hi, all,
>
> I'm writing to get some advice and perhaps offer some code that may be
> useful to the commons-chain project or elsewhere.
>
Kris,
Sorry it took so long (catching up after a two week trip was more time
es down
exactly the same route.
Thanks for the link to Coconut, I'll check it out!
Cheers,
Rory
-Original Message-
From: Alex Karasulu [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 16:22
To: Jakarta Commons Developers List
Subject: RE: [chain] Pipeline implementation
On Wed,
On Wed, 2004-09-22 at 10:33, Kris Nuttycombe wrote:
> I'll try and get our code to Craig today so that people can have a
> closer look at it.
Excellent. I think this can help me see more overlap as well.
Alex
-
To unsubscri
IO side called coconut at the codehaus which has similar
functionality but its missing some of the aspects of the chain library
here:
http://coconut.codehaus.org/
> -Original Message-
> From: Kris Nuttycombe [mailto:[EMAIL PROTECTED]
> Sent: 22 September 2004 00:47
> To: Jakar
t: 22 September 2004 15:34
To: Jakarta Commons Developers List
Subject: Re: [chain] Pipeline implementation
This is exactly the sort of use case we have developed our pipeline
under, and there are in fact already plugins to obtain data over FTP and
HTTP, and work is ongoing on an XSLT plugin.
A
eady?
Cheers,
Rory
-Original Message-
From: Kris Nuttycombe [mailto:[EMAIL PROTECTED]
Sent: 22 September 2004 00:47
To: Jakarta Commons Developers List
Subject: Re: [chain] Pipeline implementation
Alex Karasulu wrote:
subscribers that share the same index have events processed in paralle
On Tue, 2004-09-21 at 19:46, Kris Nuttycombe wrote:
> Alex Karasulu wrote:
>
> >>subscribers that share the same index have events processed in parallel.
> >>Also, perhaps instead of returning void StageHandler.handleEvent() could
> >>return a boolean value that flags whether or not the event is
Alex Karasulu wrote:
subscribers that share the same index have events processed in parallel.
Also, perhaps instead of returning void StageHandler.handleEvent() could
return a boolean value that flags whether or not the event is allowed to
propagate to other stages with higher serial numbers.
T
Hi all,
Just wanted at least once to attempt to cross pollinate both lists
(Directory) and Commons by posting to both this response. I think there
are some very interesting ideas here.
Most likely we are not going to be able to make the SEDA stuff this
general purpose - nor do we want to howeve
Hi Kris,
On Fri, 2004-09-17 at 19:29, Kris Nuttycombe wrote:
> >>The model that we've been using is that stages process data instead of
> >>events, although one could certainly consider an event as a type of
> >>
> >>
> >
> >Ahh that's interesting. We do the events and carry a payload.
Alex Karasulu wrote:
Cool. We actually don't have our own thread pool but abstracted it away
so we can use any thread pool. For testing purposes we use the commons
sandbox thread pool. We made this API thinking it'll be embedded within
other servers or frameworks that already have their own thr
Hi Kris,
On Fri, 2004-09-17 at 16:23, Kris Nuttycombe wrote:
> Hi, Alex,
>
> There is definitely some overlap here, and I think that there's good
> potential for collaboration. Our current implementation of the pipeline
> can definitely benefit from the per-stage thread pool configuration that
Hi, Alex,
There is definitely some overlap here, and I think that there's good
potential for collaboration. Our current implementation of the pipeline
can definitely benefit from the per-stage thread pool configuration that
you've done, since right now each one of our stages is still
single-thr
13 matches
Mail list logo