Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX(Exception caused by accesing to CDOObject by CDOResource.getContents())
[CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #879970] Fri, 01 June 2012 08:06 Go to next message
Paco Blanco is currently offline Paco BlancoFriend
Messages: 28
Registered: June 2012
Junior Member
I fill the database trough CDO feature.

I have a resource with many contents inside from various EMF classes belongs to different auto-generated packages. After some actions to check the funcionality of CDO, I try to get the contents from the resource in this way:
for(EObject object : resource.getContents()) {
    ...
}

Resource is instanced:
CDOTransaction transaction = cdoSession.openTransaction();
CDOResource resource = (CDOResource) transaction.getOrCreateResource("/myResource");

The contents are iterated but when it comes to specific iteration, the next exception is thrown:
java.lang.IllegalStateException: Invalid synthetic type: 29
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:271)
	at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:146)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:143)
	at org.eclipse.emf.cdo.internal.net4j.protocol.LoadRevisionsRequest.confirming(LoadRevisionsRequest.java:1)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequest.confirming(CDOClientRequest.java:90)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedInput(RequestWithConfirmation.java:123)
	at org.eclipse.net4j.signal.Signal.doInput(Signal.java:326)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:103)
	at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:51)
	at org.eclipse.net4j.signal.Signal.runSync(Signal.java:251)
	at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:419)
	at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:87)
	at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:73)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:410)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:443)
	at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.loadRevisions(CDOClientProtocol.java:162)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.loadRevisions(CDORevisionManagerImpl.java:365)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevisions(CDORevisionManagerImpl.java:276)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:259)
	at org.eclipse.emf.cdo.internal.common.revision.CDORevisionManagerImpl.getRevision(CDORevisionManagerImpl.java:252)
	at org.eclipse.emf.internal.cdo.view.CDOViewImpl.getRevision(CDOViewImpl.java:430)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.createObject(AbstractCDOView.java:801)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.getObject(AbstractCDOView.java:715)
	at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.getObject(CDOTransactionImpl.java:1034)
	at org.eclipse.emf.internal.cdo.view.AbstractCDOView.convertIDToObject(AbstractCDOView.java:1028)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertIDToObject(CDOStoreImpl.java:668)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.convertToEMF(CDOStoreImpl.java:636)
	at org.eclipse.emf.internal.cdo.view.CDOStoreImpl.get(CDOStoreImpl.java:187)
	at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreEList.delegateGet(EStoreEObjectImpl.java:247)
	at org.eclipse.emf.common.util.DelegatingEList.get(DelegatingEList.java:236)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.doNext(AbstractEList.java:709)
	at org.eclipse.emf.common.util.AbstractEList$EIterator.next(AbstractEList.java:696)
	at com.example.model.consumer.CDOClientToTestEMFModel.CDOResourceInfoToStdOut(CDOClientToTestEMFModel.java:214)
	at com.example.model.consumer.CDOClientToTestEMFModel.deleteObjectWithXrefsFromTransaction(CDOClientToTestEMFModel.java:453)
	at com.example.model.consumer.CDOClientToTestEMFModel.popola(CDOClientToTestEMFModel.java:148)
	at com.example.model.consumer.CDOClientToTestEMFModel.run(CDOClientToTestEMFModel.java:75)
	at com.example.model.consumer.Activator.start(Activator.java:50)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702)
	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683)
	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381)
	at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:389)
	at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1131)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
	at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)


Some background data to place the problem:
mysql> select * from cdoresource_contents_list where cdo_source = 2;
+------------+---------+-----------+
| cdo_source | cdo_idx | cdo_value |
+------------+---------+-----------+
|          2 |       0 |         3 |
|          2 |       1 |         5 |
|          2 |       2 |         9 |
|          2 |       3 |        11 |
|          2 |       4 |        15 |
|          2 |       5 |        17 |
|          2 |       6 |        21 |
|          2 |       7 |        23 |
|          2 |       8 |        27 |
|          2 |       9 |        28 |
|          2 |      10 |        30 |
|          2 |      11 |        34 |
|          2 |      12 |        35 |
|          2 |      13 |        36 |
|          2 |      14 |        38 |
|          2 |      15 |        42 |
|          2 |      16 |        43 |
|          2 |      17 |        45 |
+------------+---------+-----------+
18 rows in set (0.02 sec)

resource.getContents().size() also returns 18.

The exception always occours at accesing to element 27. The previous elements (3, 5 ...23) are iterated well:
| cdo_id | cdo_version | cdo_created   | cdo_revised | cdo_resource | cdo_container | cdo_feature | graphicsElement | material | x    | y    | z    | scale |
+--------+-------------+---------------+-------------+--------------+---------------+-------------+-----------------+----------+------+------+------+-------+
|     27 |           1 | 1338302307364 |           0 |            2 |             0 |           0 |            NULL |       [b]29[/b] |    0 |  100 |    0 |     1 |

This element has a EReference to Object of cdoId 29 (maybe this is the synthetic type that refers the error).
This element has a normal structure in DB:
| cdo_id | cdo_version | cdo_created   | cdo_revised | cdo_resource | cdo_container | cdo_feature | selectedStyle | unselectedStyle | name                | code  |
|     29 |           1 | 1338302307364 |           0 |            0 |            28 |          -1 |            30 |            NULL | material en Part       | 32342 |

cdo_container and selectedStyle point to existent objets in DB and all the hierarchy looks well-structured.

