[
https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894378#comment-13894378
]
Per Steffensen commented on SOLR-3383:
--------------------------------------
[~martin.grotzke], we made a java-Futures implementation long ago. We have it
on some branch somewhere. We never got around to finish it, because we decided
that it was not high priority at the moment. We will not prioritize to finish
it any time soon. Callback thingy could also be interesting - maybe support
both java-Futures and callback. Guess if you want this, you will have to make
it yourself. Guess I can give you a patch with our changes, but it will fit a
very old version of Solr - probably somewhere before 4.0.0 was even released.
You will definitely have to work on it afterwards.
> 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]
