[
https://issues.apache.org/jira/browse/DIRMINA-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-792:
--------------------------------------
Description:
After some time of operation the following code waits forever.
{code}
WriteFuture wf = getSession().write(message);
wf.await();
{code}
I have an application that successfully sends between 20-200 messages before
running into the await() forever situation. What I saw with a network sniffer
is that the TCP-ACK for the message has send by the receiving application.
Since we have the same situation with multiple configurations, over company
LAN, direct ethernet connection and both applications on the same machine I
think it is not a network problem. What we saw at the log is that the TCP-ACK
took more than 150ms before the call blocks.
I replaced the await code with wf.await(100L) which comes back but
wf.isWritten() is still false. I'm not sure about the consequences of not
waiting for the data to be written to the TCP-stack. Is this what await() does?
I tried to find the connection between the real write operation and the future
but gave up. I could not even log the queue size or any other debug
information. If somebody knows which of the accessible values makes sense to
log or how to reschedule the read request, add a comment.
was:
After some time of operation the following code waits forever.
WriteFuture wf = getSession().write(message);
wf.await();
I have an application that successfully sends between 20-200 messages before
running into the await() forever situation. What I saw with a network sniffer
is that the TCP-ACK for the message has send by the receiving application.
Since we have the same situation with multiple configurations, over company
LAN, direct ethernet connection and both applications on the same machine I
think it is not a network problem. What we saw at the log is that the TCP-ACK
took more than 150ms before the call blocks.
I replaced the await code with wf.await(100L) which comes back but
wf.isWritten() is still false. I'm not sure about the consequences of not
waiting for the data to be written to the TCP-stack. Is this what await() does?
I tried to find the connection between the real write operation and the future
but gave up. I could not even log the queue size or any other debug
information. If somebody knows which of the accessible values makes sense to
log or how to reschedule the read request, add a comment.
> await() forever
> ---------------
>
> Key: DIRMINA-792
> URL: https://issues.apache.org/jira/browse/DIRMINA-792
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0-RC1
> Environment: java 6, Windows XP, 32 Bit
> Reporter: Haug Bürger
> Fix For: 2.0.8
>
>
> After some time of operation the following code waits forever.
> {code}
> WriteFuture wf = getSession().write(message);
> wf.await();
> {code}
> I have an application that successfully sends between 20-200 messages before
> running into the await() forever situation. What I saw with a network sniffer
> is that the TCP-ACK for the message has send by the receiving application.
> Since we have the same situation with multiple configurations, over company
> LAN, direct ethernet connection and both applications on the same machine I
> think it is not a network problem. What we saw at the log is that the TCP-ACK
> took more than 150ms before the call blocks.
> I replaced the await code with wf.await(100L) which comes back but
> wf.isWritten() is still false. I'm not sure about the consequences of not
> waiting for the data to be written to the TCP-stack. Is this what await()
> does?
> I tried to find the connection between the real write operation and the
> future but gave up. I could not even log the queue size or any other debug
> information. If somebody knows which of the accessible values makes sense to
> log or how to reschedule the read request, add a comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
