You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2012/10/10 13:15:07 UTC

[jira] [Updated] (DIRMINA-768) Don't use a queue to store the encoded/decoded messages

     [ https://issues.apache.org/jira/browse/DIRMINA-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRMINA-768:
--------------------------------------

    Fix Version/s:     (was: 2.0.6)
                   2.0.8
    
> 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: 2.0.8
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira