Bugzilla – Full Text Bug Listing
| Summary: | Error in LockingNotificationsTest.testSameBranchDifferentSession [Combined, MEM-branching, JVM, Native] | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Eike Stepper <stepper> |
| Component: | cdo.core | Assignee: | Caspar D. <caspar_d> |
| Status: | NEW --- | QA Contact: | Eike Stepper <stepper> |
| Severity: | minor | ||
| Priority: | P3 | ||
| Version: | 4.13 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 353691 | ||
| Bug Blocks: | |||
|
Description
Eike Stepper
I've seen this locally and on Hudson, e.g., https://hudson.eclipse.org/hudson/job/emf-cdo-integration/1745/testReport/junit/org.eclipse.emf.cdo.tests.AllConfigs$Scenario%5BCombined,%20MEM-branching,%20JVM,%20Native%5D$org.eclipse.emf.cdo.tests/LockingNotificationsTest/testSameBranchDifferentSession/ I've seen this happen too, but rarely. It's the controlView's session (session2) that doesn't know the model1 ePackage. It's registry is always an instance of CDOPackageRegistryImpl, and apparently it's this registry that returns null on CDOClassifierRef.java:110. When I debug from there, I end up at: CDOPackageUnitImpl.loadPackageFromGlobalRegistry(String) line: 391 CDOPackageUnitImpl.loadPackagesFromGlobalRegistry() line: 379 CDOPackageUnitImpl.load(InternalCDOPackageRegistry$PackageLoader, boolean) line: 247 CDOPackageUnitImpl.load(boolean) line: 239 CDOPackageInfoImpl.doGetEPackage(boolean) line: 123 CDOPackageInfoImpl.getEPackage(boolean) line: 110 CDOPackageInfoImpl.getEPackage() line: 105 CDOPackageRegistryImpl(EPackageRegistryImpl).getEPackage(String) line: 133 CDOClassifierRef.resolve(EPackage$Registry) line: 110 That's where the matter is delegated to EPackage.Registry.INSTANCE, which I thought was always a simple singleton. But it's not. In fact it's an instance of EPackageRegistryImpl.Delegator, which looks up a ClassLoader for the current thread, and then uses that as a key into a classloader- to-registry map...... and if there's no registry for the classloader, then it creates a registry that delegates to the registry of the parent classloader....... :-S This is all waaaaay over my head. I'm at a loss to understand why the global registry works this way, under what circumstances this would fail, and how our test code causes such a failure. Any comments welcome. I'm going to disable LockingNotificationsTest.testSameBranchDifferentSession_explicitRelease() because it's failing all too often and it *seems* to be an issue with the test framework. *** Bug 358603 has been marked as a duplicate of this bug. *** Committed revision 9203 Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2. Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |