[
https://issues.apache.org/jira/browse/DIRMINA-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833897#action_12833897
]
Emmanuel Lecharny commented on DIRMINA-764:
-------------------------------------------
I did some tests with Netty and I don't get at all the 200 Kmsg/s you get.
Running the exact same client, with a 2 ms delay waiting for incoming messages
to be there, 100 threads, I top at 15 000 msg/s, 3 000 more than MINA. Now, if
I set the delay to 0, I top at 6 000 msg/s, but the good news is that NETTY
does not stale.
It seems that NETTY does have a way to throttle the throughput, someting we
have to implement in MINA.
> DDOS possible in only a few seconds...
> --------------------------------------
>
> Key: DIRMINA-764
> URL: https://issues.apache.org/jira/browse/DIRMINA-764
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.0-RC1
> Reporter: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> We can kill a server in just a few seconds using the stress test found in
> DIRMINA-762.
> If we inject messages with no delay, using 50 threads to do that, the
> ProtocolCodecFilter$MessageWriteRequest is stuffed with hundred of thousands
> messages waiting to be written back to the client, with no success.
> On the client side, we receive almost no messages :
> 0 messages/sec (total messages received 1)
> 2 messages/sec (total messages received 11)
> 8 messages/sec (total messages received 55)
> 8 messages/sec (total messages received 95)
> 9 messages/sec (total messages received 144)
> 3 messages/sec (total messages received 162)
> 1 messages/sec (total messages received 169)
> ...
> On the server side, the memory is totally swamped in 20 seconds, with no way
> to recover :
> Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: Java heap
> space
> (see graph attached)
> On the server, ConcurrentLinkedQueue contain the messages to be written (in
> my case, 724 499 Node are present). There are also 361629
> DefaultWriteRequests, 361628 DefaultWriteFutures, 361625 SimpleBuffer, 361
> 618 ProtocolCodecFilter$MessageWriteRequest and 361 614
> ProtocolCodecFilter$EncodedWriteRequests.
> That mean we don't flush them to the client at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
