nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Zhurakousky <>
Subject Re: Common scheduler and add-hock thread creation
Date Tue, 17 Nov 2015 01:01:32 GMT
Taking liberties - so let me throw few example. I am sure you’d agree that Thread creation
and management is an expensive and hard and error prone, hence new java.util.concurrent and
all the goodies in it. 
- There is a patch currently in the queue where there is a creation of new Thread() and then
starting it. Is it necessary? Could we reuse the thread from the common pool?
- We have many places where we have Thread.sleep(..) and in fact do sleep considerable amount
of time. That thread lays dormant where it could actually be doing something. Is it necessary?


> On Nov 16, 2015, at 7:52 PM, Tony Kurc <> wrote:
> the issue with a best practices guide on this subject is it will be
> dominated by edge cases. The common case should be "don't produce any
> threads".
> That being said, I commented on a jira somewhere about LinkedBlockingQueues
> used in so many producer/consumer style processors and possibly needing a
> library to have some consistency in using those queues in a consistent
> thread safe manner.
> Also, I'm not quite sure of what you mean by taking liberties?
> On Mon, Nov 16, 2015 at 7:39 PM, Oleg Zhurakousky <
>> wrote:
>> Guys
>> I am noticing many modules where we have things like "new
>> Thread(..).start()”, creation of new executors and schedulers,
>> Thread.sleep(..)  etc.,. I am sure many would agree that taking such
>> liberties with Threads will have consequences (not IF but WHEN)
>> On several threads several of us mentioned a “must read” for anyone who is
>> getting into concurrent code -
>> and indeed we can/should definitely grab some best practices from this book.
>> At least we can start from what’s our strategy around thread management
>> for NAR developers? Basically should/should not a user create Threads,
>> Executors, Schedulers etc.
>> Cheers
>> Oleg

View raw message