directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Burgemeister (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRAPI-318) Schema elements HashCode are not computed at all
Date Tue, 28 Aug 2018 02:30:00 GMT

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

Aaron Burgemeister commented on DIRAPI-318:
-------------------------------------------

I'm going to post here since it is where the fix matters, but also on the Directory Studio
bug dealing with slow loading (DIRSTUDIO-1174) because I am so happy!.

 

Cloned the API repo, ran a build (not sure I did that properly, but it made my CPU warm up
for a while so it seemed good enough), and then copied JARs until I found this one copied
by this command to where my newly-built Directory Studio build was waiting:

cp ./ldap/model/target/api-ldap-model-2.0.0.AM2-SNAPSHOT.jar /home/ab/Desktop/ApacheDirectoryStudio/plugins/org.apache.directory.api.ldap.model_2.0.0.AM1.jar

Summary: Twenty-seven (27) seconds came down to seven (7), which is only a couple seconds
longer than a fresh install with no connections defined.  If it gets better than this, I'll
be surprised.  Great, wonderful work!  I think people who use Directory Studio at all will
notice this difference since we're going from a one-second penalty per connection with non-default
schema, to something around a 0.05 second penalty (don't check my math).

> Schema elements HashCode are not computed at all
> ------------------------------------------------
>
>                 Key: DIRAPI-318
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-318
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 2.0.0.AM1
>            Reporter: Emmanuel Lecharny
>            Priority: Critical
>             Fix For: 2.0.0.AM2
>
>
> The {{SchemaObject}} sub-classes hashCode is never computed, unless the {{lock()}} method
is called.
> The {{lock()}} method is used to compute this value, but them the object isn't mutable
anymore. This is ok for the un-mutable flavor, not at all for the mutable one, as any attempt
to update them will result in a {{UnsupportedOperationException}} being thrown, like in :
> {code:java}
>     public void setMayAttributeTypeOids( List<String> mayAttributeTypeOids )
>     {
>         if ( locked )
>         {
>             throw new UnsupportedOperationException( I18n.err( I18n.ERR_13700_CANNOT_MODIFY_LOCKED_SCHEMA_OBJECT,
getName() ) );
>         }
>         if ( !isReadOnly )
>         {
>             this.mayAttributeTypeOids = mayAttributeTypeOids;
>         }
>     }
> {code}
> The idea behind not computing teh hashCode on the fly was to speedup the use of this
class, which is frequently stored in {{Map}} or {{Set}}. The problem is that the {{lock()}}
method must now be called explicitly *outside* the class, which is clearly painful.
> The direct consequence if the {{lock()}} method is not called is that *ALL* the {{SchemaElement}}
instances will have a hashCode value of {{0}}, making the access from a {{Set}}/{{Map}} quite
expensive :/
> To add insult to injury, you simply can't call {{lock()}} on a mutable version, as it
will forbid you to update the object unless you unlock it before. Beautiful :/



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

Mime
View raw message