Maybe the method could be overloaded with an executor... there's a balance
between expert control and simplicity. Shrug.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, Aug 6, 2020 at 10:56 AM Bram Van Dam wrote:
> > public CompletableFuture>
> public CompletableFuture>
requestAsync(SolrRequest request);
NamedList aside, this looks like a great async API to me. But I
would still like some control over the thread pool/executor that's being
used.
Maybe that doesn't have to be part of the requestAysnc method signature,
maybe it could be
On Sun, Aug 2, 2020 at 10:47 AM Atri Sharma wrote:
> I am +1 to this approach. Some thoughts inline.
>
> How would query timeout be respected in this approach?
>
The backend would need to "complete exceptionally" with a timeout
exception we think is appropriate. It'd call
completableFuture.com
+1 I and a few of my former Lucidworks colleagues know the pain of the
synchronous client very well.
Thanks for the first step toward an improved design Dat and David Smiley!
Marcus
On Sun, Aug 2, 2020 at 07:47 Atri Sharma wrote:
> I am +1 to this approach. Some thoughts inline.
>
> How would
I am +1 to this approach. Some thoughts inline.
How would query timeout be respected in this approach?
>
The default approach might be configured to throw
> UnsupportedOperationException, or perhaps might simply use an Executor to
> get it done in an obvious way (assuming we can get ahold of an
The new API seems good to me. it does be able to handle all cases : future,
listener and error handling.
On Sat, Aug 1, 2020 at 10:15 AM David Smiley
wrote:
> Noble: Those sound like some big and bold ideas that are deserving of a
> separate conversation? My proposal here is based on the APIs w
Noble: Those sound like some big and bold ideas that are deserving of a
separate conversation? My proposal here is based on the APIs we have today.
~ David
On Fri, Jul 31, 2020 at 10:06 PM Noble Paul wrote:
> I would also wish to deprecate all the public APIs which uses concrete
> classes and
I would also wish to deprecate all the public APIs which uses concrete
classes and move over to interfaces.
The objectives are.
* We should be able to use POJOs that help with strong typing
* We should be able to easily switch between JSON/javabin/XML or even
well known protocols like protobuf
On
Thanks David for bringing this up.
I want us to stop using concrete classes. We should exclusively use
interfaces in our public APIs.
We should stop using NamedList and start using this interface
https://github.com/apache/lucene-solr/blob/b91b461632b19c9488926a9302126a2158df3298/solr/solrj/src/j
Hello devs,
I'd like to have an API design discussion here on the dev list concerning
adding asynchronous request semantics to SolrClient. I think the
SolrClient APIs require great peer-review consideration and so I'm having
this discussion here instead of a JIRA issue.
Background: Sometimes, a
10 matches
Mail list logo
