[jira] Commented: (FELIX-1310) BundleCache may fail to initialize

["Richard S. Hall (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728877#action_12728877 ] 

Richard S. Hall commented on FELIX-1310:
----------------------------------------

I remember seeing an issue like this once before, but I cannot seem to find the exact details. I thought we fixed something like this.

At any rate, if it is a "control-c" during an update, that could definitely screw us up. In that case, we would have to make our cache reading a little more robust in the face of corruption.

> BundleCache may fail to initialize
> ----------------------------------
>
>                 Key: FELIX-1310
>                 URL: https://issues.apache.org/jira/browse/FELIX-1310
>             Project: Felix
>          Issue Type: Bug
>          Components: Framework
>    Affects Versions: felix-1.6.0
>            Reporter: Felix Meschberger
>
> Under certain circumstances not yet exactly known to me a strange error may be logged when the framework starts:
> 08.07.2009 16:16:32 *ERROR* webapp-CRX Launchpad Webapp: ERROR: org.apache.felix.framework.cache.BundleCache:
>         Error creating archive. (java.io.FileNotFoundException: ....\felix\bundle85\version298.-1\revision.location
>         (The system cannot find the path specified))
> I trace this to BundleArchive(Logger logger, Map configMap, File archiveRootDir) constructor which does:
>         int revisionCount = 0;
>         while (true)
>         {
>             File revisionRootDir = new File(m_archiveRootDir,
>                 REVISION_DIRECTORY + getRefreshCount() + "." + revisionCount);
>             if (!BundleCache.getSecureAction().fileExists(revisionRootDir))
>             {
>                 break;
>             }
>             revisionCount++;
>         }
>         if (revisionCount > 1)
>         {
>             m_revisions = new BundleRevision[revisionCount - 1];
>         }
>         revise(getRevisionLocation(revisionCount - 1), null);
> and given that there is no folder ....\felix\bundle85\version298.0 the loop will immediately terminate with revisionCount=0 and hence call getRevisionLocation with a revision number of "-1".
> I assume the revisionCount=0 state should be guarded here .. But I do not exactly know what the correct solution would be.
> My assumption would be that the user tried to update Bundle 85 from 297 to 298 but the update was interrupted by a system termination, since the version297.0 still exists but the refresh count file has already been updated to 298 (so it looks).
> I am currently asking the user for more information and will ammend this issue as soon as I have it.
> We have observed the problem on an 1.6.0 framework instance. The BundleCache initialization code, though, is still the same in trunk.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.