[
https://issues.apache.org/jira/browse/SOLR-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065390#comment-13065390
]
Jeremy Custenborder edited comment on SOLR-2326 at 7/14/11 5:15 PM:
--------------------------------------------------------------------
I'm running into the same issue. My slave server has no update handlers.
Calling /solr/core/replication?command=indexversion on the master always
returned 0. I was looking at the code for the handler and found an interesting
comment on line 125. It's currently configured to replicate after commit.
{quote}
This happens when replication is not configured to happen after startup and no
commit/optimize
has happened yet.
{quote}
This got me thinking so I issued the following command against the master
{quote}
curl 'http://127.0.0.1:8080/solr/core/update' -H "Content-Type: text/xml"
--data-binary '<optimize/>'
{quote}
The next call to /solr/core/replication?command=indexversion returned a valid
version and replication to the slave started.
This makes me believe the problem is in this code block.
{code}
if (command.equals(CMD_INDEX_VERSION)) {
IndexCommit commitPoint = indexCommitPoint; // make a copy so it won't
change
if (commitPoint != null && replicationEnabled.get()) {
//
// There is a race condition here. The commit point may be changed /
deleted by the time
// we get around to reserving it. This is a very small window though,
and should not result
// in a catastrophic failure, but will result in the client getting an
empty file list for
// the CMD_GET_FILE_LIST command.
//
core.getDeletionPolicy().setReserveDuration(commitPoint.getVersion(),
reserveCommitDuration);
rsp.add(CMD_INDEX_VERSION, commitPoint.getVersion());
rsp.add(GENERATION, commitPoint.getGeneration());
} else {
// This happens when replication is not configured to happen after
startup and no commit/optimize
// has happened yet.
rsp.add(CMD_INDEX_VERSION, 0L);
rsp.add(GENERATION, 0L);
}
}
{code}
It looks like there is a race condition resulting in indexCommitPoint being
null. Look at the method postCommit() in getEventListener() method.
{code}
public void postCommit() {
IndexCommit currentCommitPoint =
core.getDeletionPolicy().getLatestCommit();
if (getCommit) {
// IndexCommit oldCommitPoint = indexCommitPoint;
indexCommitPoint = currentCommitPoint;
// We don't need to save commit points for replication, the
SolrDeletionPolicy
// always saves the last commit point (and the last optimized commit
point, if needed)
/***
if (indexCommitPoint != null) {
core.getDeletionPolicy().saveCommitPoint(indexCommitPoint.getVersion());
}
if(oldCommitPoint != null){
core.getDeletionPolicy().releaseCommitPoint(oldCommitPoint.getVersion());
}
***/
}
if (snapshoot) {
try {
SnapShooter snapShooter = new SnapShooter(core, null);
snapShooter.createSnapAsync(currentCommitPoint,
ReplicationHandler.this);
} catch (Exception e) {
LOG.error("Exception while snapshooting", e);
}
}
}
{code}
This is the first time I see indexCommitPoint being set. Since indexCommitPoint
is null until being loaded this causes a value of 0 to always be returned.
If you call optimize like I did does your index start replicating? In my
situation each core that returned 0/0 started replicating after I called
optimize.
was (Author: jcustenborder):
I'm running into the same issue. My slave server has no update handlers.
Calling /solr/core/replication?command=indexversion on the master always
returned 0. I was looking at the code for the handler and found an interesting
comment on line 125. It's currently configured to replicate after commit.
{quote}
This happens when replication is not configured to happen after startup and no
commit/optimize
has happened yet.
{quote}
This got me thinking so I issued the following command against the master
{quote}
curl 'http://127.0.0.1:8080/solr/core/update' -H "Content-Type: text/xml"
--data-binary '<optimize/>'
{quote}
The next call to /solr/core/replication?command=indexversion returned a valid
version and replication to the slave started.
This makes me believe the problem is in this code block.
{code}
if (command.equals(CMD_INDEX_VERSION)) {
IndexCommit commitPoint = indexCommitPoint; // make a copy so it won't
change
if (commitPoint != null && replicationEnabled.get()) {
//
// There is a race condition here. The commit point may be changed /
deleted by the time
// we get around to reserving it. This is a very small window though,
and should not result
// in a catastrophic failure, but will result in the client getting an
empty file list for
// the CMD_GET_FILE_LIST command.
//
core.getDeletionPolicy().setReserveDuration(commitPoint.getVersion(),
reserveCommitDuration);
rsp.add(CMD_INDEX_VERSION, commitPoint.getVersion());
rsp.add(GENERATION, commitPoint.getGeneration());
} else {
// This happens when replication is not configured to happen after
startup and no commit/optimize
// has happened yet.
rsp.add(CMD_INDEX_VERSION, 0L);
rsp.add(GENERATION, 0L);
}
}
{code}
It looks like there is a race condition resulting in indexCommitPoint being
null. Look at the method postCommit() in getEventListener() method.
{code}
public void postCommit() {
IndexCommit currentCommitPoint =
core.getDeletionPolicy().getLatestCommit();
if (getCommit) {
// IndexCommit oldCommitPoint = indexCommitPoint;
indexCommitPoint = currentCommitPoint;
// We don't need to save commit points for replication, the
SolrDeletionPolicy
// always saves the last commit point (and the last optimized commit
point, if needed)
/***
if (indexCommitPoint != null) {
core.getDeletionPolicy().saveCommitPoint(indexCommitPoint.getVersion());
}
if(oldCommitPoint != null){
core.getDeletionPolicy().releaseCommitPoint(oldCommitPoint.getVersion());
}
***/
}
if (snapshoot) {
try {
SnapShooter snapShooter = new SnapShooter(core, null);
snapShooter.createSnapAsync(currentCommitPoint,
ReplicationHandler.this);
} catch (Exception e) {
LOG.error("Exception while snapshooting", e);
}
}
}
{code}
Since indexCommitPoint is null until being loaded this causes a value of 0 to
always be returned.
If you call optimize like I did does your index start replicating? In my
situation each core that returned 0/0 started replicating after I called
optimize.
> Replication command indexversion fails to return index version
> --------------------------------------------------------------
>
> Key: SOLR-2326
> URL: https://issues.apache.org/jira/browse/SOLR-2326
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Environment: Branch 3x latest
> Reporter: Eric Pugh
> Assignee: Mark Miller
> Fix For: 3.4, 4.0
>
>
> To test this, I took the /example/multicore/core0 solrconfig and added a
> simple replication handler:
> <requestHandler name="/replication" class="solr.ReplicationHandler" >
> <lst name="master">
> <str name="replicateAfter">commit</str>
> <str name="replicateAfter">startup</str>
> <str name="confFiles">schema.xml</str>
> </lst>
> </requestHandler>
> When I query the handler for details I get back the indexVersion that I
> expect:
> http://localhost:8983/solr/core0/replication?command=details&wt=json&indent=true
> But when I ask for just the indexVersion I get back a 0, which prevent the
> slaves from pulling updates:
> http://localhost:8983/solr/core0/replication?command=indexversion&wt=json&indent=true
--
This message is automatically generated by JIRA.
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]
