You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Jan Høydahl <ja...@cominvent.com> on 2013/05/02 09:38:37 UTC
[Discussion] Discontinue the ROLLBACK command in Solr?
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
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Mark Miller <ma...@gmail.com>.
+1, not a fan.
Also, doesn't work in SolrCloud either.
- Mark
On May 8, 2013, at 9:08 PM, Chris Hostetter <ho...@fucit.org> wrote:
>
> : 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?
>
> +1 ... i don't remember the details of how/why/where rollback works, but
> as i understand it, there are some serious caveats to it's usage, as well
> as some bugs that may not have any viable/simple solutions (at least as
> far as i know of).
>
> example...
> https://issues.apache.org/jira/browse/SOLR-4733
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by "Dyer, James" <Ja...@ingramcontent.com>.
We use rollback (in conjunction with DIH) when doing full re-imports on a traditional "non-cloud" index. As DIH first deletes all documents then adds them all, its handy for it to roll back its changes if something goes wrong. Then the indexing node can simply return to service executing queries until the problem is solved, etc.
Would it be acceptable to retain rollback for non-cloud indexes that do not have atomic updates, etc enabled? We could even put an "enable rollback" parameter in the config that is by default turned off so users can be made to think about it before turning it on, etc.
Of course, if rollback was removed, the workaround is to take a backup, then attempt reindex, then replace the backup on failure. This is custom scripting that is currently done automatically.
James Dyer
Ingram Content Group
(615) 213-4311
-----Original Message-----
From: Chris Hostetter [mailto:hossman_lucene@fucit.org]
Sent: Wednesday, May 08, 2013 8:08 PM
To: dev@lucene.apache.org
Subject: Re: [Discussion] Discontinue the ROLLBACK command in Solr?
: 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?
+1 ... i don't remember the details of how/why/where rollback works, but
as i understand it, there are some serious caveats to it's usage, as well
as some bugs that may not have any viable/simple solutions (at least as
far as i know of).
example...
https://issues.apache.org/jira/browse/SOLR-4733
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Chris Hostetter <ho...@fucit.org>.
: 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?
+1 ... i don't remember the details of how/why/where rollback works, but
as i understand it, there are some serious caveats to it's usage, as well
as some bugs that may not have any viable/simple solutions (at least as
far as i know of).
example...
https://issues.apache.org/jira/browse/SOLR-4733
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <sh...@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 <va...@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 <ja...@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 <mk...@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 <ja...@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 <mk...@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 <ja...@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
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>>
>
>
>
>
> --
>
>
> Regards,
> Varun Thacker
> http://www.vthacker.in/
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Shalin Shekhar Mangar <sh...@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
<va...@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 <ja...@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 <mkhludnev@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 <ja...@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 <
>>> mkhludnev@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 <ja...@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<de...@lucene.apache.org>
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sincerely yours
>>>> Mikhail Khludnev
>>>> Principal Engineer,
>>>> Grid Dynamics
>>>>
>>>>
>>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>> <http://www.griddynamics.com/>
>> <mk...@griddynamics.com>
>>
>>
>>
>
>
> --
>
>
> Regards,
> Varun Thacker
> http://www.vthacker.in/
>
--
Regards,
Shalin Shekhar Mangar.
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Varun Thacker <va...@gmail.com>.
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 <ja...@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 <mk...@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 <ja...@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 <mk...@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 <ja...@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<de...@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> Sincerely yours
>>> Mikhail Khludnev
>>> Principal Engineer,
>>> Grid Dynamics
>>>
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com/>
> <mk...@griddynamics.com>
>
>
>
--
Regards,
Varun Thacker
http://www.vthacker.in/
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <mk...@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 <ja...@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 <mk...@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 <ja...@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
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
>
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Mikhail Khludnev <mk...@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 <ja...@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 <mk...@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 <ja...@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<de...@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>> Principal Engineer,
>> Grid Dynamics
>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.**org<de...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mk...@griddynamics.com>
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Jack Krupansky <ja...@basetechnology.com>.
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 <mk...@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 <ja...@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
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Mark Miller <ma...@gmail.com>.
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 <mk...@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 <ja...@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
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [Discussion] Discontinue the ROLLBACK command in Solr?
Posted by Mikhail Khludnev <mk...@griddynamics.com>.
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 <ja...@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
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mk...@griddynamics.com>