lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (SOLR-3424) PhoneticFilterFactory threadsafety bug
Date Tue, 01 May 2012 07:29:45 GMT


Uwe Schindler commented on SOLR-3424:

Hi David,

looks good, but there is a bug:
The refactoring of the REGISTRY static map was an anonymous inner class before (new HashMap()
{{ hashmap ctor code }}; (please note double parens). Now it is assigned to a static field,
but the initializer code is an inline ctor of the factory, means the initialization runs on
every instantiation.

- add *static* before the anonymous ctor:
private static final Map<String, Class<? extends Encoder>> registry = new HashMap<String,
Class<? extends Encoder>>(6);
static {

- or leave the initializer as it was before (anonymous HashMap subclass with overridden ctor).

in resolve encoder maybe remove the clazz variable and directly return the result of forName().
I do't like non-final variables initialized with null because that prevents compilation failures
on missing initialization and null could be returned - especially with lots of try-catch blocks.
> PhoneticFilterFactory threadsafety bug
> --------------------------------------
>                 Key: SOLR-3424
>                 URL:
>             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, 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message