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/
