Sorry, I had copy/paste the wrong link before. Here is the correct one: https://issues.apache.org/jira/browse/SOLR-3986
Bill On Wed, Oct 24, 2012 at 10:26 AM, Bill Au <bill.w...@gmail.com> wrote: > I just filed a bug with all the details: > > https://issues.apache.org/jira/browse/SOLR-3681 > > Bill > > > On Tue, Oct 23, 2012 at 2:47 PM, Chris Hostetter <hossman_luc...@fucit.org > > 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? >> >> Ya gotta be specific Bill: where in the admin UI do you think it's >> displaying the incorrect information? >> >> The Admin UI just adds pretty markup to information fetched from the >> admin handlers using javascript, so if there is a problem it's either in >> the admin handlers, or in the javascript possibly caching the olds values. >> >> Off the cuff, this reminds me of... >> >> https://issues.apache.org/jira/browse/SOLR-3681 >> >> The root confusion there was that /admin/replication explicitly shows data >> about the commit point available for replication -- not the current commit >> point being "searched" on the master. >> >> So if you are seeing a disconnect, then perhaps it's just that same >> descrepency? -- allthough if you are *only* seeing a disconnect after a >> deleteByQuery (and not after document adds, or a deleteById) then that >> does smell fishy, and makes me wonder if there is a code path where the >> "userData" for the commits aren't being set properly. >> >> Can you file a bug with a unit test to reproduce? or at the very list a >> set of specific commands to run against the solr example including what >> request handler URLs to hit (so there's no risk of confusion about the ui >> javascript behavior) to see the problem? >> >> >> -Hoss >> > >
