You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2013/01/07 06:42:12 UTC
[MINA3] Writting messages directly : some pb
Hi !
as you know, I was modifying the code to write the messages directly
into the channel instead of pushing it into a queue, and wait for the
SelectorLoop to process it. So far, so good it works well, except that
the messageSent( event is difficult to generate.
Whe we push the message into a queue, what happens is that we feed the
DefaultWriteRequest with the original message (ie before it goes through
the codec filter), and we also add a future into it. This is done
*after* the message has been enqueued. Why ? Because in
AbstractIoSession.processMessageWriting(), we get back the enqueued
message using the lastWriteRequest, which is produced by the
AbstractIoSession.enqueueFinalWriteMessage().
Now, the messageSent() event will be produced by the selectorLoop() when
it process the message to write, pollingit from the queue. At thsi
point, this message has everything needed : the data tow rite, the
original data and teh future.
But when we write the message directly, we don't have the future nor the
original message, yet, but still we have to generate the messageSent
event. This is problematic...
Here, what I suggest, is that the original message is to be passed
through the full chain of filters, so that we can update it in any case.
That would probably mean that the AbstractIoSession.doWriteWithFuture()
create this envelop, feed it with the original message and the future,
and pass this object down the chain.
I don't see any oher way to solve this issue. If any of you have any
better idea, I'm all ears :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Chad Beaulac <ca...@gmail.com>.
Hi Emmanuel.
It's all good. We want the same thing. I'm not feeling like we're arguing at all. :-)
Understood on setting SO_SNDBUF.
I think your algorithm is good. The write before the select fires the write event only when the queue is empty should be ok and it should lower initial latency as you suggested earlier.
I'm going to test this change but I expect that it will work well.
Regards,
Chad
On Jan 8, 2013, at 11:40 AM, Emmanuel Lécharny wrote:
> Just a clarification :
>
> Chad, I don't want to fell like I'm arguing. I'm really trying to see if
> the change I have pushed should be made optional, and if doing so will
> really help when we are dealing with a congestion situation.
>
> What I dont get is how waiting for the select() to wake up the thread
> when the socket is ready to write is any different from what I'm doing.
> Do you have any link that explaining the pb ?
>
> Thanks !
>
>
> Le 1/8/13 4:46 PM, Emmanuel Lécharny a écrit :
>> Le 1/8/13 4:06 PM, Chad Beaulac a écrit :
>>> Understood on change in state between writable event firing and socket could close by the time you goto write. In which case the read event would fire next and result in zero bytes read signaling the socket is closed.
>>>
>>> Your statement below is exactly what I have dealt with on many systems. Resulting in TCP buffer overflow and RAM bloat/leak.
>>> "One possible case would be if the underlying OS were to accept anything
>>> you try to write into the socket..."
>> In my understanding, you can mitigate such pb by setting the
>> SO_SNDBUF,accordingly to your client capacity. At some point, if your
>> client is slow, you perfectly can ends with your server being swamped
>> with data waiting to be sent, but I don't see hav using a queue can help
>> here : as soon as the socket will refuse to accept anymore data than the
>> buffer it uses to store the data, you are safe.
>>
>> In other words, your application should take care of such scenario, or,
>> better for MINA to provide the tools to inform the application when the
>> sending queue is getting too large...
>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Chad Beaulac
Objective Solutions, Inc.
www.objectivesolutions.com
chad@objectivesolutions.com
410.707.5842 (cell)
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Just a clarification :
Chad, I don't want to fell like I'm arguing. I'm really trying to see if
the change I have pushed should be made optional, and if doing so will
really help when we are dealing with a congestion situation.
What I dont get is how waiting for the select() to wake up the thread
when the socket is ready to write is any different from what I'm doing.
Do you have any link that explaining the pb ?
Thanks !
Le 1/8/13 4:46 PM, Emmanuel Lécharny a écrit :
> Le 1/8/13 4:06 PM, Chad Beaulac a écrit :
>> Understood on change in state between writable event firing and socket could close by the time you goto write. In which case the read event would fire next and result in zero bytes read signaling the socket is closed.
>>
>> Your statement below is exactly what I have dealt with on many systems. Resulting in TCP buffer overflow and RAM bloat/leak.
>> "One possible case would be if the underlying OS were to accept anything
>> you try to write into the socket..."
> In my understanding, you can mitigate such pb by setting the
> SO_SNDBUF,accordingly to your client capacity. At some point, if your
> client is slow, you perfectly can ends with your server being swamped
> with data waiting to be sent, but I don't see hav using a queue can help
> here : as soon as the socket will refuse to accept anymore data than the
> buffer it uses to store the data, you are safe.
>
> In other words, your application should take care of such scenario, or,
> better for MINA to provide the tools to inform the application when the
> sending queue is getting too large...
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 1/8/13 4:06 PM, Chad Beaulac a écrit :
> Understood on change in state between writable event firing and socket could close by the time you goto write. In which case the read event would fire next and result in zero bytes read signaling the socket is closed.
>
> Your statement below is exactly what I have dealt with on many systems. Resulting in TCP buffer overflow and RAM bloat/leak.
> "One possible case would be if the underlying OS were to accept anything
> you try to write into the socket..."
In my understanding, you can mitigate such pb by setting the
SO_SNDBUF,accordingly to your client capacity. At some point, if your
client is slow, you perfectly can ends with your server being swamped
with data waiting to be sent, but I don't see hav using a queue can help
here : as soon as the socket will refuse to accept anymore data than the
buffer it uses to store the data, you are safe.
In other words, your application should take care of such scenario, or,
better for MINA to provide the tools to inform the application when the
sending queue is getting too large...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Chad Beaulac <ca...@gmail.com>.
Understood on change in state between writable event firing and socket could close by the time you goto write. In which case the read event would fire next and result in zero bytes read signaling the socket is closed.
Your statement below is exactly what I have dealt with on many systems. Resulting in TCP buffer overflow and RAM bloat/leak.
"One possible case would be if the underlying OS were to accept anything
you try to write into the socket..."
Sent from my iPhone
On Jan 8, 2013, at 9:21 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> One possible case would be if the underlying OS were to accept anything
> you try to write into the socke
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
I would add that just because you told the selectionKey to be ready for
a write by setting the OP_WRITE flag, and that the select() has been
interrupted because the underlying socket is ready to process a write
does not mean it's ready to be written when you try to do so : in the
mean time, the socket status might have changed.
I still don't see, from a technical point, how trying to write directly
into the socket could be problematic.
One possible case would be if the underlying OS were to accept anything
you try to write into the socket, even if the remote client does not
read anything, leading to data being stacked in memory. But I doubt any
decent system would ever do that...
Le 1/8/13 9:52 AM, Emmanuel Lécharny a écrit :
> Le 1/8/13 3:24 AM, Chad Beaulac a écrit :
>> On Jan 7, 2013, at 11:58 AM, Emmanuel Lécharny wrote:
>>
>>> Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
>>>> If you don't push the data onto a queue and wait for the selector to fire, you could be trying to write data to a socket that is congestion controlled, which you shouldn't do. The writer should wait for the selector to fire saying the socket is writable before trying to write.
>>> The thing is that in any case, we do try to write into the socket. If
>>> the socket internal buffer gets full, we won't be able to write any ore
>>> data into it, and we will have to wait for the socket to inform the
>>> selector when it's ready to accept more data.
>>>
>>> What I'm proposing is not any different, except that I bypass the queue
>>> *if* and only *if* the socket is ready to accept new data. In other
>>> words, the algorithm is :
>>> o if there is a queue containing messages waiting for the socket to be
>>> ready (OP_WRITE set ti true), then enqueue the new message.
>>> o else try to write the message into the socket
>>> - if we can't write the full message, set the SelectionKey to be
>>> interested in OP_WRITE, and enqueue the remaining data.
>>> - Otherwise, the data have already been written anyway, we are done
>>>
>>> This is the way MINA 2 works since it's inception.
>>>
>>> Is there anything wrong with that ?
>>>
>> Potentially. You should not attempt to write to the socket unless the OP_WRITE selector key says the socket is writable. If the selector has fired and says the socket is writable before you try to write, it's not a problem. Otherwise, you should queue the data, let the Selector fire and then try to write. I don't see any way around queuing the data.
> Technically, in MINA 3, and in MINA 2, and in Netty, we actually *write*
> the data, then set the OP_WRITE if we weren't able to write the data
> into the socket, so when the socket is ready fro write, we can try
> again. In this case, the data are enqueued.
>
> But the fact is that it worked for years, without any problem.
>
>> You never want to try to write to a socket that is writable. If it isn't writable, it's closed or congestion controlled. This "edge-triggered" I/O approach works well. You don't know what "edge" you're on if you haven't registered for an event before you try to write.
> If the socket is not writable, then trying to write into it will just
> return 0. You immediately know that you should differ the write.
>
> Still trying to see where it can be a problem...
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 1/8/13 3:24 AM, Chad Beaulac a écrit :
> On Jan 7, 2013, at 11:58 AM, Emmanuel Lécharny wrote:
>
>> Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
>>> If you don't push the data onto a queue and wait for the selector to fire, you could be trying to write data to a socket that is congestion controlled, which you shouldn't do. The writer should wait for the selector to fire saying the socket is writable before trying to write.
>> The thing is that in any case, we do try to write into the socket. If
>> the socket internal buffer gets full, we won't be able to write any ore
>> data into it, and we will have to wait for the socket to inform the
>> selector when it's ready to accept more data.
>>
>> What I'm proposing is not any different, except that I bypass the queue
>> *if* and only *if* the socket is ready to accept new data. In other
>> words, the algorithm is :
>> o if there is a queue containing messages waiting for the socket to be
>> ready (OP_WRITE set ti true), then enqueue the new message.
>> o else try to write the message into the socket
>> - if we can't write the full message, set the SelectionKey to be
>> interested in OP_WRITE, and enqueue the remaining data.
>> - Otherwise, the data have already been written anyway, we are done
>>
>> This is the way MINA 2 works since it's inception.
>>
>> Is there anything wrong with that ?
>>
> Potentially. You should not attempt to write to the socket unless the OP_WRITE selector key says the socket is writable. If the selector has fired and says the socket is writable before you try to write, it's not a problem. Otherwise, you should queue the data, let the Selector fire and then try to write. I don't see any way around queuing the data.
Technically, in MINA 3, and in MINA 2, and in Netty, we actually *write*
the data, then set the OP_WRITE if we weren't able to write the data
into the socket, so when the socket is ready fro write, we can try
again. In this case, the data are enqueued.
But the fact is that it worked for years, without any problem.
> You never want to try to write to a socket that is writable. If it isn't writable, it's closed or congestion controlled. This "edge-triggered" I/O approach works well. You don't know what "edge" you're on if you haven't registered for an event before you try to write.
If the socket is not writable, then trying to write into it will just
return 0. You immediately know that you should differ the write.
Still trying to see where it can be a problem...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 1/8/13 3:13 PM, Chad Beaulac a écrit :
> Non-blocking mode for all sockets for sure. I like the algorithm. Seems like you almost certainly still avoid trying to write multiple times to a congestion controlled socket which must not happen.
Yes, this is exactly what we do. The kind of stuff that would be
absolutely atrocious would be the approach that Jean-François Arcand is
depicting as an error :
http://jfarcand.wordpress.com/2006/05/30/tricks-and-tips-with-nio-part-i-why-you-must-handle-op_write/
You have to avoid such a behavior, and that means you have to use a
queue *if* you can't write all your data directly.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Chad Beaulac <ca...@gmail.com>.
Non-blocking mode for all sockets for sure. I like the algorithm. Seems like you almost certainly still avoid trying to write multiple times to a congestion controlled socket which must not happen. I'll modify my code to try your slightly different approach.
Chad
Sent from my iPhone
On Jan 8, 2013, at 3:45 AM, Julien Vermillard <jv...@gmail.com> wrote:
> the trick is to try to write first with the socket configured in non
> blocking mode, so if it's congestion controlled , the write will
> fail instantaneously so we en-queue the message and set the OP_WRITE flag
> on the selection key.
>
>
> On Tue, Jan 8, 2013 at 3:24 AM, Chad Beaulac <ca...@gmail.com> wrote:
>
>>
>> On Jan 7, 2013, at 11:58 AM, Emmanuel Lécharny wrote:
>>
>>> Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
>>>> If you don't push the data onto a queue and wait for the selector to
>> fire, you could be trying to write data to a socket that is congestion
>> controlled, which you shouldn't do. The writer should wait for the selector
>> to fire saying the socket is writable before trying to write.
>>>
>>> The thing is that in any case, we do try to write into the socket. If
>>> the socket internal buffer gets full, we won't be able to write any ore
>>> data into it, and we will have to wait for the socket to inform the
>>> selector when it's ready to accept more data.
>>>
>>> What I'm proposing is not any different, except that I bypass the queue
>>> *if* and only *if* the socket is ready to accept new data. In other
>>> words, the algorithm is :
>>> o if there is a queue containing messages waiting for the socket to be
>>> ready (OP_WRITE set ti true), then enqueue the new message.
>>> o else try to write the message into the socket
>>> - if we can't write the full message, set the SelectionKey to be
>>> interested in OP_WRITE, and enqueue the remaining data.
>>> - Otherwise, the data have already been written anyway, we are done
>>>
>>> This is the way MINA 2 works since it's inception.
>>>
>>> Is there anything wrong with that ?
>>
>> Potentially. You should not attempt to write to the socket unless the
>> OP_WRITE selector key says the socket is writable. If the selector has
>> fired and says the socket is writable before you try to write, it's not a
>> problem. Otherwise, you should queue the data, let the Selector fire and
>> then try to write. I don't see any way around queuing the data.
>> You never want to try to write to a socket that is writable. If it isn't
>> writable, it's closed or congestion controlled. This "edge-triggered" I/O
>> approach works well. You don't know what "edge" you're on if you haven't
>> registered for an event before you try to write.
>>
>> Pseudocode Algorithm.
>>
>> // Client provides data to this class to output onto the socket.
>> public synchronized void put(Data data) {
>> if (queue.isEmpty) {
>> register(key, OP_WRITE); // output queue is empty. We need to
>> register for the write event so the OS can tell us when it's ok to write.
>> enqueue(data); // Put the data onto the ConcurrentLinkedQueue
>> }
>> else {
>> enqueue(data); // Just put the data onto the queue. We're already
>> registered for the write event.
>> }
>> }
>>
>> public void runEventLoop() {
>> // handle events on Selector
>> }
>>
>>
>> // OP_WRITE fired for key
>> public synchronized void writeData(key) {
>> while (!queue.isEmpty()) {
>> Data data = queue.dequeue();
>> writeForKey(key,data);
>> if (data.remaining() > 0) {
>> enqueue(data);
>> break; // socket is congestion controlled. We're still
>> registered for the write event. When the TCP queue drains, the write event
>> will fire again
>> }
>> }
>> if (queue.isEmpty()) {
>> unregister(key, OP_WRITE); // We don't have data to write to
>> this socket anymore. Unregister for the write event.
>> }
>> }
>>
>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>
>> Chad Beaulac
>> Objective Solutions, Inc.
>> www.objectivesolutions.com
>> chad@objectivesolutions.com
>>
>>
>>
>>
>>
>>
>>
Re: [MINA3] Writting messages directly : some pb
Posted by Julien Vermillard <jv...@gmail.com>.
the trick is to try to write first with the socket configured in non
blocking mode, so if it's congestion controlled , the write will
fail instantaneously so we en-queue the message and set the OP_WRITE flag
on the selection key.
On Tue, Jan 8, 2013 at 3:24 AM, Chad Beaulac <ca...@gmail.com> wrote:
>
> On Jan 7, 2013, at 11:58 AM, Emmanuel Lécharny wrote:
>
> > Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
> >> If you don't push the data onto a queue and wait for the selector to
> fire, you could be trying to write data to a socket that is congestion
> controlled, which you shouldn't do. The writer should wait for the selector
> to fire saying the socket is writable before trying to write.
> >
> > The thing is that in any case, we do try to write into the socket. If
> > the socket internal buffer gets full, we won't be able to write any ore
> > data into it, and we will have to wait for the socket to inform the
> > selector when it's ready to accept more data.
> >
> > What I'm proposing is not any different, except that I bypass the queue
> > *if* and only *if* the socket is ready to accept new data. In other
> > words, the algorithm is :
> > o if there is a queue containing messages waiting for the socket to be
> > ready (OP_WRITE set ti true), then enqueue the new message.
> > o else try to write the message into the socket
> > - if we can't write the full message, set the SelectionKey to be
> > interested in OP_WRITE, and enqueue the remaining data.
> > - Otherwise, the data have already been written anyway, we are done
> >
> > This is the way MINA 2 works since it's inception.
> >
> > Is there anything wrong with that ?
> >
>
> Potentially. You should not attempt to write to the socket unless the
> OP_WRITE selector key says the socket is writable. If the selector has
> fired and says the socket is writable before you try to write, it's not a
> problem. Otherwise, you should queue the data, let the Selector fire and
> then try to write. I don't see any way around queuing the data.
> You never want to try to write to a socket that is writable. If it isn't
> writable, it's closed or congestion controlled. This "edge-triggered" I/O
> approach works well. You don't know what "edge" you're on if you haven't
> registered for an event before you try to write.
>
> Pseudocode Algorithm.
>
> // Client provides data to this class to output onto the socket.
> public synchronized void put(Data data) {
> if (queue.isEmpty) {
> register(key, OP_WRITE); // output queue is empty. We need to
> register for the write event so the OS can tell us when it's ok to write.
> enqueue(data); // Put the data onto the ConcurrentLinkedQueue
> }
> else {
> enqueue(data); // Just put the data onto the queue. We're already
> registered for the write event.
> }
> }
>
> public void runEventLoop() {
> // handle events on Selector
> }
>
>
> // OP_WRITE fired for key
> public synchronized void writeData(key) {
> while (!queue.isEmpty()) {
> Data data = queue.dequeue();
> writeForKey(key,data);
> if (data.remaining() > 0) {
> enqueue(data);
> break; // socket is congestion controlled. We're still
> registered for the write event. When the TCP queue drains, the write event
> will fire again
> }
> }
> if (queue.isEmpty()) {
> unregister(key, OP_WRITE); // We don't have data to write to
> this socket anymore. Unregister for the write event.
> }
> }
>
>
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
> Chad Beaulac
> Objective Solutions, Inc.
> www.objectivesolutions.com
> chad@objectivesolutions.com
>
>
>
>
>
>
>
Re: [MINA3] Writting messages directly : some pb
Posted by Chad Beaulac <ca...@gmail.com>.
On Jan 7, 2013, at 11:58 AM, Emmanuel Lécharny wrote:
> Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
>> If you don't push the data onto a queue and wait for the selector to fire, you could be trying to write data to a socket that is congestion controlled, which you shouldn't do. The writer should wait for the selector to fire saying the socket is writable before trying to write.
>
> The thing is that in any case, we do try to write into the socket. If
> the socket internal buffer gets full, we won't be able to write any ore
> data into it, and we will have to wait for the socket to inform the
> selector when it's ready to accept more data.
>
> What I'm proposing is not any different, except that I bypass the queue
> *if* and only *if* the socket is ready to accept new data. In other
> words, the algorithm is :
> o if there is a queue containing messages waiting for the socket to be
> ready (OP_WRITE set ti true), then enqueue the new message.
> o else try to write the message into the socket
> - if we can't write the full message, set the SelectionKey to be
> interested in OP_WRITE, and enqueue the remaining data.
> - Otherwise, the data have already been written anyway, we are done
>
> This is the way MINA 2 works since it's inception.
>
> Is there anything wrong with that ?
>
Potentially. You should not attempt to write to the socket unless the OP_WRITE selector key says the socket is writable. If the selector has fired and says the socket is writable before you try to write, it's not a problem. Otherwise, you should queue the data, let the Selector fire and then try to write. I don't see any way around queuing the data.
You never want to try to write to a socket that is writable. If it isn't writable, it's closed or congestion controlled. This "edge-triggered" I/O approach works well. You don't know what "edge" you're on if you haven't registered for an event before you try to write.
Pseudocode Algorithm.
// Client provides data to this class to output onto the socket.
public synchronized void put(Data data) {
if (queue.isEmpty) {
register(key, OP_WRITE); // output queue is empty. We need to register for the write event so the OS can tell us when it's ok to write.
enqueue(data); // Put the data onto the ConcurrentLinkedQueue
}
else {
enqueue(data); // Just put the data onto the queue. We're already registered for the write event.
}
}
public void runEventLoop() {
// handle events on Selector
}
// OP_WRITE fired for key
public synchronized void writeData(key) {
while (!queue.isEmpty()) {
Data data = queue.dequeue();
writeForKey(key,data);
if (data.remaining() > 0) {
enqueue(data);
break; // socket is congestion controlled. We're still registered for the write event. When the TCP queue drains, the write event will fire again
}
}
if (queue.isEmpty()) {
unregister(key, OP_WRITE); // We don't have data to write to this socket anymore. Unregister for the write event.
}
}
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Chad Beaulac
Objective Solutions, Inc.
www.objectivesolutions.com
chad@objectivesolutions.com
Re: [MINA3] Writting messages directly : some pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 1/7/13 2:19 PM, Chad Beaulac a écrit :
> If you don't push the data onto a queue and wait for the selector to fire, you could be trying to write data to a socket that is congestion controlled, which you shouldn't do. The writer should wait for the selector to fire saying the socket is writable before trying to write.
The thing is that in any case, we do try to write into the socket. If
the socket internal buffer gets full, we won't be able to write any ore
data into it, and we will have to wait for the socket to inform the
selector when it's ready to accept more data.
What I'm proposing is not any different, except that I bypass the queue
*if* and only *if* the socket is ready to accept new data. In other
words, the algorithm is :
o if there is a queue containing messages waiting for the socket to be
ready (OP_WRITE set ti true), then enqueue the new message.
o else try to write the message into the socket
- if we can't write the full message, set the SelectionKey to be
interested in OP_WRITE, and enqueue the remaining data.
- Otherwise, the data have already been written anyway, we are done
This is the way MINA 2 works since it's inception.
Is there anything wrong with that ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA3] Writting messages directly : some pb
Posted by Chad Beaulac <ca...@gmail.com>.
If you don't push the data onto a queue and wait for the selector to fire, you could be trying to write data to a socket that is congestion controlled, which you shouldn't do. The writer should wait for the selector to fire saying the socket is writable before trying to write.
Chad Beaulac
Objective Solutions, Inc.
www.objectivesolutions.com
chad@objectivesolutions.com
On Jan 7, 2013, at 4:20 AM, Julien Vermillard wrote:
> I have another problem (probably hitting you too) with the Idle event wich
> is spawned from another thread (the idle checker thread). we should perhaps
> pass message to the selector and wake it.
>
>
>
>
> On Mon, Jan 7, 2013 at 6:42 AM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Hi !
>>
>> as you know, I was modifying the code to write the messages directly
>> into the channel instead of pushing it into a queue, and wait for the
>> SelectorLoop to process it. So far, so good it works well, except that
>> the messageSent( event is difficult to generate.
>>
>> Whe we push the message into a queue, what happens is that we feed the
>> DefaultWriteRequest with the original message (ie before it goes through
>> the codec filter), and we also add a future into it. This is done
>> *after* the message has been enqueued. Why ? Because in
>> AbstractIoSession.processMessageWriting(), we get back the enqueued
>> message using the lastWriteRequest, which is produced by the
>> AbstractIoSession.enqueueFinalWriteMessage().
>>
>> Now, the messageSent() event will be produced by the selectorLoop() when
>> it process the message to write, pollingit from the queue. At thsi
>> point, this message has everything needed : the data tow rite, the
>> original data and teh future.
>>
>> But when we write the message directly, we don't have the future nor the
>> original message, yet, but still we have to generate the messageSent
>> event. This is problematic...
>>
>> Here, what I suggest, is that the original message is to be passed
>> through the full chain of filters, so that we can update it in any case.
>> That would probably mean that the AbstractIoSession.doWriteWithFuture()
>> create this envelop, feed it with the original message and the future,
>> and pass this object down the chain.
>>
>> I don't see any oher way to solve this issue. If any of you have any
>> better idea, I'm all ears :)
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
Re: [MINA3] Writting messages directly : some pb
Posted by Julien Vermillard <jv...@gmail.com>.
I have another problem (probably hitting you too) with the Idle event wich
is spawned from another thread (the idle checker thread). we should perhaps
pass message to the selector and wake it.
On Mon, Jan 7, 2013 at 6:42 AM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Hi !
>
> as you know, I was modifying the code to write the messages directly
> into the channel instead of pushing it into a queue, and wait for the
> SelectorLoop to process it. So far, so good it works well, except that
> the messageSent( event is difficult to generate.
>
> Whe we push the message into a queue, what happens is that we feed the
> DefaultWriteRequest with the original message (ie before it goes through
> the codec filter), and we also add a future into it. This is done
> *after* the message has been enqueued. Why ? Because in
> AbstractIoSession.processMessageWriting(), we get back the enqueued
> message using the lastWriteRequest, which is produced by the
> AbstractIoSession.enqueueFinalWriteMessage().
>
> Now, the messageSent() event will be produced by the selectorLoop() when
> it process the message to write, pollingit from the queue. At thsi
> point, this message has everything needed : the data tow rite, the
> original data and teh future.
>
> But when we write the message directly, we don't have the future nor the
> original message, yet, but still we have to generate the messageSent
> event. This is problematic...
>
> Here, what I suggest, is that the original message is to be passed
> through the full chain of filters, so that we can update it in any case.
> That would probably mean that the AbstractIoSession.doWriteWithFuture()
> create this envelop, feed it with the original message and the future,
> and pass this object down the chain.
>
> I don't see any oher way to solve this issue. If any of you have any
> better idea, I'm all ears :)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>