[
https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623201#action_12623201
]
Noble Paul commented on SOLR-647:
---------------------------------
bq. Also, is there any reason not to allow the same core to be registered more
than once if desired?
How will SolrCore#getCoreDescriptor() work. what will it return?
should the getCore() have synchronized block?
can we manage with a ConcurrentHashMap? A lock to be obtained per request looks
like too much of a price . The only problem with concurrent map is that if you
remove while an iteration is going on you may get an exception (correct me if I
am wrong). If we can have a separate lock for just that we can have
synchronization only in those places and we can spare the getCore()
> 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: Yonik Seeley
> 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, 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.
