On 09/18/2014 05:32 PM, Dan Berindei wrote:
>
> You're right about the remote executor getting full as well, we're
> lacking any feedback mechanism to tell the sender to slow down, except
> for blocking the OOB thread. I wonder if we could tell JGroups somehow
> to discard the message from inside MessageDispatcher.handle (e.g. throw
> a DiscardMessageException), so the sender has to retransmit it and we
> don't block the OOB thread. That should allow us to set a size limit on
> the BlockingTaskAwareExecutor's blockedTasks collection as well. Bela,
WDYT?
Even if we have a way to tell the JGroups to resend the message, we have
no idea if the executor service is full or not. We allow a user to
inject their own implementation of it.
We do allow a custom executor implementation, but it's our SPI. So we
can require the custom executor to be configured to throw a
RejectedExecutionException when the queue is full instead of blocking
the caller thread, if it helps us.
and about jbossas/wildfly? aren't they inject their own executor service?
the better approach will be to have a custom rejection policy that put
back the task in the BlockingTaskAwareExecutor's queue.