It does, thank you. I've just dropped a few person-days from our current effort estimation.
> Am 07.08.2015 um 07:13 schrieb Alexey Goncharuk <[email protected]>: > > >> I think what counts is the number of jobs/tasks which can be executed by one >> node at a given time. I think this should be configurable within ignite. >> >> Here's my use case. We want to run a distributed computation using a >> third-party tool which, when executed, takes an entire CPU core. We'll wrap >> that execution in Java in an Ignite task/job (sorry, I alwas forget which is >> which). On a multi-core machines we'd like to be able to run N-X tasks >> simultaneously where N is a number of cores and X is 1 or 2 (for 4-core or >> >8-core machines) reserved for administrative/management tasks. Like, 14 >> cores for a 16-core machine. >> >> At the moment my understanding is that we'll need to start N-X nodes per >> server, to handle N-X jobs/tasks at once, correct? > > You do not need to start multiple nodes in order to achieve multi-threaded > job execution. By default Ignite will run tasks in parallel in the public > thread pool of a fixed size in the order in which they arrive on a node. The > default number of threads in this pool is 2*number of cores reported by > Runtime#availableProcessors(). So if you do need any fancy job execution > ordering or job stealing, it will be enough to set the number of threads in > the public thread pool to N-X (see > IgniteConfiguration#setPublicThreadPoolSize). > > If you want a more fine-grained control over how jobs are executed, you might > want to use one of the CollisionSPIs shipped with Ignite, for example, > PriorityQueueCollisionSpi or JobStealingCollisionSpi, or implement your own > collision SPI. > > Hope that helps, > Alexey
