[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933682#comment-17933682
]
ASF subversion and git services commented on SOLR-17677:
Commit 3a492203cf4d9b7ed9431de9378049992f7da355 in solr's branch
refs/heads/deprecations from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=3a492203cf4 ]
SOLR-17677: HashRangeQuery doesn't NEED SolrIndexSearcher (#3206)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Fix For: main (10.0), 9.9, 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933680#comment-17933680
]
ASF subversion and git services commented on SOLR-17677:
Commit 76e9b331a35ae2a80a675c98794b677758470b09 in solr's branch
refs/heads/deprecations from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=76e9b331a35 ]
SOLR-17677: Ensure DBQ is safe before running (#3203)
Portions of the DBQ codepath execute the deletion query with a standard
Lucene IndexSearcher, which upsets some Solr Query implementations that
have been built to assume SolrIndexSearcher in (e.g.)
Query.createWeight.
This commit adds checks for this case, which work by using a Lucene
"QueryVisitor" to iterate over a parsed query tree and detect whether
any of the individual queries require SolrIndexSearcher.
(The QueryVisitor implementation has been added as 'lucene.
experimental', to leave us free to modify or remove it in future as desired.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Fix For: main (10.0), 9.9, 9.8.1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.s
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930340#comment-17930340
]
ASF subversion and git services commented on SOLR-17677:
Commit 70bd055f1dc8d8bb5200f77fd6f4790115357080 in solr's branch
refs/heads/branch_9_8 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=70bd055f1dc ]
SOLR-17677: Ensure DBQ is safe before running (#3203)
Portions of the DBQ codepath execute the deletion query with a standard
Lucene IndexSearcher, which upsets some Solr Query implementations that
have been built to assume SolrIndexSearcher in (e.g.)
Query.createWeight.
This commit adds checks for this case, which work by using a Lucene
"QueryVisitor" to iterate over a parsed query tree and detect whether
any of the individual queries require SolrIndexSearcher.
(The QueryVisitor implementation has been added as 'lucene.
experimental', to leave us free to modify or remove it in future as desired.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17930326#comment-17930326
]
ASF subversion and git services commented on SOLR-17677:
Commit 0ade74477d2ceef1de244e6462d3769d7c00cd7a in solr's branch
refs/heads/branch_9x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=0ade74477d2 ]
SOLR-17677: Ensure DBQ is safe before running (#3203)
Portions of the DBQ codepath execute the deletion query with a standard
Lucene IndexSearcher, which upsets some Solr Query implementations that
have been built to assume SolrIndexSearcher in (e.g.)
Query.createWeight.
This commit adds checks for this case, which work by using a Lucene
"QueryVisitor" to iterate over a parsed query tree and detect whether
any of the individual queries require SolrIndexSearcher.
(The QueryVisitor implementation has been added as 'lucene.
experimental', to leave us free to modify or remove it in future as desired.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.ja
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17929815#comment-17929815
]
ASF subversion and git services commented on SOLR-17677:
Commit 3a492203cf4d9b7ed9431de9378049992f7da355 in solr's branch
refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=3a492203cf4 ]
SOLR-17677: HashRangeQuery doesn't NEED SolrIndexSearcher (#3206)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176)
> ~[jetty-server-10.0.22.j
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17929297#comment-17929297
]
ASF subversion and git services commented on SOLR-17677:
Commit 76e9b331a35ae2a80a675c98794b677758470b09 in solr's branch
refs/heads/main from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=76e9b331a35 ]
SOLR-17677: Ensure DBQ is safe before running (#3203)
Portions of the DBQ codepath execute the deletion query with a standard
Lucene IndexSearcher, which upsets some Solr Query implementations that
have been built to assume SolrIndexSearcher in (e.g.)
Query.createWeight.
This commit adds checks for this case, which work by using a Lucene
"QueryVisitor" to iterate over a parsed query tree and detect whether
any of the individual queries require SolrIndexSearcher.
(The QueryVisitor implementation has been added as 'lucene.
experimental', to leave us free to modify or remove it in future as desired.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.jar:10.0.2
[jira] [Commented] (SOLR-17677) {!join} in delete-by-query throws ClassCastException and closes IndexWriter
[
https://issues.apache.org/jira/browse/SOLR-17677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17928868#comment-17928868
]
Jason Gerlowski commented on SOLR-17677:
A few small updates:
First, this is pretty trivial to reproduce with the following:
{code}
bin/solr start -c -e techproducts
curl -ilk -X GET "http://localhost:8983/solr/techproducts/update?commit=true";
-H "Content-type: application/xml" -d '{!join from=manu_id_s
to=manu_id_s v="id:123"}'
{code}
Second, the issue here isn't specific to JoinQuery - a handful of Solr Query
implementations run into similar issues. The list I've found so far includes:
* Join
* Graph
* Collapse
* HashRange
* "IGainTerms"
* SignificantTerms
* "TextLogisticRegression"
(It's hard to imagine anyone running some of these in a DBQ, but still worth
safeguarding nonetheless I suppose. Join and Graph definitely seem like the
two most likely scenarios this might arise for a user.)
> {!join} in delete-by-query throws ClassCastException and closes IndexWriter
> ---
>
> Key: SOLR-17677
> URL: https://issues.apache.org/jira/browse/SOLR-17677
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 9.8
>Reporter: Jason Gerlowski
>Priority: Minor
>
> Solr's JoinQuery implementation explicitly casts the provided "IndexSearcher"
> to a "SolrIndexSearcher". In most contexts this assumption bears out, but
> not always.
> One counter-example is Solr's "Delete By Query" codepath, which runs the
> deletion query using a "raw" Lucene IndexSearcher. (Presumably this is
> because the new searcher has just been opened?). Any DBQ containing a join
> query will throw a ClassCastException, which then bubbles up to the
> IndexWriter as a "tragic" Lucene exception, force-closing the IndexWriter and
> throwing the surrounding SolrCore in to a bad state:
> {code}
> 2025-02-18 19:39:25.339 ERROR (qtp1426725223-177-localhost-73)
> [c:techproducts s:shard2 r:core_node3 x:techproducts_shard2_replica_n1
> t:localhost-73] o.a.s.h.RequestHandlerBase Server exception =>
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> org.apache.solr.common.SolrException: this IndexWriter is closed
> at
> org.apache.solr.common.SolrException.wrapLuceneTragicExceptionIfNecessary(SolrException.java:218)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.normalizeReceivedException(RequestHandlerBase.java:272)
> ~[?:?]
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:238)
> ~[?:?]
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2880) ~[?:?]
> at
> org.apache.solr.servlet.HttpSolrCall.executeCoreRequest(HttpSolrCall.java:890)
> ~[?:?]
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:576)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.dispatch(SolrDispatchFilter.java:241)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.lambda$doFilterRetry$0(SolrDispatchFilter.java:198)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.traceHttpRequestExecution2(ServletUtils.java:227)
> ~[?:?]
> at
> org.apache.solr.servlet.ServletUtils.rateLimitRequest(ServletUtils.java:197)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilterRetry(SolrDispatchFilter.java:192)
> ~[?:?]
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:181)
> ~[?:?]
> at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:97)
> ~[jetty-servlet-api-4.0.6.jar:?]
> at
> org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527)
> ~[jetty-servlet-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598)
> ~[jetty-security-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223)
> ~[jetty-server-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1580)
> ~[jetty-server-10.0.22.jar:10.
