You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2012/04/30 13:50:49 UTC
[jira] [Created] (DIRSERVER-1719) [Perf] Modify the way we process
entries to be returned
Emmanuel Lecharny created DIRSERVER-1719:
--------------------------------------------
Summary: [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
[jira] [Commented] (DIRSERVER-1719) [Perf] Modify the way we
process entries to be returned
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DIRSERVER-1719) [Perf] Modify the way we
process entries to be returned
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264899#comment-13264899 ]
Emmanuel Lecharny commented on DIRSERVER-1719:
----------------------------------------------
This was exactly what I had in mind : wrap the entr fetched from the backend, and store there the modification to be applied.
The tricky part comes with the ACI which may hide some attribute's values, so the granularity is the value, not the attribute
> [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
[jira] [Commented] (DIRSERVER-1719) [Perf] Modify the way we
process entries to be returned
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266576#comment-13266576 ]
Emmanuel Lecharny commented on DIRSERVER-1719:
----------------------------------------------
One other idea :
- we could modify the way the filters so that they don't process Entry, but Attribute. Now when we loop on all the original entry (the one we fetched from the backend) attributes, we will go through all the filters to know if we should return the attribute, or discard it.
- we will have to process the collective attribute in a bit different way, as they are added to the result entry, but basically, this is quite the same mechanism. We get back the added attributes, then we check against the other filters if the attribute should be returned or not
- the ACI filter is also a bit different, because it checks the Values too. Here, the filter could return a copy of the modified Attribute, if and only if the Attribute has already been accepted by all the other filters (considering that the ACI filter will be the last one to proceed, this is ok).
At the end, we don't have to clone the full entry, ot do we have to store intermediary modifications. We will just do that once, just when we generate the entry to return. If this is called by the network layer, we won't even create an entry, but serialize it directly into a ByteBuffer.
> [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
[jira] [Updated] (DIRSERVER-1719) [Perf] Modify the way we process
entries to be returned
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1719:
-----------------------------------------
Fix Version/s: (was: 2.0.0-M8)
2.1.0
> [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.1.0
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira