[jira] [Commented] (SOLR-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886642#comment-17886642 ] Jason Gerlowski commented on SOLR-16470: Agreed - required parameters should be, well, required. A '400' telling users what param they forgot is much better than an opaque stack trace later on. Thanks for working on the 'filecontent' API [~mbiscocho] - if you hit any blockers or have more questions, let me know! > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 4h 20m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer reassigned SOLR-17464:
-
Assignee: James Dyer
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886678#comment-17886678
]
ASF subversion and git services commented on SOLR-17464:
Commit e5d26619509626f7bad13d4ae86e7f9b9344fba1 in solr's branch
refs/heads/main from James Dyer
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=e5d26619509 ]
SOLR-17464 (#2733)
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886682#comment-17886682
]
Jason Gerlowski commented on SOLR-17464:
bq. I was in this code somewhat recently and thought I could jumpstart my
Monday with a cast-free PR.
Hey, no better way to start the week, that's awesome. Thanks for fixing!
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16470) Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get File List
[ https://issues.apache.org/jira/browse/SOLR-16470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886687#comment-17886687 ] Matthew Biscocho commented on SOLR-16470: - Thanks everyone. [PR|https://github.com/apache/solr/pull/2734] made for this last V2 api for this. Not sure why Jira didn't pick it up. Probably missing something so it didn't attach. Added in some things to throw a 400 in the V1 and V2 code path for bad requests. > Create V2 equivalent of V1 Replication: Get IndexVersion, Get FileStream, Get > File List > --- > > Key: SOLR-16470 > URL: https://issues.apache.org/jira/browse/SOLR-16470 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.2 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 4h 20m > Remaining Estimate: 0h > > Replication Handler has no v2 equivalent. This ticket is covering few > endpoints from ReplicationHandler such as Get IndexVersion, Get FileStream, > Get File List. > Existing V1 > |-GET /solr/collName/replication?command=indexversion-| > |GET /solr/collName/replication?command=filecontent| > |-GET /solr/collName/replication?command=filelist-| > Proposed API design > |-GET /api/cores/coreName/replication/indexversion-| > |GET /api/cores/coreName/replication/files/filePath| > |-GET /api/cores/coreName/replication/files-| > few other pointers that might be helpful, especially for newcomers: > * The v1 logic for this API lives in ReplicationHandler > * [Some discussion of how APIs work in Solr (Particularly the "APIs in Solr" > section.)|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#apis-in-solr] > * [A step-by-step guide to creating APIs using the preferred v2 API > framework|https://github.com/apache/solr/blob/main/dev-docs/apis.adoc#writing-jax-rs-apis] > * [A recent PR that adds a v2 API, as an > example|https://github.com/apache/solr/pull/2144] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16871) Race condition for coordinator node init
[ https://issues.apache.org/jira/browse/SOLR-16871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Gibney updated SOLR-16871: -- Fix Version/s: 9.4 > Race condition for coordinator node init > > > Key: SOLR-16871 > URL: https://issues.apache.org/jira/browse/SOLR-16871 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Patson Luk >Priority: Major > Fix For: 9.4 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > From a unit test case [that issue concurrent select queries to coordinator > nodes|https://github.com/cowpaths/fullstory-solr/blob/e4226eb8fa2afb01d7615f7faea01f71b144cd58/solr/core/src/test/org/apache/solr/search/TestCoordinatorRole.java#L486], > it’s found that there could be 3 race condition issues: > 1. If multiple concurrent requests find the synthetic collection is not yet > created, they might all attempt to create the synthetic collection. This > could trigger SolrException on `collection already exists` > 2. Similarly, if multiple concurrent requests find there’s no replica of the > synthetic collection for current node (multiple coordinator node scenario), > then CoordinatorHttpSolrCall#addReplica could be invoked multiple times. This > should not trigger any exception, but would create multiple replicas for the > same node in the synthetic collection > 3. The existing logic > [here|https://github.com/cowpaths/fullstory-solr/blob/6c8531f08301a291478502c262499abed0d5075c/solr/core/src/java/org/apache/solr/servlet/CoordinatorHttpSolrCall.java#L102] > assumes if > syntheticColl.getReplicas(solrCall.cores.getZkController().getNodeName()) > returns non empty result, then the following call in > [here|https://github.com/cowpaths/fullstory-solr/blob/6c8531f08301a291478502c262499abed0d5075c/solr/core/src/java/org/apache/solr/servlet/CoordinatorHttpSolrCall.java#L112] > should return a core. Unfortunately, the first call can return a non empty > list but with a DOWN replica if another request is in the progress of > creating such replica. In this case, the > solrCall.getCoreByCollection(syntheticCollectionName, isPreferLeader) would > call super.getCoreByCollection at > [here|https://github.com/cowpaths/fullstory-solr/blob/6c8531f08301a291478502c262499abed0d5075c/solr/core/src/java/org/apache/solr/servlet/CoordinatorHttpSolrCall.java#L69] > which would return a null (since super impl only returns active replica). So > CoordinatorHttpSolrCall#getCoreByCollection would end up calling > CoordinatorHttpSolrCall#getCore , introducing an infinite loop and cause > stack overflow -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16898) Remove debug println from JSONTestUtil
[ https://issues.apache.org/jira/browse/SOLR-16898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Gibney updated SOLR-16898: -- Fix Version/s: 9.4 > Remove debug println from JSONTestUtil > -- > > Key: SOLR-16898 > URL: https://issues.apache.org/jira/browse/SOLR-16898 > Project: Solr > Issue Type: Test > Components: SolrCloud >Reporter: Patson Luk >Priority: Major > Fix For: 9.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It's found that a possibly debug statement > https://github.com/apache/solr/commit/e5ca599f51f859834efde2e190ba1e3f17cbb4b1#diff-1098b7bd3712859836c1915cc5af5190782fb27183e5750d4bbf1d2d3e229c92R80 > creates a large amount of log for our test case in > https://github.com/cowpaths/fullstory-solr/actions/runs/5591120540/jobs/10221763319 > and caused GC limit exception hence test failure -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886713#comment-17886713
]
ASF subversion and git services commented on SOLR-17464:
Commit 3d76ccdf65c0a1231b40c937f72ba174ae3a0dff in solr's branch
refs/heads/branch_9x from James Dyer
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=3d76ccdf65c ]
SOLR-17464: Fixed Http2SolrClient bug in that 'requestAsync' triggered NPE when
using a shared Jetty client (#2733)
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-17464.
---
Resolution: Fixed
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
> Fix For: 9.8
>
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17464) Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
[
https://issues.apache.org/jira/browse/SOLR-17464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-17464:
--
Fix Version/s: 9.8
> Http2SolrClient.requestAsync triggers NPE when using a shared Jetty client
> --
>
> Key: SOLR-17464
> URL: https://issues.apache.org/jira/browse/SOLR-17464
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: main (10.0), 9.7
>Reporter: Jason Gerlowski
>Assignee: James Dyer
>Priority: Major
> Labels: newdev
> Fix For: 9.8
>
>
> Http2SolrClient can be configured to either create its own Jetty HttpClient,
> or reuse an existing one.
> In this latter "reuse" case, the Http2SolrClient never sets the "executor"
> instance variable. This causes a NullPointerException any time the
> SolrClient's "requestAsync" method is called, which expects "executor" to be
> set.
> The bug is easy to reproduce with the following JUnit code (that, as of
> writing, can be dropped into Http2SolrClientTest and run):
> {code}
> @Test
> public void testReproduceExecutorNPEBug() {
> DebugServlet.clear();
> final var url = getBaseUrl() + DEBUG_SERVLET_PATH;
> final var queryParams = new ModifiableSolrParams();
> queryParams.add("q", "*:*");
> try (Http2SolrClient originalClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).build()) {
> // TODO The 'requestAsync' call below should succeed, but produces an
> NPE since
> try (Http2SolrClient derivedClient = new
> Http2SolrClient.Builder(url).withDefaultCollection(DEFAULT_CORE).withHttpClient(originalClient).build())
> {
> final var future = derivedClient.requestAsync(new
> QueryRequest(queryParams));
> final var results = future.join();
> }
> }
> }
> {code}
> And the exception:
> {code}
> 3429 INFO (h2sc-21-thread-2) [n: c: s: r: x: t:] o.e.j.c.ResponseNotifier
> Exception while notifying listener
> org.apache.solr.client.solrj.impl.Http2SolrClient$1@34bcd66e
> => java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> java.lang.NullPointerException: Cannot invoke
> "java.util.concurrent.ExecutorService.execute(java.lang.Runnable)" because
> "this.this$0.executor" is null
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$1.onHeaders(Http2SolrClient.java:447)
> ~[main/:?]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:95)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.ResponseNotifier.notifyHeaders(ResponseNotifier.java:87)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.client.HttpReceiver.responseHeaders(HttpReceiver.java:327)
> [jetty-client-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpReceiverOverHTTP2.onHeaders(HttpReceiverOverHTTP2.java:120)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> at
> org.eclipse.jetty.http2.client.http.HttpChannelOverHTTP2$Listener.onHeaders(HttpChannelOverHTTP2.java:186)
> [http2-http-client-transport-10.0.22.jar:10.0.22]
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17475) Allow DELETESTATUS to keep only recent status
Yuntong Qu created SOLR-17475: - Summary: Allow DELETESTATUS to keep only recent status Key: SOLR-17475 URL: https://issues.apache.org/jira/browse/SOLR-17475 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Yuntong Qu collections api DeleteStatus can only delete a specific async id or flush all id. We should allow also DELETESTATUS to do more fine grained management of status by only keeping most recent X number of status. This would make overseer znode number more manageable. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17476) Allow DELETESTATUS to keep only recent status
Yuntong Qu created SOLR-17476: - Summary: Allow DELETESTATUS to keep only recent status Key: SOLR-17476 URL: https://issues.apache.org/jira/browse/SOLR-17476 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Yuntong Qu collections api DeleteStatus can only delete a specific async id or flush all id. We should allow also DELETESTATUS to do more fine grained management of status by only keeping most recent X number of status. This would make overseer znode number more manageable. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17125) SIP-20 ZERO replicas, separation of compute and storage
[ https://issues.apache.org/jira/browse/SOLR-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886614#comment-17886614 ] Eric Pugh commented on SOLR-17125: -- Just want to share that I saw some interesting presentations at OpenSearchCon by Uber and Slack on how their respective logging solutions built on Lucene do this... > SIP-20 ZERO replicas, separation of compute and storage > --- > > Key: SOLR-17125 > URL: https://issues.apache.org/jira/browse/SOLR-17125 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: main (10.0) >Reporter: Ilan Ginzburg >Assignee: Ilan Ginzburg >Priority: Major > > This Jira is the initial ticket for the implementation of > [*SIP-20*|https://cwiki.apache.org/confluence/display/SOLR/SIP-20%3A+Separation+of+Compute+and+Storage+in+SolrCloud], > the separation of compute and storage in SolrCloud. > The first code drop corresponding to this Jira is in branch > [https://github.com/apache/solr/tree/*jira/solr-17125-zero-replicas*|https://github.com/apache/solr/tree/jira/solr-17125-zero-replicas] > Documentation to help approach that branch is available at > [https://github.com/apache/solr/blob/jira/solr-17125-zero-replicas/solr/*ZERO-REPLICAS.adoc*|https://github.com/apache/solr/blob/jira/solr-17125-zero-replicas/solr/ZERO-REPLICAS.adoc] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17469) CLI: Resolve -f flag conflicts
[ https://issues.apache.org/jira/browse/SOLR-17469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17469: Assignee: Eric Pugh > CLI: Resolve -f flag conflicts > -- > > Key: SOLR-17469 > URL: https://issues.apache.org/jira/browse/SOLR-17469 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: 9.7, 9x >Reporter: Christos Malliaridis >Assignee: Eric Pugh >Priority: Major > Labels: cli, migration > > h4. Description > The -f flag is used in multiple options, including: > * foreground in bin/solr and bin/solr.cmd, which runs Solr in the foreground > * format in PostTool to send application/json content as Solr commands to > /update instead of /update/json/docs > * format in ExportTool to set the output format for exported docs > * force in bin/solr and RunExampleTool to allow starting Solr as root user > * config file in SolrExporter to specify the configuration file > * force delete in DeleteTool to skip safety checks when deleting the > configuration directory used by a collection > * upgrade solr in install_solr_service.sh to overwrite symlink and init > script of previous installation > To avoid confusion, we should deprecate (9.8) and remove (10.0) the -f flag > from options that do not explicitly need it. > h4. Proposed Conflict Resolution > Keep -f for forcing actions since it is often used in other tools for "force" > as well. This means keep -f for force in bin/solr and RunExampleTool to allow > starting Solr as root user and also for force deleting configuration > directories in DeleteTool. > Deprecate (9x and 9.7.1) and remove (10.0) by replacing the > "force-delete-config" (--force-delete-config, -forceDeleteConfig, > --forceDeleteConfig, -f) in DeleteTool with the "force" option ( --force, -f). > Deprecate (9x and 9.7.1) and remove (10.0) -f from the "format" option in > PostTool. > Deprecate (9x and 9.7.1) and remove (10.0) -f from the "config file" option > (-f, --config-file, -config-file) in SolrExporter. > Deprecate (9x and 9.7.1) and remove (10.0) -f from "upgrade solr" in > install_solr_service.sh by replacing it with "–upgrade". > h4. More Information > Please look into [Solr Arguments - Migration > Overview|[https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U]] > for a better overview and additional information. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
