[
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: [email protected]
For additional commands, e-mail: [email protected]
