lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3424) PhoneticFilterFactory threadsafety bug
Date Mon, 30 Apr 2012 15:31:48 GMT

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

David Smiley commented on SOLR-3424:
------------------------------------

Rob: This is a (minor) thread-safety bug and consequently it's not really feasible to test
it without a lot of work and without a guarantee at the end that there is no problem, and
so it isn't worth it.  Of course if you want to; go for it ;-)

Uwe: Thanks very much for your comments.  I wasn't sure what the lifecycle of this class was
or if/how it is shared; I looked at the javadocs of TokenFilterFactory just now and I think
its clearer.  Given that the Factory's init() method is not going to be called frequently,
it seems to me that the class name based lookups need not cache at all.  And I also like your
suggestion of improving the fallback lookup by looking for a '.'.  BTW I considered wrapping
with unmodifiableMap but didn't bother because it's not exposed outside of this class, which
is fairly small too, but I will since it seems to be a big deal to you (three exclamation
points).  I'll propose another patch later

~ David
                
> PhoneticFilterFactory threadsafety bug
> --------------------------------------
>
>                 Key: SOLR-3424
>                 URL: https://issues.apache.org/jira/browse/SOLR-3424
>             Project: Solr
>          Issue Type: Bug
>          Components: Schema and Analysis
>    Affects Versions: 3.6, 4.0
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>             Fix For: 4.0
>
>         Attachments: SOLR-3424_PhoneticFilterFactory_threadsafety_bug.patch
>
>
> PhoneticFilterFactory has a static HashMap registry mapping an encoder name to an implementation.
There is a ReentrantLock used when the map is modified (when the encoder config specifies
a class name).  However, this map, which can be accessed by multiple indexing threads, isn't
guarded on any of the reads, which isn't just the common path but also the error messages
which dump the registry into the error message.
> I realize the likelihood of a problem is extremely slim, but a bug's a bug.

--
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

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message