[
https://issues.apache.org/jira/browse/LUCENE-4796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586301#comment-13586301
]
Hoss Man commented on LUCENE-4796:
----------------------------------
bq. We have to fix the same issue in AnalysisSPILoader which is (unfortunately)
a different class with some code duplication
Ahhhh... that could totally explain why my naive attempt at fixing SOLR-4373 a
while back didn't seem to work -- i was only aware of NamedSPILoader but did ad
hock testing using analyzer factories.
Uwe: looking at your patch, one thing that jumps out at me is that
AnalysisSPILoader seems to have another exist bug that may also cause some
similar problems, regardless of thread safety...
{code}
public synchronized void reload(ClassLoader classloader) {
final SPIClassIterator<S> loader = SPIClassIterator.get(clazz, classloader);
final LinkedHashMap<String,Class<? extends S>> services = new
LinkedHashMap<String,Class<? extends S>>();
{code}
...shouldn't that LinkedHashMap be initialized with a copy of this.services
(just like in NamedSPILoader.reload) so successive calls to reload(...) don't
"forget" services that have already been added?
(if you only call reload on child classloaders, then i imagine this wouldn't
cause any problems, but with independent sibling classloaders it seems like
calls stacks along the lines of..
{noformat}
analysisloader = new AnalysisSPILoader(Foo.class, parentClassLoader);
analysisloader.reload(childAClassLoader);
analysisloader.reload(childBClassLoader);
{noformat}
...would cause the loader to "forget" about any services it found in
childAClassloader)
> NamedSPILoader.reload needs to be synchronized
> ----------------------------------------------
>
> Key: LUCENE-4796
> URL: https://issues.apache.org/jira/browse/LUCENE-4796
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4796.patch
>
>
> Spun off of SOLR-4373: as discsused with uwe on IRC, NamedSPILoader.reload is
> not thread safe: it reads from this.services at the beginging of hte method,
> makes additions based on the method input, and then overwrites this.services
> at the end of the method. if the method is called by two threads
> concurrently, the entries added by threadB could be lost if threadA enters
> the method before threadB and exists the method after threadB
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
