[
https://issues.apache.org/jira/browse/DIRMINA-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125387#comment-14125387
]
Emmanuel Lecharny commented on DIRMINA-768:
-------------------------------------------
Too complex to implement in MINA 2.
Postponed to MINA 3
> Don't use a queue to store the encoded/decoded messages
> -------------------------------------------------------
>
> Key: DIRMINA-768
> URL: https://issues.apache.org/jira/browse/DIRMINA-768
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.0-RC1
> Reporter: Emmanuel Lecharny
> Fix For: 3.0.0-M3
>
>
> Encoding/decoding messages is done using an encoder/decoder and a dedicated
> data structure storing the encoded/decoded result. This data structure
> contains a queue to store the results (we may have more than one).
> The problems with this approach are that :
> - it's more complex than necessary,
> - we have to allocate those data structure for each session
> - we have to allocate a queue for each new session
> - we will store in memory all the results until the encoding/decoding is
> fully done, before processing them
> The last point is really worrying, as if we have a huge piece of data coming
> from a client, and if we decode it to produce tens of messages, it's
> perfectly possible that when processing the very first message, the handler
> might decide that the connection should be killed (for instance if the fisrt
> message is not expected). We then have decoded all the remaining messages for
> nothing, wasting CPU and memory.
> I suggest that the decode method returns the result one by one, until we
> can't anymore decode anything.
> From the client POV, that does not change a lot of things, in fact, it should
> be totally transparent. From the performance POV, we might have a small gain
> here, as we won't create anymore those intermediate structures, so we will
> gain on the spared instance creation, and also on the GC.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
