Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
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.orgwrote: : 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
Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
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
Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
: 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
Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
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
Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
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.comwrote: 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
Solr 4.0.0 - index version and generation not changed after delete by query on master
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
Re: Solr 4.0.0 - index version and generation not changed after delete by query on master
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
