[jira] [Updated] (DIRAPI-322) Use a TLS buffer to encode requests and responses

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

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

Emmanuel Lecharny updated DIRAPI-322:
-------------------------------------
    Fix Version/s:     (was: 2.0.0)

> Use a TLS buffer to encode requests and responses
> -------------------------------------------------
>
>                 Key: DIRAPI-322
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-322
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 2.0.0.AM3
>            Reporter: Emmanuel Lecharny
>            Priority: Major
>             Fix For: 2.0.0.AM3
>
>
> The way we encode messages is a bit complex. We try not to allocate many buffers, but instead pre-compute the needed size, then allocate the buffer, and ultimately store the data.
> It might be interesting to pre-allocate a buffer that is stored in the Thread Local Storage, big enough to store all the message, most of the time (like, a 4Kb buffer). As every encoding will be done in one single thread up to completion, this should never be problematic.
> Another improvement, to avoid storing temporary information (like the bytes' length or the byte[] for Strings) would be to encode the messages by the end: Messages are TLV constructs, where the L gives some information about the V part. Usually, we know about the L when the V has been computed. If we start by flushing the V into the buffer, from the end, we can append the L before it, and so on. When done, we simply have to copy the whole data into the right sized buffer.
> That would save a hell lot of allocations, thus GC cycles.
> If the TLS buffer is not big enough, we simply compute the needed size, and encode the message the standard way. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)