[jira] [Commented] (SLING-3737) Instance Sling Identifier may be randomly reset on restart

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on SLING-3737:
---------------------------------------

Github user tmaret closed the pull request at:

    https://github.com/apache/sling/pull/22


> Instance Sling Identifier may be randomly reset on restart
> ----------------------------------------------------------
>
>                 Key: SLING-3737
>                 URL: https://issues.apache.org/jira/browse/SLING-3737
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Settings 1.3.0
>            Reporter: Timothee Maret
>            Assignee: Carsten Ziegeler
>             Fix For: Settings 1.3.2
>
>         Attachments: SLING-3737.diff, SLING-3737.diff, SLING-3737.diff
>
>
> In our Setup, we experience instances changing their Sling identifier upon restart.
> We have experienced only a few occurrences of this issue, but the effect is really bad, turning the services relying on the Sling Identifier into unexpected state (for instance Sling discovery service).
> We have checked that the sling.id.file was present before the issue occurred.
> We also checked that the value in this file was valid (36 byte long UUID).
> Despite having a valid sling.id.file file, the instance sometimes reset the Sling ID upon restart.
> Looking at the latest code in org.apache.sling.settings.impl.SlingSettingsServiceImpl#readSlingId
> it seems there is a bug in the way the sling id is read from the file sling.id.file.
> {code}
> private String readSlingId(final File idFile) {
>         if (idFile.exists() && idFile.length() >= 36) {
>             FileInputStream fin = null;
>             try {
>                 fin = new FileInputStream(idFile);
>                 final byte[] rawBytes = new byte[36];
>                 if (fin.read(rawBytes) == 36) {
>                     final String rawString = new String(rawBytes, "ISO-8859-1");
>                     // roundtrip to ensure correct format of UUID value
>                     final String id = UUID.fromString(rawString).toString();
>                     logger.debug("Got Sling ID {} from file {}", id, idFile);
>                     return id;
>                 }
>             } catch (final Throwable t) {
>                 logger.error("Failed reading UUID from id file " + idFile
>                         + ", creating new id", t);
>             } finally {
>                 if (fin != null) {
>                     try {
>                         fin.close();
>                     } catch (IOException ignore) {
>                     }
>                 }
>             }
>         }
>         return null;
>     }
> {code}
> In the line
> {code}
> if (fin.read(rawBytes) == 36) {
> {code}
> The code miss uses the java.io.FileInputStream#read API.
> {code}
> /**
>      * Reads up to <code>b.length</code> bytes of data from this input
>      * stream into an array of bytes. This method blocks until some input
>      * is available.
>      *
>      * @param      b   the buffer into which the data is read.
>      * @return     the total number of bytes read into the buffer, or
>      *             <code>-1</code> if there is no more data because the end of
>      *             the file has been reached.
>      * @exception  IOException  if an I/O error occurs.
>      */
> {code}
> The API stipulates that the method blocks until if finds *some* data.
> This is a common pattern with Java IO APIs, and indeed, the method may return with only one byte read even though the end of the stream was not reached.
> If this is the case, the current logic will treat the slingId as invalid and generate a new one.
> A way to fix that is to read the sling id file completely, for instance using the org.apache.commons.io.FileUtils API
> We are running on CentOS 6.2, JDK 1.7.



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