Hi Pavel,

Thanks for confirming.

I have modified this particular subsystem to use Compute functions to
transit the data I was moving via messaging (this is a case where data
needs to move to the logic, unfortunately), and to use the custom
WithExecutor(). So far it works pretty well :)

Thanks,
Raymond.


On Fri, Mar 13, 2020 at 9:19 AM Pavel Tupitsyn <[email protected]> wrote:

> Raymond, I don't think there is a way to move IMessageListener.Invoke calls
> from Ignite public thread pool to somewhere else. WithExecutor API is for
> Compute only.
>
> > public thread pool is saturated and then causes a deadlock when a
> message arrives from another node using IMessageListener
> Possible options are:
> - increase public thread pool size using
> IgniteConfiguration.PublicThreadPoolSize property
> - move actual message processing to .NET thread pool using Task.Run /
> ThreadPool.QueueUserWorkItem / etc
>
> On Wed, Mar 11, 2020 at 7:11 AM Raymond Wilson <[email protected]>
> wrote:
>
>> I'm using the C# client on Ignite 2.8.0.
>>
>> I have had an issue with thread deadlocking where the public thread pool
>> is saturated and then causes a deadlock when a message arrives from another
>> node using IMessageListener, eg
>>
>>   public class MyListener : IMessageListener<T>
>>   {
>>     public bool Invoke(Guid nodeId, T message)
>>     {
>>       // Process it
>>
>>       return true;
>>     }
>>  }
>>
>> Ignite 2.8.0 now supports custom thread pools in the C# client :)
>>
>> I can see how to create a custom thread pool in the Ignite configuration,
>> like this:
>>
>>             ExecutorConfiguration = new List<ExecutorConfiguration>
>>             {
>>               new ExecutorConfiguration
>>               {
>>                 Name = "MyPool"
>>                 Size = 8
>>               }
>>             }
>>
>> And use it like this:
>>
>>            ignite.Compute().WithExecutor("MyPool").Run() etc
>>
>> However, I am not sure how to ask Ignite to run the Invoke() from the
>> MessageListener on that custom thread pool, rather than the public thread
>> pool.
>>
>> Suggestions?
>>
>> Thanks,
>> Raymond.
>>
>>

Reply via email to