It's not the browser cache. I have tried reloading the admin page and accessing the admin page from another machine. Both show the older index version and generation. On the slave, replication did kicked in and show the new index version and generation for the slave. But the slave admin page also shows the older index version and generation for the master.
If I do a second delete by query on the master, the master index generation reported the admin UI does go up by one on both the master and slave. But it is still one generation behind. Bill On Fri, Oct 19, 2012 at 7:09 AM, Erick Erickson <erickerick...@gmail.com>wrote: > I wonder if you're getting hit by the browser caching the admin page and > serving up the old version? What happens if you try from a different > browser or purge the browser cache? > > Of course you have to refresh the master admin page, there's no > automatic update but I assume you did that. > > Best > Erick > > On Thu, Oct 18, 2012 at 1:59 PM, Bill Au <bill.w...@gmail.com> wrote: > > Just discovered that the replication admin REST API reports the correct > > index version and generation: > > > > http://master_host:port/solr/replication?command=indexversion > > > > So is this a bug in the admin UI? > > > > Bill > > > > On Thu, Oct 18, 2012 at 11:34 AM, Bill Au <bill.w...@gmail.com> wrote: > > > >> I just upgraded to Solr 4.0.0. I noticed that after a delete by query, > >> the index version, generation, and size remain unchanged on the master > even > >> though the documents have been deleted (num docs changed and those > deleted > >> documents no longer show up in query responses). But on the slave both > the > >> index version, generation, and size are updated. So I though the master > >> and slave were out of sync but in reality that is not true. > >> > >> What's going on here? > >> > >> Bill > >> >
