lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5944) Support updates of numeric DocValues
Date Thu, 09 Jun 2016 18:27:21 GMT

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

Hoss Man commented on SOLR-5944:
--------------------------------


I don't understand this comment -- particularly in light of the changes you've made to the
test since...

{quote}
bq. what's the point of using a threadpool and SendUpdateToReplicaTask here? why not just
send the updates in a (randdomly assigned) determinisitc order? 

Essentially, I need a way to send three updates to the replica asynchronously. To achieve
the effect of asynchronous updates, I used a threadpool here. Three updates sent one after
the other, each being a blocking call, wouldn't have simulated the leader -> replica interaction
sufficiently.
{quote}

When i posted that particular question it was about outOfOrderUpdatesIndividualReplicaTest
-- the code in question at teh time looked like this...

{code}
// re-order the updates for replica2
List<UpdateRequest> reorderedUpdates = new ArrayList<>(updates);
Collections.shuffle(reorderedUpdates, random());
for (UpdateRequest update : reorderedUpdates) {
  SendUpdateToReplicaTask task = new SendUpdateToReplicaTask(update, clients.get(1), random());
  threadpool.submit(task);
}
{code}

...My impression, based on the entirety of that method, was that the intent of the test was
to bypass the normal distributed update logic and send carefully crafted "simulated" updates
direct to each replica, such that one repliica got the (simulated from leader) updates "in
order" and another replica got the (simulated from leader) updates "out of order"

* if the point was for replica2 to get the (simulated from leader) updates "out of order"
then why shuffle them - why not explicitly put them in the "wrong" order?
* if the goal was send them asynchronously, and try to get them to happen as concurrently
as possible (as you indicated above in your answer to my question) then what was the point
of the "shuffle" ?

Looking at the modified version of that code in your latest patch doesn't really help clarify
things for me...

{code}
// re-order the updates for NONLEADER 0
List<UpdateRequest> reorderedUpdates = new ArrayList<>(updates);
Collections.shuffle(reorderedUpdates, random());
List<Future<UpdateResponse>> updateResponses = new ArrayList<>();
for (UpdateRequest update : reorderedUpdates) {
  AsyncUpdateWithRandomCommit task = new AsyncUpdateWithRandomCommit(update, NONLEADERS.get(0),
seed);
  updateResponses.add(threadpool.submit(task));
  // send the updates with a slight delay in between so that they arrive in the intended order
  Thread.sleep(10);
}
{code}

In the context of your answer, that it's intentional for the updates to be async...

* why shuffle them?
* why is there now a {{sleep}} call with an explicit comment "...so that they arrive in the
intended order" ... if there is an "intended" order why would you want them to be async?

the other SendUpdateToReplicaTask/AsyncUpdateWithRandomCommit usages exhibit the same behavior
of a "sleep" in between {{ threadpool.submit(task); }} calls with similar comments about wanting
to "...ensure requests are sequential..." hence my question about why threadpools are being
used at all.

> Support updates of numeric DocValues
> ------------------------------------
>
>                 Key: SOLR-5944
>                 URL: https://issues.apache.org/jira/browse/SOLR-5944
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Ishan Chattopadhyaya
>            Assignee: Shalin Shekhar Mangar
>         Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt,
TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, TestStressInPlaceUpdates.eb044ac71.failures.tar.gz,
hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt,
hoss.D768DD9443A98DC.fail.txt, hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be really nice
to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message