[
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15323101#comment-15323101
]
Ishan Chattopadhyaya edited comment on SOLR-5944 at 6/9/16 6:54 PM:
--------------------------------------------------------------------
When update2 (say a partial update) arrives before update1 (say a full update,
on which update2 depends), then the call for indexing update2 is a blocking
call (which finishes either after update1 is indexed, or timeout is reached).
The intention was to:
# shuffle the updates (so that the 3 updates are in one of the 6 possible
permutations, one of those permutations being in-order)
# send them out in sequence of the shuffle
# have them arrive at Solr in the intended order (as intended in steps 1 and
2). However, since an out of order update waits for the dependent update and
blocks the call until such a dependent update arrives (or timeout is reached),
the intention is to have these calls non-blocking.
So, I wanted to send updates out sequentially (deliberately re-ordered, through
a shuffle), but asynchronously (so as to keep those calls non-blocking).
bq. ...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"
That is exactly my intention.
bq. 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?
There could be possibly 6 permutations in terms of the mutual ordering of the 3
updates, so I used shuffle instead of choosing a particular "wrong" ordering.
Of course, one of those 6 permutations is the "right" order, so that case is
not consistent with the name of the test; I can make a fix to exclude that case.
bq. 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" ?
I think I was trying: (a) asynchronously (so that out of order update doesn't
block out the next update request that sends a dependent order), (b) intention
was not really to test for race conditions (i.e. not really "as concurrently as
possible", but maybe I don't understand the phrase correctly), but just to be
concurrent enough so that a dependent update arrives before an out of order
update times out.
bq. Thread.sleep(10);
The point of this was to avoid situations where the shuffled list (and intended
order for that testcase) was, say, "update1, update3, update2", but it actually
went to the Solr server in the order "update1, update2, update3" due to
parallel threads sending the updates at nearly the same time.
Do you think this makes sense? I am open to revise this entire logic if you
suggest.
was (Author: ichattopadhyaya):
When update2 (say a partial update) arrives before update1 (say a full update,
on which update2 depends), then the call for indexing update2 is a blocking
call (which finishes either after update1 is indexed, or timeout is reached).
The intention was to:
# shuffle the updates (so that the 3 updates are in one of the 6 possible
permutations, one of those permutations being in-order)
# send them out in sequence of the shuffle
# have them arrive at Solr in the intended order (as intended in steps 1 and
2). However, since an out of order update waits for the dependent update and
blocks the call until such a dependent update arrives (or timeout is reached),
the intention is to have these calls non-blocking.
So, I wanted to send updates out sequentially (deliberately re-ordered, through
a shuffle), but asynchronously (so as to keep those calls non-blocking).
bq. ...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"
That is exactly my intention.
bq. 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?
There could be possibly 6 permutations in terms of the mutual ordering of the 3
updates, so I used shuffle instead of choosing a particular "wrong" ordering.
Of course, one of those 6 permutations is the "right" order, so that case is
not consistent with the name of the test; I can make a fix to exclude that case.
bq. 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" ?
I think I was trying: (a) asynchronously (so that out of order update doesn't
block out the next update request that sends a dependent order), (b) intention
was not really to test for race conditions, but just to be concurrent enough so
that a dependent update arrives before an out of order update times out.
bq. Thread.sleep(10);
The point of this was to avoid situations where the shuffled list (and intended
order for that testcase) was, say, "update1, update3, update2", but it actually
went to the Solr server in the order "update1, update2, update3" due to
parallel threads sending the updates at nearly the same time.
Do you think this makes sense? I am open to revise this entire logic if you
suggest.
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
