Re: Regarding DIRMINA-912
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 McKnightm...@mcknight4.com 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-912https://issues.apache.org/jira/browse/DIRMINA-912 Thanks! Mike
Re: Regarding DIRMINA-912
Sounds like you need a task queue and a single dispatcher thread. Write the metered messages to the task queue and let it do the temporal management. This can all be done with one thread. On Aug 25, 2013 11:57 AM, Mike McKnight m...@mcknight4.com wrote: 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 McKnightm...@mcknight4.com 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-912https://issues.apache.org/**jira/browse/DIRMINA-912 https:**//issues.apache.org/jira/**browse/DIRMINA-912https://issues.apache.org/jira/browse/DIRMINA-912 Thanks! Mike
Re: Regarding DIRMINA-912
It is all working fine...I just followed the workaround suggestion in the min bug I referenced. My only point was that I believe this is a bug in the MINA framework that should be fixed and could be addressed rather simply. On 08/25/2013 10:36 AM, Jon V. wrote: Sounds like you need a task queue and a single dispatcher thread. Write the metered messages to the task queue and let it do the temporal management. This can all be done with one thread. On Aug 25, 2013 11:57 AM, Mike McKnight m...@mcknight4.com wrote: 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 McKnightm...@mcknight4.com 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-912https://issues.apache.org/**jira/browse/DIRMINA-912 https:**//issues.apache.org/jira/**browse/DIRMINA-912https://issues.apache.org/jira/browse/DIRMINA-912 Thanks! Mike
Re: Regarding DIRMINA-912
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 m...@mcknight4.com 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-912https://issues.apache.org/jira/browse/DIRMINA-912 Thanks! Mike
Re: Regarding DIRMINA-912
Le 8/22/13 11:51 PM, Mike McKnight a écrit : 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. If your protocol is stateless, I don't think it's a problem. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Regarding DIRMINA-912
Agreed...I think I may run into an issue when I am running a ThrottlingFilter for IoEventType.WRITE events. I think that if the filter were written such that if the interval between the last message sent to an IoSession were not long enough, say 8ms, then the filter would need to sleep for some amount of time and if this bug is in play then I could envision other events like IoEventType.MESSAGE_RECEIVED not getting handled until the thread became available for that IoSession. Mike On 08/22/2013 04:51 PM, Emmanuel Lécharny wrote: Le 8/22/13 11:51 PM, Mike McKnight a écrit : 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. If your protocol is stateless, I don't think it's a problem.
