Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » [buckminster-dev] No element with id ... was found in storage resolution
[buckminster-dev] No element with id ... was found in storage resolution [message #32421] Tue, 31 March 2009 19:09 Go to next message
Nick Veys is currently offline Nick VeysFriend
Messages: 52
Registered: July 2009
Member
Been running into this issue randomly during the course of our
Buckminster integration and now after attempting to upgrade our target
platform from 3.4.1 -> 3.4.2 it is much more frequent in occurrence.

The simple result is this exception during the build of one of our products:

[java] org.eclipse.buckminster.core.metadata.model.ElementNotFoundE xception:
No element with id 3999b585-5686-32c8-838b-1959be6a3254 was found in
storage resolution
[java] at org.eclipse.buckminster.core.metadata.FileStorage.getElement (FileStorage.java:299)
[java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getActiv eResolutions(WorkspaceInfo.java:230)
[java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getResol ution(WorkspaceInfo.java:622)
[java] at org.eclipse.buckminster.pde.internal.actor.FragmentsActor.is UpToDate(FragmentsActor.java:111)
[java] at org.eclipse.buckminster.core.cspec.model.Action.isUpToDate(A ction.java:274)
[java] at org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:354)
[java] at org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:405)
[java] at org.eclipse.buckminster.core.commands.Perform.internalRun(Pe rform.java:198)
[java] at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(W orkspaceCommand.java:99)
[java] at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(Abs tractCommand.java:155)
[java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 95)
[java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 29)
[java] at org.eclipse.buckminster.cmdline.Headless.start(Headless.java :304)
[java] at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
[java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
[java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
[java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:386)
[java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
[java] at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
[java] at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
[java] at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
[java] No element with id 3999b585-5686-32c8-838b-1959be6a3254 was
found in storage resolution

Take the line #'s loosely as I've been instrumenting debug...

This will happen with completely new workspaces or ones that worked
just previously. I found some references to this issue in the group
but they seemed to conclude the issue was workspace metadata
corruption or cruft. This doesn't seem to be the case.

In the course of debugging I've found that the resolution filestorage
has a few elements removed from it right before failure. The element
requested is removed just before being checked with getCreationTime,
causing the exception.

Some debug output I instrumented:

.... [SNIP, other start/end pairs] ...
[java] INFO: [start my.pkg.jdepend:osgi.bundle$2.9.1#OSGi#bundle.jar]
[java] WARN: resolution removed 9b7e17a4-60e5-3b80-bfb8-ede4d0ba9d48,
total: 309
[java] INFO: [end my.pkg.jdepend:osgi.bundle$2.9.1#OSGi#bundle.jar]
[java] WARN: resolution removed 3999b585-5686-32c8-838b-1959be6a3254,
total: 308
[java] WARN: resolution removed e6c4099a-60f3-325b-ab08-18edc887a028,
total: 307
[java] org.eclipse.buckminster.core.metadata.model.ElementNotFoundE xception:
No element with id 3999b585-5686-32c8-838b-1959be6a3254 was found in
storage resolution
[java] at org.eclipse.buckminster.core.metadata.FileStorage.getElement (FileStorage.java:299)
[java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getActiv eResolutions(WorkspaceInfo.java:230)
.... [SNIP ... exception trace] ...

So you can see 3999... was just removed, then fetched. Stranger (to
me at least) is that the element that is causing the problem is
repeatable, and it's a completely unrelated feature, not used in the
product currently being built. So it feels a lot like a race
condition of some kind, even more so because enabling remote debug, or
adding too much log output makes it go away or very difficult to make
happen.

However, when it *doesn't* break, it either never calls
FileStore.removeElement() on resolution, or calls it after that
element is needed.

Any ideas? Unfortunately I haven't been able to create a small
workspace to reproduce. Whatever I have here as my big old project
workspace seems to create the right conditions. I'm going to continue
debugging but any guidance would be greatly appreciated.
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32458 is a reply to message #32421] Tue, 31 March 2009 19:27 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Nick,
It would be a great help if you could add a piece of code that would
print out a stack-trace just when the culprit element is removed. If
possible, try using a write buffer and write to a file and not the
console since that's generally much slower.

- thomas

Nick Veys wrote:
> Been running into this issue randomly during the course of our
> Buckminster integration and now after attempting to upgrade our target
> platform from 3.4.1 -> 3.4.2 it is much more frequent in occurrence.
>
> The simple result is this exception during the build of one of our products:
>
> [java] org.eclipse.buckminster.core.metadata.model.ElementNotFoundE xception:
> No element with id 3999b585-5686-32c8-838b-1959be6a3254 was found in
> storage resolution
> [java] at org.eclipse.buckminster.core.metadata.FileStorage.getElement (FileStorage.java:299)
> [java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getActiv eResolutions(WorkspaceInfo.java:230)
> [java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getResol ution(WorkspaceInfo.java:622)
> [java] at org.eclipse.buckminster.pde.internal.actor.FragmentsActor.is UpToDate(FragmentsActor.java:111)
> [java] at org.eclipse.buckminster.core.cspec.model.Action.isUpToDate(A ction.java:274)
> [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:354)
> [java] at org.eclipse.buckminster.core.internal.actor.PerformManager.p erform(PerformManager.java:405)
> [java] at org.eclipse.buckminster.core.commands.Perform.internalRun(Pe rform.java:198)
> [java] at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(W orkspaceCommand.java:99)
> [java] at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(Abs tractCommand.java:155)
> [java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 95)
> [java] at org.eclipse.buckminster.cmdline.Headless.run(Headless.java:2 29)
> [java] at org.eclipse.buckminster.cmdline.Headless.start(Headless.java :304)
> [java] at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
> [java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
> [java] at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
> [java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:386)
> [java] at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
> [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
> [java] at java.lang.reflect.Method.invoke(Method.java:597)
> [java] at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 549)
> [java] at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> [java] at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
> [java] at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
> [java] No element with id 3999b585-5686-32c8-838b-1959be6a3254 was
> found in storage resolution
>
> Take the line #'s loosely as I've been instrumenting debug...
>
> This will happen with completely new workspaces or ones that worked
> just previously. I found some references to this issue in the group
> but they seemed to conclude the issue was workspace metadata
> corruption or cruft. This doesn't seem to be the case.
>
> In the course of debugging I've found that the resolution filestorage
> has a few elements removed from it right before failure. The element
> requested is removed just before being checked with getCreationTime,
> causing the exception.
>
> Some debug output I instrumented:
>
> ... [SNIP, other start/end pairs] ...
> [java] INFO: [start my.pkg.jdepend:osgi.bundle$2.9.1#OSGi#bundle.jar]
> [java] WARN: resolution removed 9b7e17a4-60e5-3b80-bfb8-ede4d0ba9d48,
> total: 309
> [java] INFO: [end my.pkg.jdepend:osgi.bundle$2.9.1#OSGi#bundle.jar]
> [java] WARN: resolution removed 3999b585-5686-32c8-838b-1959be6a3254,
> total: 308
> [java] WARN: resolution removed e6c4099a-60f3-325b-ab08-18edc887a028,
> total: 307
> [java] org.eclipse.buckminster.core.metadata.model.ElementNotFoundE xception:
> No element with id 3999b585-5686-32c8-838b-1959be6a3254 was found in
> storage resolution
> [java] at org.eclipse.buckminster.core.metadata.FileStorage.getElement (FileStorage.java:299)
> [java] at org.eclipse.buckminster.core.metadata.WorkspaceInfo.getActiv eResolutions(WorkspaceInfo.java:230)
> ... [SNIP ... exception trace] ...
>
> So you can see 3999... was just removed, then fetched. Stranger (to
> me at least) is that the element that is causing the problem is
> repeatable, and it's a completely unrelated feature, not used in the
> product currently being built. So it feels a lot like a race
> condition of some kind, even more so because enabling remote debug, or
> adding too much log output makes it go away or very difficult to make
> happen.
>
> However, when it *doesn't* break, it either never calls
> FileStore.removeElement() on resolution, or calls it after that
> element is needed.
>
> Any ideas? Unfortunately I haven't been able to create a small
> workspace to reproduce. Whatever I have here as my big old project
> workspace seems to create the right conditions. I'm going to continue
> debugging but any guidance would be greatly appreciated.
Re: No element with id ... was found in storage resolution [message #32493 is a reply to message #32458] Tue, 31 March 2009 21:11 Go to previous messageGo to next message
Nick Veys is currently offline Nick VeysFriend
Messages: 52
Registered: July 2009
Member
I will do that. Further digging has shown me the MetadataRefreshJob seems
to kick off when the first eclipse.build action is run. It then
eventually (sometimes) removes the component at the inopportune time.
Should there be a scheduling rule to get the refresh job to finish before
continuing?

Thomas Hallgren wrote:

> Hi Nick,
> It would be a great help if you could add a piece of code that would
> print out a stack-trace just when the culprit element is removed. If
> possible, try using a write buffer and write to a file and not the
> console since that's generally much slower.
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32528 is a reply to message #32458] Tue, 31 March 2009 22:32 Go to previous messageGo to next message
Nick Veys is currently offline Nick VeysFriend
Messages: 52
Registered: July 2009
Member
I think I see it now.

[java] [ant] WARN: resolution removed
3999b585-5686-32c8-838b-1959be6a3254, total: 308
[java] [ant] WARN: *~*~*~* remove, component:
com.p21csi.aedge.appshell.feature
[java] [ant] java.lang.Throwable
[java] [ant] at
org.eclipse.buckminster.core.metadata.model.Resolution.remov e(Resolution.java:586)
[java] [ant] at
org.eclipse.buckminster.core.metadata.MetadataSynchronizer.r efreshProject(MetadataSynchronizer.java:352)
[java] [ant] at
org.eclipse.buckminster.core.metadata.MetadataSynchronizer$M etadataRefreshJob.run(MetadataSynchronizer.java:141)
[java] [ant] at
org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

In MetadataSynchronizer.refreshProject:

if(oldInfo != null)
{
try
{
oldInfo.remove(sm);
oldInfo.getCSpec().remove(sm);
}
catch(ReferentialIntegrityException e)
{
// Old resolution is being held by a BillOfMaterials. It
// cannot be removed at this point.
}
}

oldInfo.remove(sm); // succeeds unconditionally
oldInfo.getCSpec().remove(sm); // throws RefIntExc, but the damage is
already done, when it tries to use that component it's not there

Swapping the lines to be:

oldInfo.getCSpec().remove(sm);
oldInfo.remove(sm);

seems to guard the unchecked remove and I haven't seen any crashes since.
(not sure of the overall repercussions of this change so please tell me if
I'm crazy!)
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32563 is a reply to message #32528] Wed, 01 April 2009 04:48 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Nick,
Can you verify that this makes the problem go away? The reason the code is in the order it is is that the cspec remove
does this:

public void remove(StorageManager sm) throws CoreException
{
UUID thisId = getId();
if(!sm.getResolutions().getReferencingKeys(thisId, "cspecId").isEmpty()) //$NON-NLS-1$
throw new ReferentialIntegrityException(this, "remove", Messages.Referenced_from_Resolution); //$NON-NLS-1$

sm.getCSpecs().removeElement(thisId);
}

which means that if the resolution still exists, the cspec cannot be removed. The order asserts that a
ReferentialIntegrityException is never thrown. Reversing it will provoke that exception every time.

- thomas

Nick Veys wrote:
> I think I see it now.
>
> [java] [ant] WARN: resolution removed
> 3999b585-5686-32c8-838b-1959be6a3254, total: 308
> [java] [ant] WARN: *~*~*~* remove, component:
> com.p21csi.aedge.appshell.feature
> [java] [ant] java.lang.Throwable
> [java] [ant] at
> org.eclipse.buckminster.core.metadata.model.Resolution.remov e(Resolution.java:586)
>
> [java] [ant] at
> org.eclipse.buckminster.core.metadata.MetadataSynchronizer.r efreshProject(MetadataSynchronizer.java:352)
>
> [java] [ant] at
> org.eclipse.buckminster.core.metadata.MetadataSynchronizer$M etadataRefreshJob.run(MetadataSynchronizer.java:141)
>
> [java] [ant] at
> org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>
> In MetadataSynchronizer.refreshProject:
>
> if(oldInfo != null)
> {
> try
> {
> oldInfo.remove(sm);
> oldInfo.getCSpec().remove(sm);
> }
> catch(ReferentialIntegrityException e)
> {
> // Old resolution is being held by a BillOfMaterials. It
> // cannot be removed at this point.
> }
> }
>
> oldInfo.remove(sm); // succeeds unconditionally
> oldInfo.getCSpec().remove(sm); // throws RefIntExc, but the damage is
> already done, when it tries to use that component it's not there
>
> Swapping the lines to be:
>
> oldInfo.getCSpec().remove(sm);
> oldInfo.remove(sm);
>
> seems to guard the unchecked remove and I haven't seen any crashes
> since. (not sure of the overall repercussions of this change so please
> tell me if I'm crazy!)
>
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32597 is a reply to message #32563] Wed, 01 April 2009 14:13 Go to previous messageGo to next message
Nick Veys is currently offline Nick VeysFriend
Messages: 52
Registered: July 2009
Member
So far so good, our continuous int. server had never successfully built
this particular product and it did after that fix. My machine builds it
without issue as well. We have 6 products and several standalone features
as well as an update site being built in this build and everything else
seems unaffected.

Do you not want that exception to occur? Is it a guard against removal,
or a true exceptional problem? It seems bad to swap the lines and use the
exception as a guard since that hides what's going on, would moving that
getReferencingKeys() call out into the MetadataSynchronizer just before
the remove() calls be better?

Thomas Hallgren wrote:

> Hi Nick,
> Can you verify that this makes the problem go away? The reason the code is
in the order it is is that the cspec remove
> does this:

> public void remove(StorageManager sm) throws CoreException
> {
> UUID thisId = getId();
> if(!sm.getResolutions().getReferencingKeys(thisId, "cspecId").isEmpty())
//$NON-NLS-1$
> throw new ReferentialIntegrityException(this, "remove",
Messages.Referenced_from_Resolution); //$NON-NLS-1$

> sm.getCSpecs().removeElement(thisId);
> }

> which means that if the resolution still exists, the cspec cannot be
removed. The order asserts that a
> ReferentialIntegrityException is never thrown. Reversing it will provoke
that exception every time.
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32631 is a reply to message #32597] Wed, 01 April 2009 14:49 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
Hi Nick,
The removal of the Resolution will always succeed since Buckminster no longer stores any BillOfMaterials. A CSPEC can
exists without a Resolution that references it so it's actually OK if the first removal succeeds and the second fails.

I'm not surprised that you get less errors when things are turned around since that in effect will make any removal
impossible. The side effect is that the meta-data of the workspace will grow. Not a big deal though. I'm actually
contemplating a solution where we don't keep meta-data between invocations at all. We'll just keep track of things that
are materialized outside of the target platform or workspace.

- thomas


Nick Veys wrote:
> So far so good, our continuous int. server had never successfully built
> this particular product and it did after that fix. My machine builds it
> without issue as well. We have 6 products and several standalone
> features as well as an update site being built in this build and
> everything else seems unaffected.
>
> Do you not want that exception to occur? Is it a guard against removal,
> or a true exceptional problem? It seems bad to swap the lines and use
> the exception as a guard since that hides what's going on, would moving
> that getReferencingKeys() call out into the MetadataSynchronizer just
> before the remove() calls be better?
>
> Thomas Hallgren wrote:
>
>> Hi Nick,
>> Can you verify that this makes the problem go away? The reason the
>> code is
> in the order it is is that the cspec remove
>> does this:
>
>> public void remove(StorageManager sm) throws CoreException
>> {
>> UUID thisId = getId();
>> if(!sm.getResolutions().getReferencingKeys(thisId,
>> "cspecId").isEmpty())
> //$NON-NLS-1$
>> throw new ReferentialIntegrityException(this, "remove",
> Messages.Referenced_from_Resolution); //$NON-NLS-1$
>
>> sm.getCSpecs().removeElement(thisId);
>> }
>
>> which means that if the resolution still exists, the cspec cannot be
> removed. The order asserts that a
>> ReferentialIntegrityException is never thrown. Reversing it will provoke
> that exception every time.
>
Re: [buckminster-dev] No element with id ... was found in storage resolution [message #32666 is a reply to message #32631] Wed, 01 April 2009 16:19 Go to previous message
Nick Veys is currently offline Nick VeysFriend
Messages: 52
Registered: July 2009
Member
I see. So is there a better fix? I'll keep rolling with this as it
doesn't seem to harm anything in our case. Any more info I can get you
perhaps?

Thomas Hallgren wrote:

> Hi Nick,
> The removal of the Resolution will always succeed since Buckminster no
longer stores any BillOfMaterials. A CSPEC can
> exists without a Resolution that references it so it's actually OK if the
first removal succeeds and the second fails.

> I'm not surprised that you get less errors when things are turned around
since that in effect will make any removal
> impossible. The side effect is that the meta-data of the workspace will
grow. Not a big deal though. I'm actually
> contemplating a solution where we don't keep meta-data between invocations
at all. We'll just keep track of things that
> are materialized outside of the target platform or workspace.
Previous Topic:[buckminster-dev] Where is the 3.5 headless update site?
Next Topic:[buckminster-dev] Buckminster, headless and making the two co-operate
Goto Forum:
  


Current Time: Tue Mar 19 04:58:29 GMT 2024

Powered by FUDForum. Page generated in 0.02367 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top