Can someone have any idea about what there is wrong in my DB or in my code?

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #880017 is a reply to message #879970] Fri, 01 June 2012 09:29 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 01.06.2012 10:06, schrieb Paco Blanco:
> I fill the database trough CDO feature.
With what CDO version?

> [...] The contents are iterated but when it comes to specific iteration, the next exception is thrown:
>
> java.lang.IllegalStateException: Invalid synthetic type: 29
> at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:271)
> [...]
This doesn't match my latest 4.1 sources. Can you please re-test that with a newer CDO build, e.g.
http://www.eclipse.org/cdo/downloads/#S20120529_0159

It would also be good (not mandatory!) to test your scenario with H2 in addition to your MySQL setup.

> [...] The exception always occours at accesing to element 27. The previous elements (3, 5 ...23) are iterated well:
>
> | cdo_id | cdo_version | cdo_created | cdo_revised | cdo_resource | cdo_container | cdo_feature | graphicsElement |
> material | x | y | z | scale |
> +--------+-------------+---------------+-------------+--------------+---------------+-------------+-----------------+----------+------+------+------+-------+
>
> | 27 | 1 | 1338302307364 | 0 | 2 | 0 | 0 | NULL
> | 29 | 0 | 100 | 0 | 1 |
I guess that "29" just means "bold"?

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

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #880067 is a reply to message #880017] Fri, 01 June 2012 11:03 Go to previous messageGo to next message
Erdal Karaca is currently offline Erdal KaracaFriend
Messages: 854
Registered: July 2009
Senior Member
I remember having similar problems when starting to play with CDO: I had changed the meta model and tried to load the objects from the db which had an older structure... Do you have the same meta model on both sides (db/client)? Or do you have changed the EClass of object 29?

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #881247 is a reply to message #880067] Mon, 04 June 2012 08:03 Go to previous messageGo to next message
Paco Blanco is currently offline Paco BlancoFriend
Messages: 28
Registered: June 2012
Junior Member
CDO Version: 4.0.1

Erdal, your explication could be right Smile I have a conflict in my EMF model so I have to autogenerate all the model with the new changes. I do not remember very well but this EClass could have modifications.

By the way, I think the exception is no clear neither explanatory.
Does someone know if CDO DB metadata store some hashing of the EClass .java/.class when it generates the tables?

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #881754 is a reply to message #881247] Tue, 05 June 2012 07:47 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 04.06.2012 10:03, schrieb Paco Blanco:
> By the way, I think the exception is no clear neither explanatory.
If this exception is thrown the code has read a byte opcode from the network and the value is not recognized a valid
opcode. This can be caused by a bug in CDO (highly unlikely here) or by misusage, such as different protocol versions in
client and server (as Erdal suggested).

Are you suggesting to add a hint like "Please check that your client and server are using the same protocol version!" to
the exception message?

Please note that the same problem can lead to literally any kind of unpredictable follow-up exception. Most of them can
not be tracked down to the root cause at the point in time they cause a problem.

> Does someone know if CDO DB metadata store some hashing of the EClass .java/.class when it generates the tables?
What do you mean by "hashing"?

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

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #882318 is a reply to message #881754] Wed, 06 June 2012 08:48 Go to previous messageGo to next message
Paco Blanco is currently offline Paco BlancoFriend
Messages: 28
Registered: June 2012
Junior Member
> Are you suggesting to add a hint like "Please check that your client and server are using the same protocol version!" to the exception message?
Yes, I do Smile

> What do you mean by "hashing"?
(My english is very bad and I use spanglish terms)
Hashing is refered to Cryptographic_hash_function. You know, MD5, SHA-X... But I think if exception is thrown, it is because an internal protocol version comparation (hash-based or not) is used.

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #882334 is a reply to message #882318] Wed, 06 June 2012 09:09 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 06.06.2012 10:48, schrieb Paco Blanco:
>> Are you suggesting to add a hint like "Please check that your client and server are using the same protocol version!"
>> to the exception message?
> Yes, I do :)
Then submit a bugzilla please ;-)

>
>> What do you mean by "hashing"?
> (My english is very bad and I use spanglish terms)
> Hashing is refered to Cryptographic_hash_function. You know, MD5, SHA-X... But I think if exception is thrown, it is
> because an internal protocol version comparation (hash-based or not) is used.
So, as to your original question:

> Does someone know if CDO DB metadata store some hashing of the EClass .java/.class when it generates the tables?

No, it doesn't. Nor does it currently persist the original class name --> table name relation during the first mapping.
It's derived from the useconfigured naming strategy each tiome the server is (re-)started.

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

Report message to a moderator

Re: [CDO] java.lang.IllegalStateException: Invalid synthetic type: XX [message #1386659 is a reply to message #882334] Thu, 19 June 2014 09:10 Go to previous message
david seb is currently offline david sebFriend
Messages: 1
Registered: June 2014
Junior Member
Hello,
I have the same problem, when i try to connect to the cdo repository using CDO Session view i get this exception :
Invalid synthetic type: 11
java.lang.IllegalStateException: Invalid synthetic type: 11
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:315)
at org.eclipse.emf.cdo.spi.common.revision.RevisionInfo.readResult(RevisionInfo.java:166)
thanks

Report message to a moderator

Previous Topic:[CDO] Problem loading older revisions of object with 4.3
Next Topic:EMF to file
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Apr 25 15:46:27 GMT 2024

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

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

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly