[jira] [Commented] (SOLR-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846037#comment-17846037
]
James Dyer commented on SOLR-17263:
---
[~andywebb1975] I think you'd be safe following the pattern with SOLR-17261 and
add your commit three places: *main*, *branch_9x* and *branch_9_6*. The
CHANGES.txt entry would go under 9_7_0 in the two branches, and under 9_6_1 in
*branch_9_6*. Those of you who commit more than I do may have better advice
than this!
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {noformat}
>
--
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-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842689#comment-17842689
]
James Dyer commented on SOLR-17263:
---
[~andywebb1975] Thank you for being an early adopter of this new client, for
reporting the bug and for the PR with the fix.
Sorry for the dueling PR's, but can you review my follow-up PR to yours,
[2435|https://github.com/apache/solr/pull/2435]?
I added a unit test and found sure enough that this affects the Jdk client but
the existing Jetty Client handles the parameters properly. The test indicates
only GET is affected by this bug but POST and PUT requests are OK. In the
follow-up PR I modified your fix to be only for GET.
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {noformat}
>
--
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-17242) HttpJdkSolrClient: Better handling of timeout parameters
[ https://issues.apache.org/jira/browse/SOLR-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-17242. --- Resolution: Won't Fix > HttpJdkSolrClient: Better handling of timeout parameters > > > Key: SOLR-17242 > URL: https://issues.apache.org/jira/browse/SOLR-17242 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Priority: Minor > > *HttpJdkSolrClient* takes timeout values on its Builder, but applies them at > the request level. It should apply them when building the client. -- 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-17242) HttpJdkSolrClient: Better handling of timeout parameters
[ https://issues.apache.org/jira/browse/SOLR-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-17242: -- Description: *HttpJdkSolrClient* takes timeout values on its Builder, but applies them at the request level. It should apply them when building the client. (was: This ticket is to address two related problems: 1. *Http2SolrClient* can throw NPE if the user does not specify timeout values when building the client. 2. *HttpJdkSolrClient* takes timeout values on its Builder, but applies them at the request level. It should apply them when building the client.) > HttpJdkSolrClient: Better handling of timeout parameters > > > Key: SOLR-17242 > URL: https://issues.apache.org/jira/browse/SOLR-17242 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Priority: Minor > > *HttpJdkSolrClient* takes timeout values on its Builder, but applies them at > the request level. It should apply them when building the client. -- 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-17242) HttpJdkSolrClient: Better handling of timeout parameters
[ https://issues.apache.org/jira/browse/SOLR-17242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-17242: -- Summary: HttpJdkSolrClient: Better handling of timeout parameters (was: Http2SolrClient/HttpJdkSolrClient: Better handling of timeout parameters) > HttpJdkSolrClient: Better handling of timeout parameters > > > Key: SOLR-17242 > URL: https://issues.apache.org/jira/browse/SOLR-17242 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Priority: Minor > > This ticket is to address two related problems: > 1. *Http2SolrClient* can throw NPE if the user does not specify timeout > values when building the client. > 2. *HttpJdkSolrClient* takes timeout values on its Builder, but applies them > at the request level. It should apply them when building the client. -- 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-17234) LBHttp2SolrClient does not skip "zombie" endpoints
[
https://issues.apache.org/jira/browse/SOLR-17234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-17234.
---
Resolution: Fixed
> LBHttp2SolrClient does not skip "zombie" endpoints
> --
>
> Key: SOLR-17234
> URL: https://issues.apache.org/jira/browse/SOLR-17234
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: main (10.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on SOLR-14763, I found different behavior with
> *LBHttp2SolrClient* between *branch_9x* and {*}main/10.x{*}.
> If the first Endpoint in the list had previously failed, *branch_9x* will
> skip the failed Endpoint with subsequent requests, and begin requesting with
> the second Endpoint. If all remaining Endpoints fail, it will then retry the
> first Endpoint again.
> If the first Endpoint in the list had previously failed, *main/10.x* will
> always try the first Endpoint despite it being in the "Zombie List". When
> the first Endpoint fails again, it will re-try the second Endpoint.
> The *branch_9x* behavior seems more desirable as this minimizes unnecessary
> work by avoiding Endpoints that are known to fail. Indeed, *main/10.x* has an
> obvious bug in *EndpointIterator#fetchNext* where it attempts to get the
> wrong type of key for the map holding the Zombies. I believe this difference
> is a regression bug in *main/10x*.
> The different behavior is recorded in test
> *LBHttp2SolrClientTest#testAsyncWithFailures*. This test was added
> after-the-fact with SOLR-14763. I needed to change its "asserts" when
> backporting to *branch_9x* to account for the changed behavior.
--
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-17234) LBHttp2SolrClient does not skip "zombie" endpoints
[
https://issues.apache.org/jira/browse/SOLR-17234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer updated SOLR-17234:
--
Fix Version/s: main (10.0)
> LBHttp2SolrClient does not skip "zombie" endpoints
> --
>
> Key: SOLR-17234
> URL: https://issues.apache.org/jira/browse/SOLR-17234
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: main (10.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Major
> Fix For: main (10.0)
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While working on SOLR-14763, I found different behavior with
> *LBHttp2SolrClient* between *branch_9x* and {*}main/10.x{*}.
> If the first Endpoint in the list had previously failed, *branch_9x* will
> skip the failed Endpoint with subsequent requests, and begin requesting with
> the second Endpoint. If all remaining Endpoints fail, it will then retry the
> first Endpoint again.
> If the first Endpoint in the list had previously failed, *main/10.x* will
> always try the first Endpoint despite it being in the "Zombie List". When
> the first Endpoint fails again, it will re-try the second Endpoint.
> The *branch_9x* behavior seems more desirable as this minimizes unnecessary
> work by avoiding Endpoints that are known to fail. Indeed, *main/10.x* has an
> obvious bug in *EndpointIterator#fetchNext* where it attempts to get the
> wrong type of key for the map holding the Zombies. I believe this difference
> is a regression bug in *main/10x*.
> The different behavior is recorded in test
> *LBHttp2SolrClientTest#testAsyncWithFailures*. This test was added
> after-the-fact with SOLR-14763. I needed to change its "asserts" when
> backporting to *branch_9x* to account for the changed behavior.
--
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-17242) Http2SolrClient/HttpJdkSolrClient: Better handling of timeout parameters
James Dyer created SOLR-17242: - Summary: Http2SolrClient/HttpJdkSolrClient: Better handling of timeout parameters Key: SOLR-17242 URL: https://issues.apache.org/jira/browse/SOLR-17242 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: SolrJ Reporter: James Dyer This ticket is to address two related problems: 1. *Http2SolrClient* can throw NPE if the user does not specify timeout values when building the client. 2. *HttpJdkSolrClient* takes timeout values on its Builder, but applies them at the request level. It should apply them when building the client. -- 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-17234) LBHttp2SolrClient does not skip "zombie" endpoints
[
https://issues.apache.org/jira/browse/SOLR-17234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer reassigned SOLR-17234:
-
Assignee: James Dyer
> LBHttp2SolrClient does not skip "zombie" endpoints
> --
>
> Key: SOLR-17234
> URL: https://issues.apache.org/jira/browse/SOLR-17234
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: main (10.0)
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Major
>
> While working on SOLR-14763, I found different behavior with
> *LBHttp2SolrClient* between *branch_9x* and {*}main/10.x{*}.
> If the first Endpoint in the list had previously failed, *branch_9x* will
> skip the failed Endpoint with subsequent requests, and begin requesting with
> the second Endpoint. If all remaining Endpoints fail, it will then retry the
> first Endpoint again.
> If the first Endpoint in the list had previously failed, *main/10.x* will
> always try the first Endpoint despite it being in the "Zombie List". When
> the first Endpoint fails again, it will re-try the second Endpoint.
> The *branch_9x* behavior seems more desirable as this minimizes unnecessary
> work by avoiding Endpoints that are known to fail. Indeed, *main/10.x* has an
> obvious bug in *EndpointIterator#fetchNext* where it attempts to get the
> wrong type of key for the map holding the Zombies. I believe this difference
> is a regression bug in *main/10x*.
> The different behavior is recorded in test
> *LBHttp2SolrClientTest#testAsyncWithFailures*. This test was added
> after-the-fact with SOLR-14763. I needed to change its "asserts" when
> backporting to *branch_9x* to account for the changed behavior.
--
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-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838983#comment-17838983 ] James Dyer commented on SOLR-14763: --- Test *HttpJdkSolrClientTest.testAsyncAndCancel* has unreproducible failures after this ticket. With the new API this is a low-value test whose outcome is largely due to JDK behavior. I am removing this test entirely. > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Fix For: main (10.0), 9.6 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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] [Comment Edited] (SOLR-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837343#comment-17837343 ] James Dyer edited comment on SOLR-14763 at 4/18/24 12:54 PM: - [PR 2402|https://github.com/apache/solr/pull/2402] updates this for inclusion in 9.6. [PR 2407|https://github.com/apache/solr/pull/2407] removes deprecated APIs from 10.0/main. was (Author: jdyer): [PR 2402|https://github.com/apache/solr/pull/2402] updates this for inclusion in 9.6. Needs an additional PR to remove old deprecated API in 10.0. > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Fix For: main (10.0), 9.6 > > Time Spent: 7.5h > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-14763. --- Resolution: Fixed > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Fix For: main (10.0), 9.6 > > Time Spent: 7.5h > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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-17234) LBHttp2SolrClient does not skip "zombie" endpoints
James Dyer created SOLR-17234:
-
Summary: LBHttp2SolrClient does not skip "zombie" endpoints
Key: SOLR-17234
URL: https://issues.apache.org/jira/browse/SOLR-17234
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Affects Versions: main (10.0)
Reporter: James Dyer
While working on SOLR-14763, I found different behavior with
*LBHttp2SolrClient* between *branch_9x* and {*}main/10.x{*}.
If the first Endpoint in the list had previously failed, *branch_9x* will skip
the failed Endpoint with subsequent requests, and begin requesting with the
second Endpoint. If all remaining Endpoints fail, it will then retry the first
Endpoint again.
If the first Endpoint in the list had previously failed, *main/10.x* will
always try the first Endpoint despite it being in the "Zombie List". When the
first Endpoint fails again, it will re-try the second Endpoint.
The *branch_9x* behavior seems more desirable as this minimizes unnecessary
work by avoiding Endpoints that are known to fail. Indeed, *main/10.x* has an
obvious bug in *EndpointIterator#fetchNext* where it attempts to get the wrong
type of key for the map holding the Zombies. I believe this difference is a
regression bug in *main/10x*.
The different behavior is recorded in test
*LBHttp2SolrClientTest#testAsyncWithFailures*. This test was added
after-the-fact with SOLR-14763. I needed to change its "asserts" when
backporting to *branch_9x* to account for the changed behavior.
--
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-17066) Deprecate and remove core URLs in HttpSolrClient and friends
[
https://issues.apache.org/jira/browse/SOLR-17066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837819#comment-17837819
]
James Dyer commented on SOLR-17066:
---
[~gerlowskija] Can this ticket be closed?
> Deprecate and remove core URLs in HttpSolrClient and friends
>
>
> Key: SOLR-17066
> URL: https://issues.apache.org/jira/browse/SOLR-17066
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Major
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Currently, URL-driven SolrClients can consume a base URL that either ends in
> an API-version specific path ("/solr" for v1 APIs, "/api" for v2), or in the
> full path to a specific core or collection ("/solr/techproducts").
> The latter option causes a number of problems in practice. It prevents the
> client from being used for any "admin" requests or for requests to other
> cores or collections. (Short of running a regex on
> {{SolrClient.getBaseURL}}, it's hard to even tell which of these restrictions
> a given client might have.) And lastly, specifying such core/collection URL
> makes it tough mix and match v1 and v2 API requests within the same client
> (see SOLR-17044).
> We should give SolrJ users some similar way to default collection/cores
> without any of these downsides. One approach would be to extend the
> {{withDefaultCollection}} pattern currently established in
> {{CloudHttp2SolrClient.Builder}}.
> (IMO we should also revisit the division of responsibilities between
> SolrClient and SolrRequest implementations - maybe clients shouldn't,
> directly at least, be holding on to request-specific settings like the
> core/collection at all. But that's a much larger concern that we might not
> want to wade into here. See SOLR-10466 for more on this topic.)
--
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-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837343#comment-17837343 ] James Dyer commented on SOLR-14763: --- [PR 2402|https://github.com/apache/solr/pull/2402] updates this for inclusion in 9.6. Needs an additional PR to remove old deprecated API in 10.0. > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Fix For: main (10.0), 9.6 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-14763: -- Fix Version/s: main (10.0) 9.6 > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Fix For: main (10.0), 9.6 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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-14763) SolrJ Client Async HTTP/2 Requests
[ https://issues.apache.org/jira/browse/SOLR-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-14763: - Assignee: James Dyer > SolrJ Client Async HTTP/2 Requests > -- > > Key: SOLR-14763 > URL: https://issues.apache.org/jira/browse/SOLR-14763 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Affects Versions: 8.7 >Reporter: Rishi Sankar >Assignee: James Dyer >Priority: Major > Time Spent: 6h 10m > Remaining Estimate: 0h > > In SOLR-14354, [~caomanhdat] created an API to use Jetty async API to make > more thread efficient HttpShardHandler requests. This added public async > request APIs to Http2SolrClient and LBHttp2SolrClient. There are a few ways > this API can be improved, that I will track in this issue: > 1) Using a CompletableFuture-based async API signature, instead of using > internal custom interfaces (Cancellable, AsyncListener) - based on [this > discussion|https://lists.apache.org/thread.html/r548f318d9176c84ad1a4ed49ff182eeea9f82f26cb23e372244c8a23%40%3Cdev.lucene.apache.org%3E]. > 2) An async API is also useful in other HTTP/2 Solr clients as well, > particularly CloudHttp2SolrClient (SOLR-14675). I will add a requestAsync > method to the SolrClient class, with a default method that initially throws > an unsupported operation exception (maybe this can be later updated to use an > executor to handle the async request as a default impl). For now, I'll > override the default implementation in the Http2SolrClient and > CloudHttp2SolrClient. -- 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-17211) HttpJdkSolrClient: Support Async
[
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-17211.
---
Resolution: Fixed
> HttpJdkSolrClient: Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses
> *java.net.http.HttpClient* internally. This JDK client supports asynchronous
> requests, so the Jdk Solr Client likewise can have async support. This
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
> public Cancellable asyncRequest(
> SolrRequest solrRequest,
> String collection,
> AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.
--
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-17211) HttpJdkSolrClient: Support Async
[
https://issues.apache.org/jira/browse/SOLR-17211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer reassigned SOLR-17211:
-
Assignee: James Dyer
> HttpJdkSolrClient: Support Async
> -
>
> Key: SOLR-17211
> URL: https://issues.apache.org/jira/browse/SOLR-17211
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses
> *java.net.http.HttpClient* internally. This JDK client supports asynchronous
> requests, so the Jdk Solr Client likewise can have async support. This
> ticket is to:
> 1. Extract from *Http2SolrClient* method
> {code:java}
> public Cancellable asyncRequest(
> SolrRequest solrRequest,
> String collection,
> AsyncListener> asyncListener)
> {code}
> 2. Implement on *HttpJdkSolrClient*
> 3. Add javadoc for both clients.
> 4. Add unit tests for both clients.
--
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-17211) HttpJdkSolrClient: Support Async
James Dyer created SOLR-17211:
-
Summary: HttpJdkSolrClient: Support Async
Key: SOLR-17211
URL: https://issues.apache.org/jira/browse/SOLR-17211
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrJ
Reporter: James Dyer
With SOLR-599 we added a new SolrJ client *HttpJdkSolrClient* which uses
*java.net.http.HttpClient* internally. This JDK client supports asynchronous
requests, so the Jdk Solr Client likewise can have async support. This ticket
is to:
1. Extract from *Http2SolrClient* method
{code:java}
public Cancellable asyncRequest(
SolrRequest solrRequest,
String collection,
AsyncListener> asyncListener)
{code}
2. Implement on *HttpJdkSolrClient*
3. Add javadoc for both clients.
4. Add unit tests for both clients.
--
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-17205) De-couple SolrJ required Java version from server Java version (main)
[ https://issues.apache.org/jira/browse/SOLR-17205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829233#comment-17829233 ] James Dyer commented on SOLR-17205: --- I had initially misunderstood the suggestion, but David had the idea that in the "close" method, we could simply check if the client implements closable and if so, cast it and call "close". This would give the users the best possible experience without adding much complexity. This won't help with removing the unit test "after" hacks that ensure the client's threads are cleaned up, however. Beyond that, I am not sure what other JDK Http Client enhancements we might want from Java 21? > De-couple SolrJ required Java version from server Java version (main) > - > > Key: SOLR-17205 > URL: https://issues.apache.org/jira/browse/SOLR-17205 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Solr 9.x requires Java 11, both for server and solrj client. > In Solr 10 we will likely bump required java version to Java 17, or maybe > even 21, and since we are a standalone app we can do that - on the > server-side. > However, to give SolrJ client a broadest possible compatibility with customer > application environments, we should consider de-coupling SolrJ's java > requirement from the server-side. That would allow us to be progressive on > the server side Java without forcing users to stay on latest Java in their > apps. > I don't know if it makes much sense to be compatible too far back on EOL java > versions, but perhaps let SolrJ stay one LTS version behind the server for > broad compatibility. -- 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-17161) Separate out a solrj-jetty package / artifact
[
https://issues.apache.org/jira/browse/SOLR-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826079#comment-17826079
]
James Dyer commented on SOLR-17161:
---
Would it be easier to go the other way with this, and extract out a
"solrj-core" that doesn't have any dependencies (other than slf4j), rather than
move out the jetty dependencies?
> Separate out a solrj-jetty package / artifact
> -
>
> Key: SOLR-17161
> URL: https://issues.apache.org/jira/browse/SOLR-17161
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
>Reporter: Jan Høydahl
>Priority: Major
>
> Given we have a native JDK based client in SOLR-599, we can separate out all
> {{Http2SolrClient}} and freiends with their jetty-client dependencies into a
> separate artifact {{{}solrj-jetty{}}}.
--
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-15730) Modularize SolrJ
[ https://issues.apache.org/jira/browse/SOLR-15730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826072#comment-17826072 ] James Dyer commented on SOLR-15730: --- bq. If we could make the main org.apache.solr.solrj:solrj package 100% dependency-less, except slf4j, that would be fantastic. That is for sure something to look into. I know for the application I maintain, solrj is one of those things that seems to pull in needless dependencies, and things that sometime cause conflicts, so getting to this for the basic use-cases would be a good step forward. > Modularize SolrJ > > > Key: SOLR-15730 > URL: https://issues.apache.org/jira/browse/SOLR-15730 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: Jan Høydahl >Priority: Major > Attachments: Skjermbilde 2021-10-28 kl. 15.38.40.png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Umbrella issue for breaking up SolrJ into a slim solrj-core with minimal > dependencies as well as solrj-zk, solrj-streaming, solrj-jdbc etc as needed. > We can move relevant other JIRAs as sub-tasks to this one to keep everything > together. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17826070#comment-17826070 ] James Dyer commented on SOLR-599: - bq. Would not this allow for a CloudHttpJdkSolrClient next, without requiring more dependencies? I think so, but we might need a Load Balancing Jdk Client first? Also, doesn't CloudSolrClient pull in zookeeper as a client-side dependency? My thinking here is users that use CSC are perhaps not too concerned with transitive dependencies? > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8.5h > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > -java.net.HttpUrlConnection- java.net.http.HttpClient and will use > BinaryResponseParser as the default response parser. Using this basic > implementation out of the box would require no dependencies on either > commons-httpclient or StAX. The only dependency would be on solr-commons > making this a very lightweight and distribution friendly Java client for Solr. > - > h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on > the actual resolution. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-599: Description: SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by -java.net.HttpUrlConnection- java.net.http.HttpClient and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. - h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on the actual resolution. was: SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by -java.net.HttpUrlConnection- java.net.http.HttpClient and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h 10m > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > -java.net.HttpUrlConnection- java.net.http.HttpClient and will use > BinaryResponseParser as the default response parser. Using this basic > implementation out of the box would require no dependencies on either > commons-httpclient or StAX. The only dependency would be on solr-commons > making this a very lightweight and distribution friendly Java client for Solr. > - > h3. See PR [#2259|https://github.com/apache/solr/pull/2259] for details on > the actual resolution. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-599: Description: SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by -java.net.HttpUrlConnection- java.net.http.HttpClient and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. was: SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h 10m > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > -java.net.HttpUrlConnection- java.net.http.HttpClient and will use > BinaryResponseParser as the default response parser. Using this basic > implementation out of the box would require no dependencies on either > commons-httpclient or StAX. The only dependency would be on solr-commons > making this a very lightweight and distribution friendly Java client for Solr. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-599. - Resolution: Fixed > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h 10m > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > java.net.HttpUrlConnection and will use BinaryResponseParser as the default > response parser. Using this basic implementation out of the box would require > no dependencies on either commons-httpclient or StAX. The only dependency > would be on solr-commons making this a very lightweight and distribution > friendly Java client for Solr. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-599: Fix Version/s: main (10.0) 9.6.0 (was: 4.9) (was: 6.0) > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: main (10.0), 9.6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h 10m > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > java.net.HttpUrlConnection and will use BinaryResponseParser as the default > response parser. Using this basic implementation out of the box would require > no dependencies on either commons-httpclient or StAX. The only dependency > would be on solr-commons making this a very lightweight and distribution > friendly Java client for Solr. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825677#comment-17825677 ] James Dyer commented on SOLR-599: - I plan on merging this shortly as *HttpJdkSolrClient*. I appreciate the time both Jan and especially you, David, have taken to review this. > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Priority: Minor > Fix For: 4.9, 6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > java.net.HttpUrlConnection and will use BinaryResponseParser as the default > response parser. Using this basic implementation out of the box would require > no dependencies on either commons-httpclient or StAX. The only dependency > would be on solr-commons making this a very lightweight and distribution > friendly Java client for Solr. -- 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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer reassigned SOLR-599: --- Assignee: James Dyer > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Assignee: James Dyer >Priority: Minor > Fix For: 4.9, 6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > Time Spent: 8h > Remaining Estimate: 0h > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > java.net.HttpUrlConnection and will use BinaryResponseParser as the default > response parser. Using this basic implementation out of the box would require > no dependencies on either commons-httpclient or StAX. The only dependency > would be on solr-commons making this a very lightweight and distribution > friendly Java client for Solr. -- 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-16078) New solrj-core module
[
https://issues.apache.org/jira/browse/SOLR-16078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817448#comment-17817448
]
James Dyer commented on SOLR-16078:
---
bq. Can we even get rid of jackson, or is it needed for JSON
I was thinking about this and was wondering if it would be possible, even if we
need a JSON parser, to have one solrj maven coordinate that only depended on
slf4j and nothing else. This would be for those applications running in a
JakartaEE-compliant environment. Then a separate artifact would pull in
Jackson for those users who do not have JSONB provided by the environment. I
do not know what it would take to accomplish this or if it is worth it.
> New solrj-core module
> -
>
> Key: SOLR-16078
> URL: https://issues.apache.org/jira/browse/SOLR-16078
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should introduce a solrj-core module that is as slim as possible wrt
> dependencies.
> A user will then add solrj-core as well as any other solj-xx modules needed
> for their use.
> By marking it {{\@lucene.experimental}} we can change the API of this
> solrj-core during 9.x as we move stuff into other modules.
--
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-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817183#comment-17817183 ] James Dyer commented on SOLR-599: - See PR [#2259|https://github.com/apache/solr/pull/2259], which is related to this issue. This PR adds a Solr client using the built-in Java 11+ Http Client. > Lightweight SolrJ client > > > Key: SOLR-599 > URL: https://issues.apache.org/jira/browse/SOLR-599 > Project: Solr > Issue Type: Improvement > Components: clients - java, SolrJ >Reporter: Shalin Shekhar Mangar >Priority: Minor > Fix For: 4.9, 6.0 > > Attachments: SOLR-599-fix-for-SolrJ-on-GAE.patch, SOLR-599.patch, > SOLR-599.patch > > > SolrJ provides a SolrServer implementation backed by commons-httpclient which > introduces many dependency jars (commons-codec, commons-io and > commons-logging). Apart from that SolrJ also uses StAX API for XML parsing > which introduces dependencies like stax-api, stax and stax-utils. > This enhancement will add a SolrServer implementation backed by > java.net.HttpUrlConnection and will use BinaryResponseParser as the default > response parser. Using this basic implementation out of the box would require > no dependencies on either commons-httpclient or StAX. The only dependency > would be on solr-commons making this a very lightweight and distribution > friendly Java client for Solr. -- 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-16367) Umbrella: Migrate away from Apache HttpClient.
[ https://issues.apache.org/jira/browse/SOLR-16367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812443#comment-17812443 ] James Dyer commented on SOLR-16367: --- I was wondering if any thought was made to use *java.net.http.HttpClient* instead of the Jetty Http Client? If the functionality is adequate, we could reduce the dependencies that SolrJ brings in. > Umbrella: Migrate away from Apache HttpClient. > -- > > Key: SOLR-16367 > URL: https://issues.apache.org/jira/browse/SOLR-16367 > Project: Solr > Issue Type: Improvement >Reporter: David Smiley >Priority: Blocker > Fix For: main (10.0) > > > This is an umbrella issue to migrate away from using Apache HttpClient to > alternatives, namely Jetty HttpClient. Supporting both is hard to maintain, > and furthermore Jetty supports HTTP 2. Sub-tasks and linked issues will > accomplish this. When this umbrella is done, Apache HttpClient will not be > used in solr-core or solrj. Modules may use it only if required by > dependencies. HttpSolrClient (which uses Apache HttpClient) can still exist > but in its own opt-in SolrJ module. -- 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-15484) Frequent test failures for JWTAuthPluginIntegrationTest
[
https://issues.apache.org/jira/browse/SOLR-15484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794477#comment-17794477
]
James Dyer commented on SOLR-15484:
---
[~Don-vip] Would you be willing to try the latest changes in [PR
#2099|https://github.com/apache/solr/pull/2099] with your setup?
> Frequent test failures for JWTAuthPluginIntegrationTest
> ---
>
> Key: SOLR-15484
> URL: https://issues.apache.org/jira/browse/SOLR-15484
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.0
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Example:
> Build: [https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/1053/]
> {code}
> 1 tests failed.
> FAILED:
> org.apache.solr.security.JWTAuthPluginIntegrationTest.mockOAuth2Server
> Error Message:
> org.junit.ComparisonFailure: Should have received 401 code expected:<[401]>
> but was:<[200]>
> Stack Trace:
> org.junit.ComparisonFailure: Should have received 401 code expected:<[401]>
> but was:<[200]>
> at __randomizedtesting.SeedInfo.seed([7827798BF4D91EFE:FF2798DB9165E212]:0)
> at org.junit.Assert.assertEquals(Assert.java:117)
> at
> org.apache.solr.security.JWTAuthPluginIntegrationTest.mockOAuth2Server(JWTAuthPluginIntegrationTest.java:143)
> ...
> {code}
> The other test failure is
> {code}
> org.apache.solr.security.JWTAuthPluginTest.initWithInvalidTrustedCertsFile
> Failing for the past 1 build (Since #924 )
> Took 7 ms.
> Error Message
> junit.framework.AssertionFailedError: Expected exception SolrException but no
> exception was thrown
> Stacktrace
> junit.framework.AssertionFailedError: Expected exception SolrException but no
> exception was thrown
> at
> __randomizedtesting.SeedInfo.seed([8651FF5FA6DE29A1:91C33C9AFD0459B5]:0)
> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2863)
> at
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2849)
> at
> org.apache.solr.security.JWTAuthPluginTest.initWithInvalidTrustedCertsFile(JWTAuthPluginTest.java:521)
> ...
> {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
