[
https://issues.apache.org/jira/browse/SOLR-4380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregg Donovan updated SOLR-4380:
--------------------------------
Description:
In the process of upgrading to 4.1 from 3.6, I've noticed that our master
servers do not show any commit points -- e.g. via
http://127.0.0.1:8983/solr/collection1/replication?command=commits -- available
until after a new commit happens. So, for static indexes, replication doesn't
happen and for dynamic indexes, we have to wait until an incremental update of
master for slaves to see any commits.
Tracing through the code, it looks like the change that may have effected us
was part of [SOLR-3911|https://issues.apache.org/jira/browse/SOLR-3911],
specifically commenting out the initialization of the newIndexWriter in the
replicateAfterStartup block [1]:
{code:java}
// TODO: perhaps this is no longer necessary then?
// core.getUpdateHandler().newIndexWriter(true);
{code}
I'm guessing this is commented out because it is assumed that indexCommitPoint
was going to be set by that block, but when a slave requests commits, that goes
back to core.getDeletionPolicy().getCommits() to fetch the list of commits. If
no indexWriter has been initialized, then, as far as I can tell,
IndexDeletionPolicyWrapper#onInit will not have been called and there will be
no commits available.
By uncommenting this line, I was able to see commits on startup and slaves
began to replicate successfully.
[1]
http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java?annotate=1420992&diff_format=h&pathrev=1420992#l880
was:
In the process of upgrading to 4.1 from 3.6, I've noticed that our
master servers do not show any commit points -- e.g. via
http://127.0.0.1:8983/solr/collection1/replication?command=commits -- available
until after a
new commit happens. So, for static indexes, replication doesn't happen
and for dynamic indexes, we have to wait until an incremental update
of master for slaves to see any commits.
Tracing through the code, it looks like the change that may have
effected us was part of
[SOLR-3911|https://issues.apache.org/jira/browse/SOLR-3911], specifically
commenting out the
initialization of the newIndexWriter in the [replicateAfterStartup
block [1]:
{code:java}
// TODO: perhaps this is no longer necessary then?
// core.getUpdateHandler().newIndexWriter(true);
{code}
I'm guessing this is commented out because it is assumed that
indexCommitPoint was going to be set by that block, but when a slave
requests commits, that goes back to
core.getDeletionPolicy().getCommits() to fetch the list of commits. If
no indexWriter has been initialized, then, as far as I can tell,
IndexDeletionPolicyWrapper#onInit will not have been called and there
will be no commits available.
By uncommenting this line, I was able to see commits on startup and slaves
began to replicate successfully.
[1]
http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java?annotate=1420992&diff_format=h&pathrev=1420992#l880
> ReplicationHandler replicateAfter startup not showing commits after SOLR-3911
> -----------------------------------------------------------------------------
>
> Key: SOLR-4380
> URL: https://issues.apache.org/jira/browse/SOLR-4380
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 4.0, 4.1
> Reporter: Gregg Donovan
>
> In the process of upgrading to 4.1 from 3.6, I've noticed that our master
> servers do not show any commit points -- e.g. via
> http://127.0.0.1:8983/solr/collection1/replication?command=commits --
> available until after a new commit happens. So, for static indexes,
> replication doesn't happen and for dynamic indexes, we have to wait until an
> incremental update of master for slaves to see any commits.
> Tracing through the code, it looks like the change that may have effected us
> was part of [SOLR-3911|https://issues.apache.org/jira/browse/SOLR-3911],
> specifically commenting out the initialization of the newIndexWriter in the
> replicateAfterStartup block [1]:
> {code:java}
> // TODO: perhaps this is no longer necessary then?
> // core.getUpdateHandler().newIndexWriter(true);
> {code}
> I'm guessing this is commented out because it is assumed that
> indexCommitPoint was going to be set by that block, but when a slave requests
> commits, that goes back to core.getDeletionPolicy().getCommits() to fetch the
> list of commits. If no indexWriter has been initialized, then, as far as I
> can tell, IndexDeletionPolicyWrapper#onInit will not have been called and
> there will be no commits available.
> By uncommenting this line, I was able to see commits on startup and slaves
> began to replicate successfully.
> [1]
> http://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java?annotate=1420992&diff_format=h&pathrev=1420992#l880
--
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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
