[
https://issues.apache.org/jira/browse/DIRSERVER-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRSERVER-1266.
------------------------------------------
Resolution: Won't Fix
This was a general misconception of my part.
First because there is no need to do a double lookup, as we can reuse the entry
we have read to avoid doing another lookup later. Second because it can spare
some later lookup too.
We have to consider that this lookup is necessary anyway, so better do it soon
than later, because for many operations, this can avoid useless processing (for
instance, if the initial lookup fails for a delete operation, then there is no
need to go any farther)
More than that, the idea was to remove the referral handling from the core
server, where it does not belong. The core server is just meant to return
entries, whatever kind they are, without interpreting their status (being a
referral or not). WRT this idea, the referral handling should be managed at the
protocol level.
> The new referal handling generate 2 lookup instead of one for every search
> request
> ----------------------------------------------------------------------------------
>
> Key: DIRSERVER-1266
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1266
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.4
> Reporter: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 1.5.5
>
>
> The new implementation for referrals generate a double lookup for search
> requests, and generally speaking, an initial lookup for every operation.
> Here is the portion of code in the ReferralAwareRequest.handle() method :
> ...
> if ( req.getControls().containsKey( ManageDsaITControl.CONTROL_OID ) )
> {
> handleIgnoringReferrals( session, reqTargetDn, null, req );
> }
> else
> {
> handleWithReferrals( session, reqTargetDn, req );
> }
> ...
> private void handleWithReferrals( LdapSession session, LdapDN
> reqTargetDn, T req )
> ...
> if ( ! ( req instanceof AddRequest ) )
> {
> try
> {
> entry = session.getCoreSession().lookup( reqTargetDn );
> ...
> then the specific handler is called, where a second lookup is done.
> We should at least store the first lookup result into the context so that we
> eliminate the need for a seconf lookup, but even then, I don't think it's a
> good idea. It would rather be much more efficient to deal with referrals the
> way it was done before (with a specific interceptor) instead of managing it
> at the protocol handling layer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
