ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: API for asynchronous execution.
Date Tue, 29 Mar 2016 19:45:27 GMT
Vladimir, Igniters

Here are my 2 cents. 

The current situation with threading when it comes to executing user callbacks -- the CQ filters
(either local or remote), the CQ listeners, the event listeners, the messaging listeners,
the entry processors (did I miss anything?) -- is pretty sad. The callbacks may get executed
on a system pool's thread, public pool's, utility pool's, discovery worker thread, application
thread, to name a few. It causes a lot of grief and suffering, hard-to-fix races, dead locks
and other bugs. 

I guess it's always possible to come up with a more or less reasonable explanation to such
predicament (which usually boils down to "It is so because this is how it's implemented"),
but I, as a user, could not care less. I want consistency. I want all my callbacks (including
Entry Processors!) to be executed on the public pool's threads, to be precise. This is not
the first time I complain about this, and I really think it's time to fix this mess.

For a good example of how to implement ordered async dispatch of callbacks on large scale,
one only needs to look at Akka (or Reactor https://github.com/reactor/reactor).  Coherence
also managed to get it right (in my opinion, that is).


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