[jira] [Resolved] (SOLR-17805) Transaction log constructor can fail and leave a file that blocks the update log.

["Bruno Roustant (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-17805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Roustant resolved SOLR-17805.
-----------------------------------
    Fix Version/s: 9.9
       Resolution: Fixed

> Transaction log constructor can fail and leave a file that blocks the update log.
> ---------------------------------------------------------------------------------
>
>                 Key: SOLR-17805
>                 URL: https://issues.apache.org/jira/browse/SOLR-17805
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 9.8.1
>            Reporter: Bruno Roustant
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 9.9
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> TransactionLog constructor can either open an existing log, or create a new log. When it is required to create a new log, it first creates a new empty log file and then opens an output stream on it.
> After the new empty log file is created, if an exception occurs when creating the output stream (e.g. disk full, encryption key not available), the TransactionLog object is not created, but the empty file is left. The problem is that UpdateLog does not update its "id" field which should point to the next (non-existing) transaction log id, instead it continues to point to the empty log file. This completely blocks the logic in UpdateLog.ensureLog() and TransactionLog constructor will always refuse to create a new transaction log, throwing "New transaction log already exists" for each update, effectively blocking all subsequent updates, until the Solr server is restarted.
> The proposed fix is to
> 1- Delete the created empty log file is an exception is thrown inside the TransactionLog constructor.
> 2- Fix the error code inconsistency between DirectUpdateHandler2.addDoc() (which currently sets a 4xx code) and RequestHandlerBase.normalizeReceivedException() (which currently asserts a 5xx code).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org