streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ebanks <ryaneba...@gmail.com>
Subject Re: LocalStreamBuilder#stop()
Date Wed, 08 Oct 2014 19:07:41 GMT
@Matt Hager
You are describing exactly what we are talking about in the options.
Option 1  would be the equivalent of calling shutdown with an infinite
timeout.  Option 2 would be calling shutdownNow with a very small timeout.
And option 2b would be calling shutdown with a predefined timeout and then
calling shutdownNow if the tasks hadn't terminated at the end of the
timeout.

-Ryan Ebanks

On Wed, Oct 8, 2014 at 10:34 AM, Matthew Hager [W2O Group] <
mhager@w2ogroup.com> wrote:

> Terminating threads is never a good idea. Shutdown the providers, give
> user an option to set a wait-out time. Default should be 10 minutes or
> something.
>
> I┬╣d pattern it off something like the way that ThreadPoolExecutor┬╣s
> termination behavior works. (Essentially, that is what you are doing)
>
>
> Thanks!
> Matt
>
> On 10/8/14, 10:31 AM, "Ryan Ebanks" <ryanebanks@gmail.com> wrote:
>
> >I've been added tests and fixing some issues in the local stream builder
> >class.  I need some input on how the stop() method should work so I can
> >write the appropriate tests.
> >
> >Option 1.) Gentle Shutdown
> >Immediately stop the providers from producing more data, but allow for all
> >data currently in the stream to finish processing.  Shutdown time would be
> >unknown as a result.
> >
> >Option 2.) Forceful Shutdown
> >Immediately stop the providers from producing more data, and stop all
> >processors/writers.  Data will be left in the pipeline will be discarded.
> >shutdown will be immediate
> >
> >Option 2b) Forceful Shutdown after small wait
> >Immediately stop providers from producing more data.  Give the
> >processors/writers a small window to try to finish processing (< 10secs),
> >and if not finished, forcefully shutdown all processors/writers.
> >
> >
> >These options can be changed in the future as more features are added.
> >For
> >example once datum tracking is implemented, we will probably want a
> >combination of option 1 and 2b.  But we need a defined way for it work
> >now,
> >so tests are testing the correct functionality.
> >
> >-Ryan Ebanks
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message