[
https://issues.apache.org/jira/browse/DIRMINA-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835754#action_12835754
]
Emmanuel Lecharny commented on DIRMINA-764:
-------------------------------------------
I now know why we process read way much that write, and never have time to
write data. The way the code is written in the core make it likely that we call
twice more time the read() method than the write() method.
The way it 'works' is that for each read message that produces a response, we
enqueue two messages to be flushed :
- the real response
- an empty marker to be able to process correctly the messageSent() event.
Sadly, we keep the selectionKey to OP_WRITE until the second message is
written, so we do two select() for each message to write. If the clients write
to the server not waiting for the response to come back, then we enqueue a hell
lot of messages we won't never be able to send to the client. After a while,
all the queus will be full of crap, and the JVM will die with an OOM.
This is bad design from day one, with pile of hacks added to try to make the
code to work. Ugly. Not sure this can be fixed easily, but will try. Puke.
Puke, puke, puke !
> 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
> Assignee: 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.
