PoolFiber

[Ryan Rawson]

Hey guys,

I've been reading the jetlang code and a few things are a mystery for me...

So PoolFiber... I see the default constructor takes 3 arguments:

Executor pool (ok makes sense)

BatchExecutor (well, there is only 1 implementation, and I'm not sure there is potential alternates)

ScheduledExecutorService (hmm)

So a few questions:

- does batch executor need to exist?  There seems to be only 1 valid implementation, since if one had it do the batch in parallel you'd lose the single-thread at a time nature of a Fiber contract.  

- ScheduledExecutorService - makes sense, but can one use the same executor for both the pool and the scheduler?  

- I see that there is a call "schedulerThatIgnoresEventsAfterStop" - it seems like this concept is important... If I reuse a random executor as my scheduler (for eg: a netty4 executor is also a scheduled executor as well), would I run in to problems?

- If I must use a scheduler that ignores tasks once it's been shut down, and I use my own, will I have to worry about thread-lock or starvation issues?  Specifically does the scheduler MUST be it's own thread as it appears to be if one uses the default PoolFiberFactory use model?

For example if I build a scheduled event executor and tell it to use 1 thread, and then assign that to a PoolFiberFactory, eg:

ScheduledExecutorService executor = // get this from, say, a netty4 event group loop

PoolFiberFactory fact = new PoolFiberFactory(executor, executor)

will I regret this later?  Do I need to set the rejectionExecutionHandler like in SchedulerImpl.java?  

Thanks!

[Mike Rettig]

-The batch executor is a common extension point for monitoring. There are many implementations that add logging or timing for each task. Jetlang doesn't have any 3rd party dependencies so it can't provide these implementations.

-You can use the same pool for execution and scheduling.

-It is possible for rejected events to fire after shutdown due to race conditions, so it is important to handle this similarly to 'schedulerThatIgnoresEventsAfterStop'. 

-I've never tested with reusing the same thread for scheduling and execution, but that should be fine. 

The rejected executions only occur if an event fires while an attempt is being made to dispose the pool fiber factory. It is rare. The exception that is thrown might not be a problem depending on your app. In my case, I added that code just because it would generate an error that developers would waste time looking into before realizing that it was just noise at shutdown of an app. If the scheduler is provided by a 3rd party, then you can protect against the exception by decorating the scheduler with an exception handler that can gracefully ignore the exception if you are shutting down.

Mike

--
You received this message because you are subscribed to the Google Groups "jetlang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jetlang-dev...@googlegroups.com.
To post to this group, send email to jetla...@googlegroups.com.
Visit this group at http://groups.google.com/group/jetlang-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ryan Rawson]

Thanks a lot for the reply!  I am think I'm getting the design decisions.

I also note that if you dont use the scheduled features, the scheduled thread pool wont ever start a thread.

I think there is a lot of promise between jetlang, netty4 (which has good thread control) and guava callbacks/futures (which require you to specify a threadpool on which to run the callback).  It fits my use case nicely, since I want to be very specific about what types of tasks (eg: IO vs cpu) get how many threads to execute.  This the kind of stuff you don't get with akka for example.