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.htmlI >> 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-unsubscribe@lucene.apache.**org<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-unsubscribe@lucene.apache.**org<dev-unsubscr...@lucene.apache.org> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@lucene.apache.**org<dev-unsubscr...@lucene.apache.org> >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> >> >> -- >> Sincerely yours >> Mikhail Khludnev >> Principal Engineer, >> Grid Dynamics >> >> <http://www.griddynamics.com/> >> <mkhlud...@griddynamics.com> >> >> >> > > > -- > > > Regards, > Varun Thacker > http://www.vthacker.in/ > -- Regards, Shalin Shekhar Mangar.
