[
https://issues.apache.org/jira/browse/SOLR-18472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-18472:
----------------------------------
Labels: pull-request-available (was: )
> TikaServerExtractionBackend can hand out a reference to a stopped HttpClient
> ----------------------------------------------------------------------------
>
> Key: SOLR-18472
> URL: https://issues.apache.org/jira/browse/SOLR-18472
> Project: Solr
> Issue Type: Bug
> Components: contrib - Solr Cell (Tika extraction)
> Affects Versions: 10.0, 9.10.1
> Reporter: Jan Høydahl
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This bug was found by Claude Opus while working on this code base. Recording
> it here, but not prioritizing a fix since it is fairly corner case:
> ----
> TikaServerExtractionBackend shares one Jetty HttpClient per JVM, reference
> counted
> via RefCounted and released when a backend is closed (core close/reload).
> The reference is acquired outside the lock that guards the shared instance:
> {code:java}
> acquiredResourcesRef = initializeHttpClient().incref();
> {code}
> initializeHttpClient() returns the existing instance on an unlocked fast
> path, so a
> concurrent close() can drop the refcount to zero in between, stopping the
> HttpClient
> and clearing the static holder. The new backend then increfs an already closed
> reference and ends up with a stopped client, while the next backend creates a
> second
> client that the stale reference no longer tracks. RefCounted's javadoc notes
> it is
> only safe when incref() cannot be called after the count hits zero, which is
> not the
> case here.
> Window is narrow and limited to core load/reload/close, not the indexing path.
> Fix: acquire (incref) and release (decref) both under INIT_LOCK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]