[ 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:56 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 arrived at 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 (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. > 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