|
Is this patch really applied? I cannot find it.
BTW it would be great if we can provide input/outputstream by default instead of using StreamIoHandler which forces users to choose only one approach. In some cases users want to use both asynchronous and synchronous I/O for maximum compatibility. WDYT? < TW it would be great if we can provide input/outputstream by default instead of using StreamIoHandler which forces users to choose only one approach. In some cases users want to use both asynchronous and synchronous I/O for maximum compatibility. WDYT?
Would be real cool ! ;) No, I hasn't been checked in yet. I should have made that clearer. I have applied the patch to my local tree and made some changes. The unit test hasn't been completed yet. I won't check it in until the test is finished.
About input/outputstream. I'm not sure I understand what you mean? Should there be methods like IoSession.getInputStream()/IoSession.getOutputStream()? It would be great if user can switch IoHandler mode and InputStream/OutputStream mode very easy.
What about providing SwitchingIoHandler? SwitchingIoHandler handler = ...; handler.setHandler( new MyIoHandler() ); // Set default one ... handler.setHandler( new StreamIoHandler() {...}); // Change the handler I guess this is the simplest solution. WDYT? > What about providing SwitchingIoHandler?
> handler.setHandler( new MyIoHandler() ); // Set default one > ... > handler.setHandler( new StreamIoHandler() {...}); // Change the handler I don't dig sooo deep in this topic, but some initial thoughts... Is it useful to switch handlers per session ? Then you might switch filter chains to ? (fe you had object sersialization filter in MyIoHandler) Would it not make more sense to configure session for a) streams (blocking) or b.) events (non-blocking) ??? The filter StreamWriteFilter has been committed. Basically it allows you to write InputStream objects using session.write(). The filter will take care of reading the bytes from the stream, put them in a ByteBuffer and pass that buffer along to the next filter. IoHandler.messageSent() won't be called until all the bytes of the stream have been written. Bytes are read in 4k chunks from the stream by default. This is configurable.
For now I haven't looked into the SwitchingIoHandler feature. Maybe it would be better to open up a new issue for that? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
filter for writing streams
* The filter will now call nextFilter.messageSent once all the contents of the stream has been written.
* The filter won't close the stream. The IoHandler will have to take care of this in messageSent.
* The filter will throw IllegalStateException if one tries to write something while there's a stream being worked on.
* The advances property has been changed into a writeBufferSize property. I think that will make more sense to users.
I hope these changes are ok and that they will make the filter even more useful. I will check it into subversion as soon as I have updated the test.
Thank you, Johannes, for your contribution!