directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRSERVER-1719) [Perf] Modify the way we process entries to be returned
Date Mon, 30 Apr 2012 12:10:47 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264888#comment-13264888
] 

Alex Karasulu commented on DIRSERVER-1719:
------------------------------------------

This is a great idea but we also have to take into account that some interceptors to produce
their net effect have to alter the entry on it's way out the door. So this can be done but
might have to be done using another more creative mechanism. I recommend using shadowing this
way for example: at the bottom you have the copy pulled out from the DIB and around it you
have a wrapper. Reads tunnel through and read what's at the bottom from the original only
if nothing has changed. Changes are stored in the wrapper. The wrapper serves as a sort of
modified value storage. 

This way what is bubbled up to the network layer is the original copy with the wrapper around
it. The necessary information is read from it and returned to the client without copying while
still having the effects of the interceptors incorporated into the returned results.

WDYT? 
                
> [Perf] Modify the way we process entries to be returned
> -------------------------------------------------------
>
>                 Key: DIRSERVER-1719
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1719
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>    Affects Versions: 2.0.0-M6
>            Reporter: Emmanuel Lecharny
>             Fix For: 2.0.0-M8
>
>
> Right now, we clone the entries we will return to the client just after having fetched
them from the backend. This is necessary as we will remove and add some attributes and values
from those entries, to comply with the user request.
> Another idea would be to compute the attributes (and values) to return, and when done,
create a new entry with all those attributes.
> As a user rarely requires all the attributes (including the operational ones), this might
save some processing, as in the current system we copy all the attributes, then we remove
some of them.
> Even better, when the CoreSession is called from the LdapProtocol layer, we don't have
to copy the attributes at all, we just have to write on the socket only the required attributes.
This will be even faster than what we currently do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message