nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Zhurakousky <ozhurakou...@hortonworks.com>
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?

Cheers
Oleg


> On Nov 16, 2015, at 7:52 PM, Tony Kurc <trkurc@gmail.com> 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 <
> ozhurakousky@hortonworks.com> 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 -
>> http://ptgmedia.pearsoncmg.com/images/9780321349606/samplepages/9780321349606.pdf
>> 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
>> 

Mime
View raw message