[
https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894298#comment-13894298
]
Martin Grotzke commented on SOLR-3383:
--------------------------------------
I'm also interested in async responses in solrj, but instead of using java
Futures, I'd prefer a callback based interface, e.g. via onSuccess(callback)
and onError(callback), much like scala Futures work.
> Async responses in SolrJ
> ------------------------
>
> Key: SOLR-3383
> URL: https://issues.apache.org/jira/browse/SOLR-3383
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 3.5
> Reporter: Per Steffensen
> Assignee: Per Steffensen
> Labels: async, asynchronous, concurrency, query, solrj, update
> Fix For: 4.7
>
> Attachments: SOLR-3383.patch
>
>
> Today it is like this
> - SolrServer.request returns NamedList<Object>
> - SolrRequest.process returns SolrResponse
> - Public methods on SolrServer like addX, optimize, commit, queryX etc.
> returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse)
> - etc
> This is all synchronous - that is, the calling thread of those methods will
> wait for the response before being able to continue. I believe the industry
> today agrees that "operations" like client-server network-requireing
> operations should be done asynchronously seens from the client API. Therefore
> basically we should change those methods
> - SolrServer.request returns Future<NamedList<Object>>
> - SolrRequest.process returns Future<SolrResponse>
> - SolrServer.xxx returns Future<subclass of SolrResponse>
> and make the appropriate changes in the implementations below.
> My main argument for this right now, is that ConcurrentUpdateSolrServer
> really is not able to hand over responses to the calling client. Guess that
> it is also the reason why it is only a "Update"-SolrServer and not a complete
> SolrServer (being able to do queries etc.) - updates does not require sending
> responses (except primitive errors) back to the client, queries etc does. Now
> that we do "finegrained error propagation" (SOLR-3382) in order to send
> "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178)
> back to the client in responses to update-request, suddenly it is not true
> anymore that updates does not require sending responses back to the client.
> Making the changes suggested above (returning Futures) would
> - Allow ConcurrentUpdateSolrServer to be used for updates potentially
> resulting in "unique key constraint"- and "versioning"-errors
> - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also
> being able to do queries etc
> - Do cool stuff like SOLR-3384
> - Make SolrJ more modern with respect to asynchronous principles
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
