lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-3383) Async responses in SolrJ
Date Fri, 20 Apr 2012 09:40:40 GMT

     [ https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Per Steffensen updated SOLR-3383:
---------------------------------

    Description: 
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
- Make SolrJ more modern with respect to asynchronous principles


  was:
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
- Make Solr more modern with respect to asynchronous principles


    
> 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.0
>
>
> 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
> - 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message