lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
Date Wed, 17 Apr 2013 20:17:18 GMT


Hoss Man commented on SOLR-4661:

Joel: please note my earlier comments...

bq. I did some more experimenting and confirmed i was wrong about this – from Solr's perspective
a new searcher is definitely getting opened and warmed. can clearly see in the logs that an "empty" commit causes a new Searcher to be opened
in any situation -- but when it happens on the master the underlying call to "DirectoryReader.openIfChanged"
recognizes that the commit point in the directory is identical.  On the slave side it may
not recognize this because the physical directory itself can change (ie: index vs index.XXXXXXXX)

Even if there is a bug here (or room for optimization on the slave side) we should track it
separately since the crux of thies issue (the UI is comparing apples and oranges) would still
be true -- notably in the case where someone may do an openSearcher=false commit on the master,
creating a new replicable version for slaves w/o opening a new searcher on the master.

> Index Version & Gen look out of sync in replication UI when master searcher uses
older commit then what is replicatable
> -----------------------------------------------------------------------------------------------------------------------
>                 Key: SOLR-4661
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: replication (java), web gui
>    Affects Versions: 4.2
>         Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>            Reporter: Aditya
>              Labels: gui, replication, web
>         Attachments:, IndexVersionSyncIssue.jpg, SOLR-4661.patch, SOLR-4661.patch,
> the ReplicationHandler (and the replication admin UI screen) report the index version
& gen for the master based on what commit point is currently open for searching -- but
this is not necessarily the most recent commit point available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there are "empty
commits" (because of reader reopening shotcuts) or commits using openSearcher=false.
> We need to add additional data to help make it clear there is no actual problem in this
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master. 
> If you apply commit on master with no pending docs then the commit time stamp and gen
is incremented. When Slaves polls master for replication it see the index version difference
and starts replicating but all files are skipped. 
> On Admin UI (on Slaves) the version number displayed for master is old where as for slave
is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see two different
Version an Gen numbers. This creates confusion of having version out of sync, though its not.

> ...
> {panel}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message