Create Disruptor with a ThreadFactory instead of ExecutorService

[brenuart]

See #567

[philsttr]

After this change, the AsyncDisruptorAppender no longer uses its executorService. The executorService is now only used by the AbstractLogstashTcpSocketAppender.

I think we have two options here:

1. Keep the executorService on AsyncDisruptorAppender for backwards compatibility in case there are other subclasses outside of logstash-logback-encoder using the executorService. In this case, the javadocs should be updated to indicate it's not used by AsyncDisruptorAppender directly, and kept for backwards compatibility for subclass usage only.
   OR
2. Move the executorService down to AbstractLogstashTcpSocketAppender.

I'm leaning in favor of 1. If you agree, can you update the javadoc of the field, and perhaps the getter as well?

We could also deprecate the executorService on AsyncDisruptorAppender with the intention of moving it down to AbstractLogstashTcpSocketAppender later. Thoughts?

[brenuart]

I see your point. However, we are moving to 7.0 and removed deprecated methods which are likely to break other people's code (I know they were marked @deprecated for a while already but, you know, I doubt many moved away from them already ;-)

I'd like to start the 7 series with as less deprecation as possible... Removing the ExecutorService from AsyncDisruptorAppender without notice is indeed not very "friendly" but how many will be affected? The workaround is very easy - just create the executor service yourself from the ThreadFactory and you are back in business.

So I would go for option (2) + describe the workaround in the release note.
Do you think this is acceptable?

[philsttr]

Yeah, I think 2 is acceptable since we're bumping the major version.

[brenuart]

Ok - done.
I'll write a note about the removal of the ExecutorService in the draft release note after the PR is merged.

I still have a question tho... I'm wondering why we have to set the corePoolSize on the ScheduledThreadPoolExecutor. This kind of executor will create threads on demand with no upper limit. The corePoolSize indicates the number of threads to keep in the pool, even if they are idle, unless allowCoreThreadTimeOut is set in which case idle threads may be evicted after a while. We have at most 3 threads/tasks:
- the KeepAlive task. This is a delayed task that is re-submitted after execution.
- the WriteTimeout. This task consumes a thread as long as the connection is open.
- the ReaderCallable. Used to read the input stream and detect when the destination closes the connection. It also consumes a thread for the duration of the connection.

If we start with a default corePoolSize of zero, the pool will start initially empty and at most 3 threads will be created depending on the configuration of the appender. Once created, 2 of them will remain active for the duration of the connection. They will return to the pool when the connection is closed and since the pool is not configured with an idle timeout they will stay there until they are reused by the subsequent connection. The recurrent KeepAlive task will also consume a thread for nearly 100% of the time and - again - will reuse one already in the pool when it is re-submitted.

My conclusion is we don't need to care about the corePoolSize at all...

(forget about the above - I was wrong - the ScheduledThreadPoolExecutor keeps only coreSize threads in the pool and discard any additional thread immediately after a task is completed and no more is waiting in the queue. Using a coreSize of zero is almost identical to not pooling anything at all)

[brenuart]

@philsttr Are you ok with these changes? Can I squash & merge?

[brenuart]

I need to add some words in the release note about the removal of the ExecutorService from the AsyncDisruptorAppender. Could you please create a first draft of the release note? I haven't done this yet with Github... I'll take care to fill in the blanks afterwards.

[philsttr]

Sure thing. Give me a few mins.

[brenuart]

Np. Time for me to go to sleep anyway ;-)