I see,
no problem :)
The code you mentioned is called from AbstractAsyncQueueWriter, which is
controlling whether ByteBuffer was entirely written or not. If not it
re-registers OP_WRITE on the main selector, so ByteBuffer writing will
be resumed once channel get ready for next write. So ByteBuffer data
shouldn't get lost.
May be you can provide testcase, so we can reproduce the problem?
Thanks.
WBR,
Alexey.
On 02/07/2012 04:35 PM, Eric.Peiffer_at_alcatel-lucent.fr wrote:
> Hi,
>
> Thank you for your answer,
>
> The source is already wrote using the release 1.9 and I 'm afraid I do
> not have time to do this refactoring
>
> Regards,
>
> Eric.
>
>
>
> *Oleksiy Stashok <oleksiy.stashok_at_oracle.com>*
>
> 07/02/2012 16:16
> Please respond to
> users_at_grizzly.java.net
>
>
>
> To
> users_at_grizzly.java.net
> cc
>
> Subject
> Re:
>
>
>
>
>
>
>
>
>
> Hi,
>
> can I suggest you to use Grizzly 2.x (2.2.1 is the latest)?
> It provides nicer FilterChain based API and you wouldn't need to deal w/
> low-level NIO API.
>
> Here are the samples you may want to check:
> http://java.net/projects/grizzly/sources/git/show/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/
>
> Specifically GIOP sample might be interesting:
> http://java.net/projects/grizzly/sources/git/show/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/filterchain
>
> You can also check the user guide:
> http://grizzly.java.net/nonav/docs/docbkx2.2/html/grizzly-docs.html
>
> WBR,
> Alexey.
>
> > Hi I'm new in the grizzly framework, I use the grizzly framework
> > release 1.9.45 in order to develope an IMAP server.
> > In order to wite data to IMAP clients i use the following sample code:
> >
> > getSelectorHandler().getAsyncQueueWriter().write(key, b,
> > callbackHandler, response.getDataProcessor());
> >
> > the write method call the method doWrite in the class
> > TCPAsyncQueueWriter. here is the implementation if the doWrite method:
> >
> > protected OperationResult doWrite(WritableByteChannel channel,
> > SocketAddress dstAddress, ByteBuffer byteBuffer,
> > OperationResult dstResult) throws IOException {
> > int written = 0;
> > int lastWriteBytes = 0;
> > try{
> > do {
> > lastWriteBytes =
> channel.write(byteBuffer);
> > if (lastWriteBytes> 0) {
> > written += lastWriteBytes;
> > }
> >
> > } while(lastWriteBytes> 0&&
> byteBuffer.hasRemaining());
> > } catch (IOException ex){
> > lastWriteBytes = -1;
> > throw ex;
> > } finally {
> > if (lastWriteBytes == -1){
> > SelectionKeyHandler skh =
> > selectorHandler.getSelectionKeyHandler();
> > if (skh instanceof
> BaseSelectionKeyHandler){
> >
> >
> ((BaseSelectionKeyHandler)skh).notifyRemotlyClose(
> >
> > selectorHandler.keyFor((SelectableChannel)channel));
> > }
> > }
> > }
> > dstResult.bytesProcessed = written;
> > return dstResult;
> > }
> >
> > Under a heavy load,call to channel.write(byteBuffer) might be return
> > 0.
> > Therefor data that are not sent are lost. in order
> to fix this I have
> > wrote the following code in the doWrite method:
> >
> > ...
> > do {
> > int remaining =
> byteBuffer.remaining();
> > lastWriteBytes =
> channel.write(byteBuffer);
> > if (lastWriteBytes == 0&&
> remaining != 0) {
> > try {
> > counter++;
> > logger.error("Can
> not send data wait 100ms");
> > Thread.sleep(100);
> > } catch (InterruptedException
> ex) {
> >
> > }
> > }
> > if (lastWriteBytes> 0) {
> > written += lastWriteBytes;
> > }
> >
> > } while (lastWriteBytes>= 0&& counter< 100&&
> > byteBuffer.hasRemaining());
> > .....
> >
> > With this fix we try to resent data that was not sent..
> >
> > Other solution more "clean" would be to register an OP_WRITE interest
> > opt to a temporary Selector and wait for the temporary Selector to tell
> > you when the SocketChannel is ready for a write operation. but I d'ont
> > know how to implement this solution in the grizzly framework
> >
> > Are you any ohter Idee?
>
>