[
https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622583#action_12622583
]
henrib edited comment on SOLR-647 at 8/14/08 8:46 AM:
-------------------------------------------------------------
About the SolrCore.open() & close():
If we were to do an incrementAndGet(), we could end up opening a closed core;
We thus must check the refcount is not <=0 first.
The close could use a decrementAndGet() but the current code ensures the count
will never go < 0 and is symmetrical to open.
In both cases, it is the test in between the get() & compareAndSet() that makes
the whole difference with {in,de]crementAndGet.
My understanding of Yonik's version is that, as a premise, opening a core is
always performed under the CoreContainer#cores synchronized protection; as I
explained in a previous comment, the assumption can not be strictly met.
was (Author: henrib):
About the SolrCore.open() & close():
If we were to do an incrementAndGet(), we could end up opening a closed core
since we can not always be under the CoreContainer#cores synchronized
protection.
We thus must check the refcount is not <=0 first.
The close could use a decrementAndGet() but the current code ensures the count
will never go < 0.
Itn both cases, it is the test in between the get() & compareAndSet() that
makes the whole difference with {in,de]crementAndGet.
> Do SolrCore.close() in a refcounted way
> ---------------------------------------
>
> Key: SOLR-647
> URL: https://issues.apache.org/jira/browse/SOLR-647
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Noble Paul
> Assignee: Grant Ingersoll
> Fix For: 1.3
>
> Attachments: refcount_example.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch,
> solr-647.patch, SOLR-647.patch, SOLR-647.patch
>
>
> The method _SolrCore.close()_ directly closes the core . It can cause
> Exceptions for in-flight requests. The _close()_ method should just do a
> decrement on refcount and the actual close must happen when the last request
> being processed by that core instance is completed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
