Mina Server and Client on same machine stop communicating on large amounts of
data
----------------------------------------------------------------------------------
Key: DIRMINA-865
URL: https://issues.apache.org/jira/browse/DIRMINA-865
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.4
Environment: Tested on Fedora 15 and Windows 7.
Reporter: Bjarke B. Blendstrup
I have two small test programs both using MINA. The Server accepts connections
on a port. When clients connect, the server sends a large amount of small
messages (approx. 1000 a second). The client simply echoes the recieved
messages to std out. The server echoes getScheduledWriteMessages() for each
client session approx. once every 10 seconds.
When the simple version of the setup runs, the client always keeps up with the
server - no problem. BUT if I introduce a small burst of messages, 50 messages
every 1 second sent without delays, on top of the 1000 a second, something
wierd happens.The number of scheduled write messages starts to increase AND
NEVER decrease again.
The "funny" thing is that this ONLY happens when the client and server run on
the same machine (both linux and windows). If they comm. across a network, this
*never* happens.
This is the output from my server with two clients connected. One client is on
the same machine as the server, the other on another machine on the LAN.
Wed Oct 05 15:16:56 CEST 2011: 0/0
Wed Oct 05 15:16:56 CEST 2011: 1428/28
Wed Oct 05 15:16:58 CEST 2011: 2550/50
Wed Oct 05 15:16:58 CEST 2011: 1683/33
Wed Oct 05 15:16:59 CEST 2011: 918/18
Wed Oct 05 15:16:59 CEST 2011: 2346/46
Wed Oct 05 15:17:00 CEST 2011: 1377/27
Wed Oct 05 15:17:00 CEST 2011: 2193/43
Wed Oct 05 15:17:01 CEST 2011: 2550/50
Wed Oct 05 15:17:01 CEST 2011: 2550/50
Wed Oct 05 15:17:03 CEST 2011: 2550/50
Wed Oct 05 15:17:03 CEST 2011: 2550/50
Wed Oct 05 15:17:04 CEST 2011: 2550/50
Wed Oct 05 15:17:04 CEST 2011: 1989/39
Wed Oct 05 15:17:05 CEST 2011: 2550/50
Wed Oct 05 15:17:05 CEST 2011: 1683/33
Wed Oct 05 15:17:06 CEST 2011: 2550/50
Wed Oct 05 15:17:06 CEST 2011: 2550/50
Wed Oct 05 15:17:07 CEST 2011: 2550/50
Wed Oct 05 15:17:07 CEST 2011: 2550/50
Wed Oct 05 15:17:09 CEST 2011: 0/0
Wed Oct 05 15:17:09 CEST 2011: 2550/50
Wed Oct 05 15:17:10 CEST 2011: 2550/50
Wed Oct 05 15:17:10 CEST 2011: 2550/50
Wed Oct 05 15:17:11 CEST 2011: 1836/36
Wed Oct 05 15:17:11 CEST 2011: 2193/44
Wed Oct 05 15:17:12 CEST 2011: 1785/35
Wed Oct 05 15:17:12 CEST 2011: 4641/91
Wed Oct 05 15:17:14 CEST 2011: 2499/49
Wed Oct 05 15:17:14 CEST 2011: 6681/131
Wed Oct 05 15:17:15 CEST 2011: 1989/39
Wed Oct 05 15:17:15 CEST 2011: 56326/1105
Wed Oct 05 15:17:16 CEST 2011: 1530/30
Wed Oct 05 15:17:16 CEST 2011: 93441/1833
Wed Oct 05 15:17:17 CEST 2011: 1734/34
Wed Oct 05 15:17:17 CEST 2011: 130556/2560
Wed Oct 05 15:17:18 CEST 2011: 1785/35
Wed Oct 05 15:17:18 CEST 2011: 184055/3609
Wed Oct 05 15:17:20 CEST 2011: 1734/34
Wed Oct 05 15:17:20 CEST 2011: 221170/4337
Wed Oct 05 15:17:21 CEST 2011: 1836/36
Wed Oct 05 15:17:21 CEST 2011: 258285/5065
Wed Oct 05 15:17:22 CEST 2011: 1734/34
Wed Oct 05 15:17:22 CEST 2011: 311784/6114
Wed Oct 05 15:17:23 CEST 2011: 2550/50
Wed Oct 05 15:17:23 CEST 2011: 348899/6842
Wed Oct 05 15:17:25 CEST 2011: 2550/50
Wed Oct 05 15:17:25 CEST 2011: 386014/7569
Wed Oct 05 15:17:26 CEST 2011: 1734/34
Wed Oct 05 15:17:26 CEST 2011: 439513/8618
Wed Oct 05 15:17:27 CEST 2011: 1581/28
Wed Oct 05 15:17:27 CEST 2011: 476628/9346
Wed Oct 05 15:17:28 CEST 2011: 1887/36
Wed Oct 05 15:17:28 CEST 2011: 513743/10074
Wed Oct 05 15:17:29 CEST 2011: 2550/50
Wed Oct 05 15:17:29 CEST 2011: 567242/11123
Wed Oct 05 15:17:31 CEST 2011: 2550/50
Wed Oct 05 15:17:31 CEST 2011: 604357/11851
Wed Oct 05 15:17:32 CEST 2011: 2550/50
Wed Oct 05 15:17:32 CEST 2011: 641472/12578
Wed Oct 05 15:17:33 CEST 2011: 1836/36
Wed Oct 05 15:17:33 CEST 2011: 692733/13583
Wed Oct 05 15:17:34 CEST 2011: 1734/34
Wed Oct 05 15:17:34 CEST 2011: 732086/14355
Wed Oct 05 15:17:36 CEST 2011: 2040/40
Wed Oct 05 15:17:36 CEST 2011: 769201/15083
Wed Oct 05 15:17:37 CEST 2011: 1734/34
Wed Oct 05 15:17:37 CEST 2011: 817122/16022
Wed Oct 05 15:17:38 CEST 2011: 1836/36
Wed Oct 05 15:17:38 CEST 2011: 859815/16860
Wed Oct 05 15:17:39 CEST 2011: 2499/49
Wed Oct 05 15:17:39 CEST 2011: 896930/17587
Wed Oct 05 15:17:41 CEST 2011: 1173/23
Wed Oct 05 15:17:41 CEST 2011: 943449/18499
Wed Oct 05 15:17:42 CEST 2011: 2550/50
Wed Oct 05 15:17:42 CEST 2011: 987544/19364
Wed Oct 05 15:17:43 CEST 2011: 1632/32
Wed Oct 05 15:17:43 CEST 2011: 1024659/20092
Wed Oct 05 15:17:44 CEST 2011: 2550/50
Wed Oct 05 15:17:44 CEST 2011: 1068756/20956
Wed Oct 05 15:17:45 CEST 2011: 1938/38
Wed Oct 05 15:17:45 CEST 2011: 1115273/21869
Wed Oct 05 15:17:47 CEST 2011: 2550/50
Wed Oct 05 15:17:47 CEST 2011: 1152388/22596
Wed Oct 05 15:17:48 CEST 2011: 969/19
Wed Oct 05 15:17:48 CEST 2011: 1194267/23417
Wed Oct 05 15:17:49 CEST 2011: 1785/35
Wed Oct 05 15:17:49 CEST 2011: 1243002/24373
Wed Oct 05 15:17:50 CEST 2011: 1530/30
Wed Oct 05 15:17:50 CEST 2011: 1280117/25101
Wed Oct 05 15:17:52 CEST 2011: 2550/50
Wed Oct 05 15:17:52 CEST 2011: 1319319/25869
Wed Oct 05 15:17:53 CEST 2011: 1632/32
Wed Oct 05 15:17:53 CEST 2011: 1370731/26878
Wed Oct 05 15:17:54 CEST 2011: 2550/50
You can see here the number of messages queued start increasing, and no matter
how long the test runs, it will never decrease again.
Another fun fact is that if I use telnet as a client, this never happens either
- no matter if the telnet is running on same machine or not.
This may seem as a very stupid test case, but it is a very good simulation of
the behaviour of the system I am trying to build. I hope you can see from the
code whether the fault is mine or not!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
