In my case I have units on the ground that need to have messages
throttled when being sent to the units. In other words all of the queued
write events going to each unit need to be metered out in an temporal
fashion. I have a separate thread pool available that can expand to the
number of units on the ground, which is max around 50, and handles this
metering process. Message processing for all but WRITE events needs to
be unfettered in any way and can not be held up for writes being
throttled. So for sure I need another executor filter that handles all
but WRITE events.
I don't see how I can do this with a single executor filter. As events
are processed in order in a queue and if I am waiting on a write then
MESSAGE_RECEIVED events are not going to get processed. There are no
separate SessionTasksQueue for the OrderedThreadPoolExecutor, just the
one for all events waiting to be processed.
Filter chain looks like this:
* codec
* inbound-filter (executor filter for all but WRITE events)
* write-throttle-filter (overrides filterWrite)
* outbound-filter (executor filter for WRITE events only)
On 08/23/2013 12:32 PM, Jon V. wrote:
What is the use case for having different thread pools for read and write
events?
Writes are already scheduled one they hit the worker. Not like your write
process is going to slow down an already threaded read request.
On Aug 22, 2013 5:52 PM, "Mike McKnight"<[email protected]> wrote:
I am just curious if there is a downside to this issue that I am not
seeing. I have seen this in my MINA application; I have inbound/outbound
executor filters as described in the issue and have seen where my inbound
threads are *sometimes* processing IoEventType.WRITE events. I don't see
any adverse effects of this, my messages are being put on the wire, but am
checking in with the list to be sure.
I am running mina-2.0.7.
https://issues.apache.org/**jira/browse/DIRMINA-912<https://issues.apache.org/jira/browse/DIRMINA-912>
Thanks!
Mike
