Agree with Val, we already have multiple pools support, the only thing we should take care about is backward compatibility, when new node sends message to an old one which does not have a needed pool yet. We can handle it manually each time, but I prefer just to fallback to some default pool in old nodes to avoid complexity.
Sergi On Jul 31, 2015 10:50 AM, "Valentin Kulichenko" < valentin.kuliche...@gmail.com> wrote: > On Fri, Jul 31, 2015 at 12:30 AM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > On Fri, Jul 31, 2015 at 12:06 AM, Sergi Vladykin < > sergi.vlady...@gmail.com > > > > > wrote: > > > > > Guys, > > > > > > We had a problem with thread starvation in PUBLIC pool because of > queries > > > as described in https://issues.apache.org/jira/browse/IGNITE-1174 > > > > > > I switched it to SYSTEM pool but this can cause delays for other cache > > > operations like put/get if we have many long running queries. > > > > > > I propose adding one more thread pool for queries to make them > > independent. > > > > > > > I like the idea, however, I think the design should be more generic. I > > think Ignite should be able to have N thread pools. Then for each set of > > operations, e.g. task-execution, message-replies, query-processing, etc. > > user should be able to assign any of the available N thread-pools. This > can > > be done in the configuration. > > > > We actually already have similar design for plugins (see IoPool extension). > I think we can reuse it for all pools in the system. > > > > > > > Thoughts? > > > > > > Sergi > > > > > >
