[
https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-3383:
------------------------------
Fix Version/s: (was: 4.1)
5.0
4.2
> 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.2, 5.0
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
