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

[Trustin Lee]

This conversation should be documented more clearly in the user guide in the
future. :)


Trustin Lee wrote:
> 
> 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--tp1476144p1476319.html
Sent from the Netty User Group mailing list archive at Nabble.com.