lucene-dev mailing list archives

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


Mark Miller commented on SOLR-9859:

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

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 which is not so straightforward
to do this way.

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

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

> does not get updated the second time around if index recovers
via replication
> ----------------------------------------------------------------------------------------------------
>                 Key: SOLR-9859
>                 URL:
>             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 {{}}
gets created. If the same shard recovers once more via replication, IndexFetcher fails to
write latest replication information as it tries to create {{}} 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\
> 	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$FSIndexOutput.<init>(
> 	at$FSIndexOutput.<init>(
> 	at
> 	at org.apache.solr.handler.IndexFetcher.logReplicationTimeAndConfFiles(
> 	at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(
> 	at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(
> 	at org.apache.solr.handler.ReplicationHandler.doFetch(
> 	at
> 	at
> 	at
> 	at java.util.concurrent.Executors$ Source)
> 	at Source)
> 	at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$0(
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$ Source)
> 	at Source)
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message