You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jérôme Etévé <je...@gmail.com> on 2009/10/16 18:58:15 UTC
Replication filelist command failure on container restart
Hi All,
I'm facing a small problem with the replication handler:
After restarting my master container (tomcat),
/admin/replication/index.jsp shows me the right information,
basically the same indexversion as before the restart (no
commits/optimize have been done after restart):
Local Index Index Version: 1255709893043, Generation: 8
However, if I query the handler with the filelist command and this
version number :
/replication?command=filelist&indexversion=1255709893043 , the handler
gives me an error:
<str name="status">invalid indexversion</str>
So I think my slaves will get confused if this information doesn't
remain consistent after a master container restart.
Is there a way to go around this problem, for instance by triggering a
commit on startup (or reload) ?
Thanks!
Jerome.
--
Jerome Eteve.
http://www.eteve.net
jerome@eteve.net
Fwd: Replication filelist command failure on container restart
Posted by Jérôme Etévé <je...@gmail.com>.
---------- Forwarded message ----------
From: Jérôme Etévé <je...@gmail.com>
Date: 2009/10/16
Subject: Re: Replication filelist command failure on container restart
To: yonik@lucidimagination.com
Thanks Yonik,
It works now!
J.
2009/10/16 Yonik Seeley <yo...@lucidimagination.com>:
> I think you may need to tell the replication handler to enable
> replication after startup too?
>
> <str name="replicateAfter">commit</str>
> <str name="replicateAfter">startup</str>
>
> -Yonik
> http://www.lucidimagination.com
>
>
> On Fri, Oct 16, 2009 at 12:58 PM, Jérôme Etévé <je...@gmail.com> wrote:
>> Hi All,
>> I'm facing a small problem with the replication handler:
>>
>> After restarting my master container (tomcat),
>> /admin/replication/index.jsp shows me the right information,
>> basically the same indexversion as before the restart (no
>> commits/optimize have been done after restart):
>>
>> Local Index Index Version: 1255709893043, Generation: 8
>>
>> However, if I query the handler with the filelist command and this
>> version number :
>> /replication?command=filelist&indexversion=1255709893043 , the handler
>> gives me an error:
>>
>> <str name="status">invalid indexversion</str>
>>
>> So I think my slaves will get confused if this information doesn't
>> remain consistent after a master container restart.
>>
>> Is there a way to go around this problem, for instance by triggering a
>> commit on startup (or reload) ?
>>
>>
>> Thanks!
>>
>> Jerome.
>>
>> --
>> Jerome Eteve.
>> http://www.eteve.net
>> jerome@eteve.net
>>
>
--
Jerome Eteve.
http://www.eteve.net
jerome@eteve.net
--
Jerome Eteve.
http://www.eteve.net
jerome@eteve.net
Re: Replication filelist command failure on container restart
Posted by Yonik Seeley <yo...@lucidimagination.com>.
I think you may need to tell the replication handler to enable
replication after startup too?
<str name="replicateAfter">commit</str>
<str name="replicateAfter">startup</str>
-Yonik
http://www.lucidimagination.com
On Fri, Oct 16, 2009 at 12:58 PM, Jérôme Etévé <je...@gmail.com> wrote:
> Hi All,
> I'm facing a small problem with the replication handler:
>
> After restarting my master container (tomcat),
> /admin/replication/index.jsp shows me the right information,
> basically the same indexversion as before the restart (no
> commits/optimize have been done after restart):
>
> Local Index Index Version: 1255709893043, Generation: 8
>
> However, if I query the handler with the filelist command and this
> version number :
> /replication?command=filelist&indexversion=1255709893043 , the handler
> gives me an error:
>
> <str name="status">invalid indexversion</str>
>
> So I think my slaves will get confused if this information doesn't
> remain consistent after a master container restart.
>
> Is there a way to go around this problem, for instance by triggering a
> commit on startup (or reload) ?
>
>
> Thanks!
>
> Jerome.
>
> --
> Jerome Eteve.
> http://www.eteve.net
> jerome@eteve.net
>