[ 
https://issues.apache.org/jira/browse/SOLR-5360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797989#comment-13797989
 ] 

Per Steffensen commented on SOLR-5360:
--------------------------------------

bq. It seems like "cannot do realtime-gets" is too strong? There are plenty of 
use-cases where going to any active replica should be fine.

My impression is that it does not work. Unlike updates and searches, 
realtime-gets are not re-routed on server-side, so you have to hit the correct 
shard directly from the client. Try running the provided test 
(CloudRealTimeGetTest) without my fix in CloudSolrServer.

bq. In your optimistic locking scenario, there should be no correctness issue, 
but just a performance/efficiency issue, right?

No I do not think so, because of the no-re-routing issue. It would be nice to 
have re-routing on server-side, and then the fix I provided to CloudSolrServer 
will just be an optimization.


> Correctly routed realtime-get through CloudSolrServer
> -----------------------------------------------------
>
>                 Key: SOLR-5360
>                 URL: https://issues.apache.org/jira/browse/SOLR-5360
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>    Affects Versions: 4.5
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: get, realtime
>             Fix For: 4.6
>
>         Attachments: SOLR-5360.patch
>
>
> Today you cannot do realtime-gets through CloudSolrServer, because it will 
> not route the request to the correct replica (the leader-replica of the shard 
> where the document to be fetched lives according to routing rules)
> Doing realtime-gets from clients are important in several scenarios. For 
> example in common optimistic locking scenario. Pseudo-code:
> {code}
> public void createOrUpdateDoc(String id, ChangeInfo changes) {
>     outherLoop: while(true) {
>         try {
>             // Assume that document with id does not exist already
>             // Just try to store it as a new document
>             SolrInputDocument newDoc = createNewSolrInputDocument(id, 
> changes); 
>             sendUpdateRequestToSolr(newDoc);
>             return;
>         } catch (DocumentAlreadyExists e) {
>             // Ok the document already existed
>             while(true) {
>                 // Fetch the existing document - realtime-get so that you do 
> not
>                 // have to wait until next commit to be able to fetch it, if 
> the document
>                 // was created/updated after last commit
>                 SolrDocument fetchedDoc = realTimeGet(id);
>                 // Merge the changes into the existing document
>                 // Including copy of _version_ from fetchedDoc to updatedDoc
>                 SolrInputDocument updatedDoc = merge(fetchedDoc, changes);
>                 // Try to store the updated document
>                 try {
>                     sendUpdateRequestToSolr(updatedDoc);
>                     return;
>                 } catch (VersionConflict e) {
>                     // Someone updated the doc, between my fetch and update
>                     // Ignore, just take another round in the inner 
> while(true)-loop
>                 } catch (DocumentDoesNotExist e) {
>                     // Someone deleted the document since when I tried to
>                     // create it as a new document the first time
>                     // Will create it again by taking another round in outher
>                     // while(true)-loop
>                     continue outherLoop;
>                 }
>             }
>         }
>     }
> }
> {code}
> Sorry if the code is not perfect, but I just wrote it directly here - I sure 
> you get the idea.
> I would like to enable realtime-get through CloudSolrServer in order to be 
> able to do scenarios as e.g. the one shown above



--
This message was sent by Atlassian JIRA
(v6.1#6144)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to