lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-9859) replication.properties does not get updated the second time around if index recovers via replication
Date Thu, 15 Dec 2016 16:44:58 GMT

    [ https://issues.apache.org/jira/browse/SOLR-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751827#comment-15751827
] 

Mark Miller commented on SOLR-9859:
-----------------------------------

bq. Is there a way we can write a temp file and do a mv to rename/overwrite replication.properties

Nothing great. Java 7 gives us an atomic move that can overwrite an existing file, but it's
impl dependent on if that is supported and it wouldn't work for the arbitrary FileSystem's
we support. We would still need some start up logic that could address a crashed state.

bq. Alternate solution would be to keep appending to existing file and read the latest stats
from the file.

The problem is we use this same strategy for index.properties which is not so straightforward
to do this way.

bq.  I think we can simply delete the exist replication.properties before write a new one.

That is the easy fix I mention above, but it's fragile, and like index.properties, not robust
in a crash.

> replication.properties does not get updated the second time around if index recovers
via replication
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-9859
>                 URL: https://issues.apache.org/jira/browse/SOLR-9859
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: 5.5.3, 6.3
>            Reporter: Pushkar Raste
>            Assignee: Mark Miller
>            Priority: Minor
>         Attachments: SOLR-9859.patch
>
>
> If a shard recovers via replication (vs PeerSync) a file named {{replication.properties}}
gets created. If the same shard recovers once more via replication, IndexFetcher fails to
write latest replication information as it tries to create {{replication.properties}} but
as file already exists. Here is the stack trace I saw 
> {code}
> java.nio.file.FileAlreadyExistsException: <solr_home>\shard-3-001\cores\collection1\data\replication.properties
> 	at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
> 	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
> 	at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
> 	at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
> 	at java.nio.file.spi.FileSystemProvider.newOutputStream(Unknown Source)
> 	at java.nio.file.Files.newOutputStream(Unknown Source)
> 	at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:413)
> 	at org.apache.lucene.store.FSDirectory$FSIndexOutput.<init>(FSDirectory.java:409)
> 	at org.apache.lucene.store.FSDirectory.createOutput(FSDirectory.java:253)
> 	at org.apache.solr.handler.IndexFetcher.logReplicationTimeAndConfFiles(IndexFetcher.java:689)
> 	at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:501)
> 	at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:265)
> 	at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:397)
> 	at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:157)
> 	at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:409)
> 	at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:222)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> 	at java.util.concurrent.FutureTask.run(Unknown Source)
> 	at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$0(ExecutorUtil.java:229)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message