felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-1310) BundleCache may fail to initialize
Date Wed, 08 Jul 2009 20:13:14 GMT

    [ 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
> 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.

View raw message