Eclipse Community Forums: EMF » [CDO] Uninitialized cannot be cast to CDOID

Home » Modeling » EMF » [CDO] Uninitialized cannot be cast to CDOID

[CDO] Uninitialized cannot be cast to CDOID [message #1634564]

Wed, 25 February 2015 05:32

Eclipse User

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 07:31

Eclipse User

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 #1634784 is a reply to message #1634746]

Wed, 25 February 2015 07:59

Eclipse User

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

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1634978 is a reply to message #1634784]

Wed, 25 February 2015 09:55

Eclipse User

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

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1635081 is a reply to message #1634978]

Wed, 25 February 2015 11:00

Eclipse User

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

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1635206 is a reply to message #1635081]

Wed, 25 February 2015 12:28

Eclipse User

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.

Greetings,
Samuel

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1635339 is a reply to message #1635206]

Wed, 25 February 2015 13:57

Eclipse User

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

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1636372 is a reply to message #1635339]

Thu, 26 February 2015 01:47

Eclipse User

Am 25.02.2015 um 19:57 schrieb Eike Stepper:
> Can you please submit a bugzilla?
I've submitted one:

460882: ClassCastException: CDORevisionUtil$Uninitialized cannot be cast to CDOID
https://bugs.eclipse.org/bugs/show_bug.cgi?id=460882

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1636389 is a reply to message #1635339]

Thu, 26 February 2015 01:59

Eclipse User

Ok, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=460883

Greetings,
Samuel

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1636974 is a reply to message #1636389]

Thu, 26 February 2015 08:20

Eclipse User

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)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndication.indicating(CDOServerIndication.java:86)
	at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:92)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:331)
	at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:65)
	at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerWriteIndication.execute(CDOServerWriteIndication.java:39)
	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)

This happens on a recursive write Lock.

Greetings,
Samuel

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1636983 is a reply to message #1636974]

Thu, 26 February 2015 08:29

Eclipse User

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

Re: [CDO] Uninitialized cannot be cast to CDOID [message #1637046 is a reply to message #1636983]

Thu, 26 February 2015 09:07

Eclipse User

I attached the stacktrace to the bugzilla, but i cant reopen it

Greetings,
Samuel

Previous Topic:	Importing from Enterprise Architect
Next Topic:	[CDO] 2 clients / 2 JVM/ 1 collection / multiple set -> Java.lang.IllegalStateException

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 17:58:09 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter