[
https://issues.apache.org/jira/browse/LUCENE-3656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172609#comment-13172609
]
Uwe Schindler commented on LUCENE-3656:
---------------------------------------
I agree that for small ordered sets (like Handlers/Listender, see example from
Javadocs) this is a good idea, but its still the wrong set for this use case:
The listeners on close are registered by code that *may* (unlikely) come from
different threads (e.g. FieldCacheImpl registers an event to purge the caches
on IndexReader close, or maybe in future Solr registers a handler - this is
generally done on setup of IndexReader). In general synchronization would not
really be required at all, but as also different threads *may* register
listeners, there should be some basic synchronization. If you would use
CopyOnWriteArraySet, registering/removing new listeners gets slow, as it has to
copy the array each time, so registering event handlers will not block but just
be slow. On the other hand we have very fast access just for exactly one single
iteration on thi set (when the listeners are triggered, on closing the reader).
We get this for free without sync, but who cares, IndexReader.close() is the
last operation on an IR where you have no concurrency anymore.
I think we should stay with a simply synchronized LinkedHashSet which is cheap
as concurrency is no issue at all (not many threads will ever register an
event, the whole synchronization is just to guard the set for concurrent
modifications (e.g. if two threads create a new FieldCache entry at same time).
The addition cost for sync on IR.close() is a no-op, as explained above (no
concurrecy anymore).
> IndexReader's add/removeCloseListener should not use ConcurrentHashMap, just
> a synchronized set
> -----------------------------------------------------------------------------------------------
>
> Key: LUCENE-3656
> URL: https://issues.apache.org/jira/browse/LUCENE-3656
> Project: Lucene - Java
> Issue Type: Bug
> Components: core/index
> Affects Versions: 3.5, 4.0
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Priority: Minor
> Labels: curiosity
> Attachments: LUCENE-3656.patch
>
>
> The use-case for ConcurrentHashMap is when many threads are reading and less
> writing to the structure. Here this is just funny: The only reader is
> close(). Here you can just use a synchronized HashSet. The complexity of CHM
> is making this just a joke :-)
--
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: [email protected]
For additional commands, e-mail: [email protected]
