Strange behaviour with netty in .net (using ikvm)

["Trustin Lee (이희승)"]

Hi Leandro,

There is a queue for write requests per channel.  However, the write
request is removed from the queue before notifying the associated
ChannelFuture.

Perhaps you could try to switch from NioClientSocketChannelFactory to
OioClientSocketChannelFactory to see if it works then?  The OIO socket
transport does not use any queue.

Also, you might want to replace LinkedTransferQueue in Netty with other
thread-safe queue implementation such as ConcurrentLinkedQueue.  LTQ
seemed to malfunction when translated by the tools like Retroweaver last
time I heard.  You'll have to build Netty to try this path, but please
take your time and let me know - I'm curious if this is really the cause
of the problem.

HTH,
Trustin

Leandro Cruz wrote:
> Hi Trustin.
> 
> The other peer is the server. Our problem is in the client side.
> I bet the server is working fine. When I test it locally everything
> works fine.
> I was suspicious about our code, but I noticed that there is some
> queue/buffer inside Netty or Socket that is buffering the data. This
> buffered data is being lost or jammed.
> Is there any buffer of this kind in netty?
> 
> --
> Leandro Rodrigo Saad Cruz
> 
> 
> On Tue, Apr 6, 2010 at 10:05 AM, "Trustin Lee (이희승)"
> <trustin at gmail.com <mailto:trustin at gmail.com>> wrote:
> 
>     Hi Leandro,
> 
>     If operationComplete() has been called with successful future (i.e.
>     future.isSuccess() == true), it means SocketChannel.write() has been
>     succeeded without a problem.  No additional action is required to make
>     sure the write is successful.
> 
>     If the peer really did not receive anything, I suspect a problem in the
>     peer (client?).  You could use a packet analyzer like WireShark to make
>     sure that there is no traffic - the peer might simply not be reading the
>     data.
> 
>     HTH,
>     Trustin
> 
>     Leandro Cruz wrote:
>     > Hi all.
>     >
>     > We switched from mina to netty lately. We wrote a small
>     client/server app
>     > that fragments binary data to send back and forth.
>     > When running from java the process seems to work pretty smoothly.
>     But when
>     > we compile it to .net using ikvm the write queue seems jammed.
>     >
>     > In our code we call channel.write multiple times and
>     > our ChannelFutureListener.operationComplete() is always
>     successful, but the
>     > message is not actually written to the other end.
>     >
>     > I know this problem is strictly related to ikvm, not netty. But
>     I'd like to
>     > ask if there is anything that could be done to make sure the
>     message is
>     > written to the socket. Is there any write queue that I could
>     configure? Any
>     > know bug related to this scenario?
>     >
>     > Cheers!
>     >
>     > --
>     > Leandro Rodrigo Saad Cruz
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > netty-users mailing list
>     > netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/netty-users
> 
>     --
>     what we call human nature in actuality is human habit
>     http://gleamynode.net/
> 
> 
> 
>     _______________________________________________
>     netty-users mailing list
>     netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100413/e5d3ea25/attachment-0001.bin