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:41:14 UTC
[jira] Created: (FELIX-1310) BundleCache may fail to initialize
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.8.1, felix-1.8.0, felix-1.6.1, felix-1.6.0, felix-2.0.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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-1310) BundleCache may fail to initialize
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved FELIX-1310.
--------------------------------------
Resolution: Cannot Reproduce
No, I never saw it again. So I agree to resolve this as proposed.
> 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: framework-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.
[jira] Commented: (FELIX-1310) BundleCache may fail to initialize
Posted by "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=12900758#action_12900758 ]
Richard S. Hall commented on FELIX-1310:
----------------------------------------
Are you still seeing this issue? I'm wondering whether it may have been related to FELIX-2222, which resulted in a similar -1 revision count. Should we close this as "cannot reproduce" ?
> 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: framework-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.
[jira] Updated: (FELIX-1310) BundleCache may fail to initialize
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-1310) BundleCache may fail to initialize
Posted by "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.