Home » Modeling » EMF » [CDO] Uninitialized cannot be cast to CDOID
| [CDO] Uninitialized cannot be cast to CDOID [message #1634564] |
Wed, 25 February 2015 10:32  |
 Samuel Leisering
Messages: 34
Registered: July 2014 |
Member |
|
|
Hi
I have a CDO Server with a somewhat big content tree (around 200k objects). The Server is configured supporting audit views and branches and a DBStore backend.
Everything works fine until the server gets into a state where it repeatedly throws a ClassCastException (around 10 times a second), and stops completely until
the client that caused it disconnects, or the server is restarted. The exact Exception is:
java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$Uninitialized cannot be cast to org.eclipse.emf.cdo.common.id.CDOID
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.writeValue(CDOTypeImpl.java:246)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadChunkIndication.responding(LoadChunkIndication.java:106)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:301)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:256)
at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
When the exception occurs seems random, but it always does.
After some debugging and reading the code, i suspected that the line
repository.ensureChunk(revision, feature, fromIndex, toIndex + 1);
at LoadChunkIndication.java:99 does not do what it should, and there are still some unitialized objects in the chunk. Because of that i tried to configure the cache to be unchunked via
transaction.options().setRevisionPrefetchingPolicy(CDOUtil.createRevisionPrefetchingPolicy(-1));
and
session.options().setCollectionLoadingPolicy(CDOUtil.createCollectionLoadingPolicy(-1, -1));
and the exception is gone since.
Is this a bug in the CDO Server, or is it due to a special configuration (or Error) on my part?
I'm running CDO 4.3.
Greetings,
Samuel
|
|
|
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1634746 is a reply to message #1634564] |
Wed, 25 February 2015 12:31  |
|
Hi Samuel,
This has been reported before but I've only ever managed to reproduce it in one scenario and that's fixed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=369646
It has been reported in the newsgroup after that fix but without being able to reproduce it it's very hard for me to
find the cause. More comments below...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 25.02.2015 um 11:32 schrieb Samuel Leisering:
> Hi
>
> I have a CDO Server with a somewhat big content tree (around 200k objects). The Server is configured supporting audit
> views and branches and a DBStore backend.
>
> Everything works fine until the server gets into a state where it repeatedly throws a ClassCastException (around 10
> times a second), and stops completely until the client that caused it disconnects, or the server is restarted. The
> exact Exception is:
>
> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$Uninitialized cannot be cast to
> org.eclipse.emf.cdo.common.id.CDOID
> at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.writeValue(CDOTypeImpl.java:246)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadChunkIndication.responding(LoadChunkIndication.java:106)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:301)
> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:256)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
> When the exception occurs seems random, but it always does.
>
> After some debugging and reading the code, i suspected that the line repository.ensureChunk(revision, feature,
> fromIndex, toIndex + 1); at LoadChunkIndication.java:99 does not do what it should, and there are still some
> unitialized objects in the chunk. Because of that i tried to configure the cache to be unchunked via
> transaction.options().setRevisionPrefetchingPolicy(CDOUtil.createRevisionPrefetchingPolicy(-1));
That's not related to partial collection loading. Can you try without that call? We must try to get a clearer picture of
when it happens and when not.
> and
> session.options().setCollectionLoadingPolicy(CDOUtil.createCollectionLoadingPolicy(-1, -1));
>
> and the exception is gone since.
>
> Is this a bug in the CDO Server, or is it due to a special configuration (or Error) on my part?
Probably for former.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1634784 is a reply to message #1634746] |
Wed, 25 February 2015 12:59 |
|
Some more questions to understand the context of the problem:
- Are you using branching or auditing in your repo config?
- What has happened on the client side before that problem occurs? For example have you been in the process of switching
the branch of a view/transaction?
- How many client sessions are involved? How many views/transactions per session?
Am 25.02.2015 um 13:31 schrieb Eike Stepper:
> Hi Samuel,
>
> This has been reported before but I've only ever managed to reproduce it in one scenario and that's fixed:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=369646
>
> It has been reported in the newsgroup after that fix but without being able to reproduce it it's very hard for me to
> find the cause. More comments below...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 25.02.2015 um 11:32 schrieb Samuel Leisering:
>> Hi
>>
>> I have a CDO Server with a somewhat big content tree (around 200k objects). The Server is configured supporting audit
>> views and branches and a DBStore backend.
>>
>> Everything works fine until the server gets into a state where it repeatedly throws a ClassCastException (around 10
>> times a second), and stops completely until the client that caused it disconnects, or the server is restarted. The
>> exact Exception is:
>>
>> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$Uninitialized cannot be cast to
>> org.eclipse.emf.cdo.common.id.CDOID
>> at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.writeValue(CDOTypeImpl.java:246)
>> at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadChunkIndication.responding(LoadChunkIndication.java:106)
>> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
>> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
>> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:301)
>> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:256)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>> When the exception occurs seems random, but it always does.
>>
>> After some debugging and reading the code, i suspected that the line repository.ensureChunk(revision, feature,
>> fromIndex, toIndex + 1); at LoadChunkIndication.java:99 does not do what it should, and there are still some
>> unitialized objects in the chunk. Because of that i tried to configure the cache to be unchunked via
>> transaction.options().setRevisionPrefetchingPolicy(CDOUtil.createRevisionPrefetchingPolicy(-1));
> That's not related to partial collection loading. Can you try without that call? We must try to get a clearer picture
> of when it happens and when not.
>
>> and
>> session.options().setCollectionLoadingPolicy(CDOUtil.createCollectionLoadingPolicy(-1, -1));
>>
>> and the exception is gone since.
>>
>> Is this a bug in the CDO Server, or is it due to a special configuration (or Error) on my part?
> Probably for former.
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1634978 is a reply to message #1634784] |
Wed, 25 February 2015 14:55 |
Samuel Leisering
Messages: 34
Registered: July 2014 |
Member |
|
|
Hi,
thanks for the fast reply.
- The Repository supports both branching and auditing
- There is no distinguishable case when the client causes this, but it happens in the same transaction and the same branch. I suspect that it is a changing operation that causes this (like moving an item to another container, or adding elements).
- The amount of connected clients varies. I think the most clients that were connected when the bug occured was around 10, but it also happened with only one client connected to a locally running cdo-server with a different DB-Store backend than our production server.
A few things that should also be mentioned after some additional debugging:
- We sucessfully had multiple clients (around 5) connected for hours doing mostly read operations and some small write operations (adding/removing to HashMaps)
- A few changes with structural impact on the model were anough to cause this bug
- We encountered this bug once *with* the Policies set to -1 (after a structural change)
I took a look in the CDOServerBrowser and inspected a broken object. The object contains two HashMaps, which are defined as described here. The contents of both of these HashMaps are UNINITIALIZED. Every other cached object of this type has the correct entries in those maps (as it whould with the used caching policies)
Greetings,
Samuel
Eike Stepper wrote on Wed, 25 February 2015 07:59Some more questions to understand the context of the problem:
- Are you using branching or auditing in your repo config?
- What has happened on the client side before that problem occurs? For example have you been in the process of switching
the branch of a view/transaction?
- How many client sessions are involved? How many views/transactions per session?
Am 25.02.2015 um 13:31 schrieb Eike Stepper:
> Hi Samuel,
>
> This has been reported before but I've only ever managed to reproduce it in one scenario and that's fixed:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=369646
>
> It has been reported in the newsgroup after that fix but without being able to reproduce it it's very hard for me to
> find the cause. More comments below...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 25.02.2015 um 11:32 schrieb Samuel Leisering:
>> Hi
>>
>> I have a CDO Server with a somewhat big content tree (around 200k objects). The Server is configured supporting audit
>> views and branches and a DBStore backend.
>>
>> Everything works fine until the server gets into a state where it repeatedly throws a ClassCastException (around 10
>> times a second), and stops completely until the client that caused it disconnects, or the server is restarted. The
>> exact Exception is:
>>
>> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$Uninitialized cannot be cast to
>> org.eclipse.emf.cdo.common.id.CDOID
>> at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$11.writeValue(CDOTypeImpl.java:246)
>> at org.eclipse.emf.cdo.server.internal.net4j.protocol.LoadChunkIndication.responding(LoadChunkIndication.java:106)
>> at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.responding(CDOServerIndication.java:134)
>> at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedOutput(IndicationWithResponse.java:98)
>> at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:301)
>> at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:67)
>> at
>> org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerReadIndication.execute(CDOServerReadIndication.java:36)
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:256)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:149)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>> When the exception occurs seems random, but it always does.
>>
>> After some debugging and reading the code, i suspected that the line repository.ensureChunk(revision, feature,
>> fromIndex, toIndex + 1); at LoadChunkIndication.java:99 does not do what it should, and there are still some
>> unitialized objects in the chunk. Because of that i tried to configure the cache to be unchunked via
>> transaction.options().setRevisionPrefetchingPolicy(CDOUtil.createRevisionPrefetchingPolicy(-1));
> That's not related to partial collection loading. Can you try without that call? We must try to get a clearer picture
> of when it happens and when not.
>
>> and
>> session.options().setCollectionLoadingPolicy(CDOUtil.createCollectionLoadingPolicy(-1, -1));
>>
>> and the exception is gone since.
>>
>> Is this a bug in the CDO Server, or is it due to a special configuration (or Error) on my part?
> Probably for former.
>
>
|
|
|
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1635081 is a reply to message #1634978] |
Wed, 25 February 2015 16:00 |
|
Am 25.02.2015 um 15:55 schrieb Samuel Leisering:
> Hi,
> thanks for the fast reply.
> - The Repository supports both branching and auditing
> - There is no distinguishable case when the client causes this, but it happens in the same transaction and the same
> branch. I suspect that it is a changing operation that causes this (like moving an item to another container, or
> adding elements).
> - The amount of connected clients varies. I think the most clients that were connected when the bug occured was around
> 10, but it also happened with only one client connected to a locally running cdo-server with a different DB-Store
> backend than our production server.
>
> A few things that should also be mentioned after some additional debugging:
> - We sucessfully had multiple clients (around 5) connected for hours doing mostly read operations and some small write
> operations (adding/removing to HashMaps) - A few changes with structural impact on the model were anough to cause this
> bug
> - We encountered this bug once *with* the Policies set to -1 (after a structural change)
>
> I took a look in the CDOServerBrowser and inspected a broken object.
In the DB Tables, Revision Store or Revision Cache?
> The object contains two HashMaps, which are defined as described
> http://wiki.eclipse.org/index.php/EMF/FAQ#How_do_I_create_a_Map_in_EMF.3F. The contents of both of these HashMaps are
> UNINITIALIZED. Every other cached object of this type has the correct entries in those maps (as it whould with the
> used caching policies)
I want to play with these maps (in combination with partial collection loading) a little bit. Can you remember if the
deletion of list elements was involved before your problem occured?
The only theory I have is: At least one client enabled partial collection loading before it loaded a revision X. That
can (and is supposed to) keep this revision in the server's revision cache with some list elements being UNINITIALIZED.
The question is why are these "placeholder" objects not properly replaced later when a client triggers the
LoadChunkIndication (see your stack trace). The only thing that makes sense is that from that time on the problem
persists even if you then switch off partial collection loading in that client. The "chunked" revision is still in the
server's cache.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1635339 is a reply to message #1635206] |
Wed, 25 February 2015 18:57 |
|
Am 25.02.2015 um 18:28 schrieb Samuel Leisering:
> It was in the Revision Cache
>
> I think it was a Drag+Drop operation (with the emf-generated editor plugin), wich contains a remove operation if i
> remember correctly.
> Regarding your theory: This was exactly what we thought, and did some tests with clients without partial loading and
> one client with partial loading, all our results have been consistent with this.
This test case reproduces a similar problem:
public void testRemove() throws CommitException
{
// Init model
Company company = getModel1Factory().createCompany();
addCategoryAndProducts(company, "Software");
CDOSession session = openSession();
CDOTransaction tx = session.openTransaction();
CDOResource resource = tx.createResource(getResourcePath(RESOURCE_PATH));
resource.getContents().add(company);
tx.commit();
tx.close();
session.close();
clearCache(getRepository().getRevisionManager());
// Test session
session = openSession();
session.options().setCollectionLoadingPolicy(CDOUtil.createCollectionLoadingPolicy(3, 3));
tx = session.openTransaction();
resource = tx.getResource(getResourcePath(RESOURCE_PATH));
company = (Company)resource.getContents().get(0);
Category software = company.getCategories().get(0);
software.getProducts().remove(15);
tx.commit();
}
The exception is not exactly yours because it happens while committing. But I suspect that it could leave a bad revision
in the server cache.
Another good news: I was able to find and fix the silly bug that caused my exception. It's in
Repository.ensureChunks(InternalCDORevision, int). There the chunkSize parameter is adjusted to the list size of the
current feature (in a loop over all features). If the first list in a revision has size zero that effectively disables
the "unchunking" for all the remaining lists. This is the central method in the server that does this unchunking. So
it's very likely that my fix will solve your exception, too.
Can you please submit a bugzilla?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
| Re: [CDO] Uninitialized cannot be cast to CDOID [message #1636983 is a reply to message #1636974] |
Thu, 26 February 2015 13:29 |
|
Am 26.02.2015 um 14:20 schrieb Samuel Leisering:
> Okay, so after some testing the exception seems to be gone.
> However an exception we had some time ago resufaced, and it seems to be related:
>
>
> java.lang.ClassCastException: org.eclipse.emf.cdo.common.revision.CDORevisionUtil$Uninitialized cannot be cast to
> org.eclipse.emf.ecore.EObject
> at org.eclipse.emf.ecore.impl.BasicEObjectImpl$2.getChildren(BasicEObjectImpl.java:842)
> at org.eclipse.emf.common.util.AbstractTreeIterator.next(AbstractTreeIterator.java:138)
> at org.eclipse.emf.cdo.internal.server.LockingManager.createContentSet(LockingManager.java:262)
> at org.eclipse.emf.cdo.internal.server.LockingManager.lock2(LockingManager.java:217)
> at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1324)
> at org.eclipse.emf.cdo.internal.server.Repository.lock(Repository.java:1317)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.LockObjectsIndication.indicating(LockObjectsIndication.java:66)
This is not because of a bug in the central ensureChunks() method but because a revision does not know by itself how to
ensureChunks(). As a result we need to have these explicit calls wherever we use potentially chunked revisions. There
may even be more such places that don't consider them. Please reopen the bugzilla and attach the stack trace.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 22:54:29 GMT 2024
Powered by FUDForum. Page generated in 0.02877 seconds |
] 
Search
Help
Register
Login
Home
