[ 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to