You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/07/08 21:47:14 UTC

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

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

Felix Meschberger updated FELIX-1310:
-------------------------------------

          Description: 
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.

  was:
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.

    Affects Version/s:     (was: felix-1.8.1)
                           (was: felix-2.0.0)
                           (was: felix-1.6.1)
                           (was: felix-1.8.0)

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