Cool. I think also we'd need a new SolrDeletionPolicy which keeps at least the last explicit user COMMIT, even if Autocommit/CommitWithins have happened after.
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 10. mai 2013 kl. 19:20 skrev Shalin Shekhar Mangar <shalinman...@gmail.com>: > There's an issue open: https://issues.apache.org/jira/browse/SOLR-2701 > > > On Fri, May 10, 2013 at 10:14 AM, Varun Thacker <varunthacker1...@gmail.com> > wrote: > Hi, > > Rollback is a good feature for people who are using Solr in non SolrCloud > mode. > > I like Jan's idea of exposing IW.commit(Map<String,String> commitUserData) to > Solr. A quick look at this shows that this doesn't exist yet > (http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22) > > Then we could probably let the user pass the commitUserData which he tagged > the commit with to rollback, and perform a rollback. Basically rollbacks can > only be preformed to a commit which has been explicitly tagged. > > I think this should solve a lot of problems regarding rollback. If this is > solvable using this method I'll create the necessary JIRA's to fix it. > > This method should also fix this issue pointed out I think. > https://issues.apache.org/jira/browse/SOLR-4733 > > Mark, This idea or any other approach still wouldn't support rollbacks in > SolrCloud right? > > > > On Fri, May 10, 2013 at 5:21 AM, Jan Høydahl <jan....@cominvent.com> wrote: > Hi, > > Thanks for clarifying, I have been thinking that full RAMbuffer triggered a > commit, but I now see the difference between a flush of a segment and further > down the road a commit which then links all these intermediate segments with > that particular commit. > > So ROLLBACK closes the writer but instead of persisting docs with a commit, > it cleans up all uncommitted (flushed or not) doc and files. This is actually > not as bad as I thought. > > So the main catch with ROLLBACK then is if COMMITs are done by other clients > or if autoCommit or commitWithin is being used. However, after reading > http://blog.mikemccandless.com/2012/03/transactional-lucene.html I see that > it is possible to tag COMMITs with userData, so we could make the rollback > actually roll back to the last explicit commit (still assuming you're the > only client around) if, say AutoCommits and CommitWithins are tagged as such. > > So I'm OK if you guys rather want to start improve the ROLLBACK API instead > of deprecating it. A client should be certain that ALL docs since last commit > gets rolled back, else the rollback command must fail. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > 9. mai 2013 kl. 20:49 skrev Mikhail Khludnev <mkhlud...@griddynamics.com>: > >> Mark, >> thanks for confirming my feeling. >> >> Hence, I ask for leaving it for "old-school" deployments. However, it's a >> good thing to clearly indicate to the user that it's not implemented for >> tlog. What about log WARN/ERROR and/or throw an exception with explanation? >> >> >> >> On Thu, May 9, 2013 at 10:28 AM, Jack Krupansky <j...@basetechnology.com> >> wrote: >> This does highlight that rollback is perfectly reasonable for embedded Solr >> or other "dedicated", single-node, well-controlled apps, even if it doesn't >> work for cloud. >> >> -- Jack Krupansky >> >> -----Original Message----- From: Mark Miller >> Sent: Thursday, May 09, 2013 1:09 PM >> >> To: dev@lucene.apache.org >> Subject: Re: [Discussion] Discontinue the ROLLBACK command in Solr? >> >> RAMbuffer doesn't affect this stuff - if you rollback, it rolls back to the >> last commit point. Flushed segments are fine. >> >> - Mark >> >> On May 9, 2013, at 12:54 PM, Mikhail Khludnev <mkhlud...@griddynamics.com> >> wrote: >> >> Jan, >> Could you please clarify current rollback functionality to me? Let's I have >> autoCommit disabled, but my RAMbuffer is not huge, hence I have few flushes >> after previous commit. if I invoke rollback will it forget about flushed >> segments? >> >> >> >> On Thu, May 2, 2013 at 12:38 AM, Jan Høydahl <jan....@cominvent.com> wrote: >> Hi, >> >> Many are confused about the rollback feature in Solr, since it cannot >> guarantee a rollback of updates from that client since last commit. >> >> In my opinion it is pretty useless to have a rollback feature you cannot >> rely upon - Unless, that is, you are the only client for sure, having no >> autoCommit, and a huge RAMbuffer. >> >> So why don't we simply deprecate the feature in 4.x and remove it from 5.0? >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com >> Solr Training - www.solrtraining.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >> -- >> Sincerely yours >> Mikhail Khludnev >> Principal Engineer, >> Grid Dynamics >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >> -- >> Sincerely yours >> Mikhail Khludnev >> Principal Engineer, >> Grid Dynamics >> >> > > > > > -- > > > Regards, > Varun Thacker > http://www.vthacker.in/ > > > > -- > Regards, > Shalin Shekhar Mangar.
