[netty-users] write() method on channels ordered?

[Trustin Lee]

Hi Matt,

I gave you an answer already in the IRC channel, but let me paste it here so
that everyone can benefit from our conversation.

trustin_> vatic42: yes.  there is a write request queue for each channel so
you can call write() simultaneously.
<vatic42> trustin_: so no, it's not possible you mean?
<trustin_> vatic42: possible.
<vatic42> trustin_: I'm confused -- what does the write request queue do,
then?
<trustin_> vatic42: it's queued and the write method will return immediately
<trustin_> vatic42: I/O thread will pick it up in background.
<vatic42> write("a"); write("b");
<vatic42> will "a" always be written before "b"?
<trustin_> yes
<vatic42> ok
<vatic42> out of curiosity is that obvious? was I just being dense?
<trustin_> I seems like you meant 'overlap' by data being messed up.
<trustin_> Perhaps I misunderstood the first question. :)
<vatic42> well
<trustin_> anyway, the behavior I explained is perhaps universal to most NIO
frameworks.
<vatic42> let me explain what prompted me to ask the question
<trustin_> OK
<vatic42> in one of the examples, you do a write and then add a listener to
the returned future to do the close afterwards, with the explanation that if
you don't do that then the close might happen first
<trustin_> Hmm yes.
<vatic42> this made me wonder whether if you do two writes, whether they
could be done out of order
<vatic42> in the same fashion
<trustin_> close and writes are treated differently.
<trustin_> you can close even before the write request queue is flushed out.
<trustin_> otherwise your connection will never get closed if the write
operation is hung up for some reason (slow network etc etc).
<vatic42> I see, that makes sense
<trustin_> so calling close() will close the connection immediately and all
the queued write requests will fail.
<vatic42> right
<trustin_> But there's also a case where you want to close after the last
message is sent (like bye-bye).  Then you can choose to use
ChannelFutureListener.CLOSE. :)
<vatic42> I see
<vatic42> are the semantics of these things detailed someplace?
<trustin_> not yet documented that clearly unfortunately, but you can always
ask a question here or in the forum.
<vatic42> ok, just making sure I wasn't missing something
<vatic42> let's say I want to close a channel
<trustin_> It was a great question. :)
<vatic42> but I want the writes that I've already done so far to finish
<vatic42> can I just do an empty write and wait on that future?
<vatic42> or is there a way to get a handle to the future for the last write
I did on that channel?
<trustin_> Hmm.. that should work.
<trustin_> If it doesn't work.. then let me know.
<vatic42> k
<trustin_> You need to remember somehow by yourself.  I'd suggest to write
an empty buffer.
<vatic42> k
<vatic42> trustin_: if an exceptionCaught event is raised, is that always
followed by a channelDisconnected event?  or is it my responsibility to
close the channel after something like that happens?
<trustin_> vatic42: if the exception is an IOException that is raised during
socket I/O, then the connection is always closed and channelDisconnected
event will be fired.
<trustin_> vatic42: Otherwise, only exceptionCaught event will be fired.
<vatic42> is there any other time channelDisconnected would be called?
<vatic42> er, fired rather
<trustin_> when a connection is closed?
<trustin_> closed somehow like closed by a remote peer or when you called
channel.close().
<vatic42> ok, I was thinking that only connectionClosed would be called if
you directly called close() on the channel
<trustin_> actually channel.close() will trigger channelUnbound,
channelDisconnected, and channelClosed.
<trustin_> Likewise, channelOpen, channelBound, and channelConnected will be
triggered when a connection is ready to communicate.
<vatic42> what about when a remote peer closes the connection?
<vatic42> same thing?
<trustin_> yes. same thing. :)
<vatic42> or do I still have to close my side of the connection?
<vatic42> ok, so no half open connections with netty, then
<trustin_> right.
<trustin_> is a half open connection useful?
<vatic42> heh
<vatic42> only in the rarest of circumstances, I'm sure
<vatic42> sorry, I didn't mean it was a negative
<vatic42> I don't think it's worth supporting in a high level framework like
netty
<trustin_> no worries. :)
<trustin_> You don't need to say sorry.
<trustin_> I was just curious
<vatic42> k :)


matt-13 wrote:
> 
> Hi,
> 
> Question about the write() method on channels.  Is it possible that
> two writes to the same channel might overlap if you don't wait for the
> first write's future to say it's done?  Or will writes on the same
> channel always be performed in the same order that they are called?
> 
> Thanks,
> Matt
> 
> 

-- 
View this message in context: http://n2.nabble.com/write%28%29-method-on-channels-ordered--tp1476144p1476317.html
Sent from the Netty User Group mailing list archive at Nabble.com.