Home » Modeling » EMF » CDO: Standalone Setup for programming with the API
CDO: Standalone Setup for programming with the API [message #1753757] |
Thu, 09 February 2017 18:37 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello everyone,
I'm trying to set up a CDO server in standalone mode (i.e. outside of Eclipse), and I intend to use its Java API directly (no GUI). However, all examples and tutorials that I can find are either explaining the user interface, or are outdated and don't even compile anymore. The closest thing to what I want that I have found so far is this:
http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.examples/src/org/eclipse/emf/cdo/examples/server/Server.java
... which works (i.e. the server starts up, the database schema is being created and so on), however the code example does unfortunately not show how to create a CDOSession object to work with. So, given the example above, how do I extend it so that I can interact with a CDOSession object? I don't need a client/server separation, in my case everything is inside the same JVM.
I'd be grateful for any advice on this topic.
Thanks,
Alan
|
|
| | | | | |
Re: CDO: Standalone Setup for programming with the API [message #1754023 is a reply to message #1753960] |
Mon, 13 February 2017 21:38 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Eike Stepper wrote on Mon, 13 February 2017 07:38You missed my comment about using "Newer integration builds"
Please try http://download.eclipse.org/modeling/emf/cdo/updates/integration ...
Ah, indeed I must have overlooked that comment, I'm sorry, my bad. If you don't mind me asking, is there a way for me how I can manage the CDO dependencies outside of an Eclipse environment, for example via Maven/Gradle or with a single big Jar file that contains all classes CDO needs to run? The only way I see to access those integration builds would be to download the p2 update site (Eclipse can do that) and manually manage the dependencies, but given the high number of individual Jar files used by CDO, this seems like a very error-prone task...
[Updated on: Mon, 13 February 2017 21:40] Report message to a moderator
|
|
| | |
Re: CDO: Standalone Setup for programming with the API [message #1754296 is a reply to message #1754217] |
Thu, 16 February 2017 09:12 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello,
first of all: thanks A LOT for your support on this matter, I really appreciate it! I used @Guillaume Hillairet's mavenized version of CDO, together with the example code provided by @Eike Stepper, and I finally got an embedded CDO server up and running - great! I then took the liberty to change a few things in the CDOFacade class. First of all, I used the MySQL connector instead of H2, this worked out of the box. However, afterwards I changed 'AUDITING' and 'BRANCHING' to 'true'. Then, the following exception occurred:
org.eclipse.net4j.util.transaction.TransactionException: Rollback in DBStore: org.eclipse.net4j.db.DBException: java.sql.SQLException: Table definition has changed, please retry transaction
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.queryResources(AbstractHorizontalMappingStrategy.java:470)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.queryResources(AbstractHorizontalMappingStrategy.java:126)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.queryResources(DBStoreAccessor.java:341)
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.readResourceID(StoreAccessorBase.java:201)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalClassMapping.checkDuplicateResources(AbstractHorizontalClassMapping.java:572)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.writeRevision(HorizontalBranchingClassMapping.java:741)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.writeRevision(DBStoreAccessor.java:615)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.writeRevisions(DBStoreAccessor.java:580)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.writeNewObjectRevisions(DBStoreAccessor.java:564)
at org.eclipse.emf.cdo.spi.server.StoreAccessor.doWrite(StoreAccessor.java:102)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.doWrite(DBStoreAccessor.java:888)
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.write(StoreAccessorBase.java:138)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.writeAccessor(TransactionCommitContext.java:1612)
at org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(TransactionCommitContext.java:737)
at org.eclipse.emf.cdo.internal.server.Repository.initRootResource(Repository.java:2226)
at org.eclipse.emf.cdo.internal.server.Repository.doActivate(Repository.java:2430)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.ShareableLifecycle.internalActivate(ShareableLifecycle.java:43)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:127)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:117)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.activateRepository(CDOEmbeddedRepositoryConfig.java:159)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.doActivate(CDOEmbeddedRepositoryConfig.java:188)
at org.eclipse.emf.cdo.examples.embedded.CDOFacade.doActivate(CDOFacade.java:138)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.example.cdotest.CdoTest.runTest(CdoTest3.java:23)
Caused by: java.sql.SQLException: Table definition has changed, please retry transaction
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4190)
at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:2143)
at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1999)
at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:3496)
at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:490)
at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:3198)
at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:2366)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2789)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2818)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2157)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2324)
at org.eclipse.net4j.internal.db.DBPreparedStatement.executeQuery(DBPreparedStatement.java:112)
at org.eclipse.net4j.internal.db.DBPreparedStatement.executeQuery(DBPreparedStatement.java:1)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.queryResources(AbstractHorizontalMappingStrategy.java:450)
... 49 more
at org.eclipse.emf.cdo.internal.server.Repository.initRootResource(Repository.java:2232)
at org.eclipse.emf.cdo.internal.server.Repository.doActivate(Repository.java:2430)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.ShareableLifecycle.internalActivate(ShareableLifecycle.java:43)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:127)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:117)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.activateRepository(CDOEmbeddedRepositoryConfig.java:159)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.doActivate(CDOEmbeddedRepositoryConfig.java:188)
at org.eclipse.emf.cdo.examples.embedded.CDOFacade.doActivate(CDOFacade.java:138)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.example.cdotest.CdoTest.runTest(CdoTest3.java:23)
... all I really did was to enable branching and auditing. This however seems to have corrupted the database. When I restart the server on the same MySQL database, I get this:
java.lang.NullPointerException
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalClassMapping.initTable(AbstractHorizontalClassMapping.java:128)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalClassMapping.<init>(AbstractHorizontalClassMapping.java:112)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingClassMapping.<init>(HorizontalBranchingClassMapping.java:204)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.HorizontalBranchingMappingStrategy.doCreateClassMapping(HorizontalBranchingMappingStrategy.java:62)
at org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.createClassMapping(AbstractMappingStrategy.java:683)
at org.eclipse.emf.cdo.server.internal.db.mapping.AbstractMappingStrategy.getClassMapping(AbstractMappingStrategy.java:732)
at org.eclipse.emf.cdo.server.internal.db.mapping.horizontal.AbstractHorizontalMappingStrategy.queryResources(AbstractHorizontalMappingStrategy.java:125)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.queryResources(DBStoreAccessor.java:341)
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.readResourceID(StoreAccessorBase.java:201)
at org.eclipse.emf.cdo.internal.server.Repository.readRootResource(Repository.java:2276)
at org.eclipse.emf.cdo.internal.server.Repository.doActivate(Repository.java:2437)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.ShareableLifecycle.internalActivate(ShareableLifecycle.java:43)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:127)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:117)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.activateRepository(CDOEmbeddedRepositoryConfig.java:159)
at org.eclipse.emf.cdo.server.embedded.CDOEmbeddedRepositoryConfig.doActivate(CDOEmbeddedRepositoryConfig.java:188)
at org.eclipse.emf.cdo.examples.embedded.CDOFacade.doActivate(CDOFacade.java:138)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.example.cdotest.CdoTest.runTest(CdoTest3.java:23)
Am I doing something wrong here? Did I simply run into a bug? Or is auditing/branching not supported on MySQL?
EDIT: It works fine on H2. Seems to be an issue with the MySQL adapter.
[Updated on: Thu, 16 February 2017 09:47] Report message to a moderator
|
|
|
Re: CDO: Standalone Setup for programming with the API [message #1754320 is a reply to message #1754296] |
Thu, 16 February 2017 11:28 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
... one more thing. I am currently experimenting with the CDO API, and when adding a larger set of EObjects to the CDO Resource and then commiting the transaction, I'm getting the following exception:
org.eclipse.emf.cdo.util.CommitException: java.lang.IllegalStateException: peerChannel == null
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commitSynced(CDOTransactionImpl.java:1679)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1585)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1552)
at org.example.cdotest.CdoTest.runTest(CdoTest.java:38)
Caused by: java.lang.IllegalStateException: peerChannel == null
at org.eclipse.net4j.internal.jvm.JVMConnector.multiplexChannel(JVMConnector.java:78)
at org.eclipse.spi.net4j.Channel.handleBuffer(Channel.java:212)
at org.eclipse.net4j.buffer.BufferOutputStream.flushPrivate(BufferOutputStream.java:153)
at org.eclipse.net4j.buffer.BufferOutputStream.flushIfFilled(BufferOutputStream.java:145)
at org.eclipse.net4j.buffer.BufferOutputStream.write(BufferOutputStream.java:104)
at java.io.OutputStream.write(OutputStream.java:116)
at java.io.DataOutputStream.write(DataOutputStream.java:107)
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:401)
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:323)
at org.eclipse.net4j.util.io.ExtendedIOUtil.writeString(ExtendedIOUtil.java:303)
at org.eclipse.net4j.util.io.ExtendedDataOutputStream.writeString(ExtendedDataOutputStream.java:50)
at org.eclipse.net4j.util.io.ExtendedDataOutput$Delegating.writeString(ExtendedDataOutput.java:146)
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$26.doWriteValue(CDOTypeImpl.java:616)
at org.eclipse.emf.cdo.internal.common.model.CDOTypeImpl$ObjectType.writeValue(CDOTypeImpl.java:1108)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDOFeatureValue(CDODataOutputImpl.java:521)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeValue(BaseCDORevision.java:434)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeValues(BaseCDORevision.java:391)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.write(BaseCDORevision.java:345)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:412)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:404)
at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requestingCommit(CommitTransactionRequest.java:210)
at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requesting(CommitTransactionRequest.java:146)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequestWithMonitoring.requesting(CDOClientRequestWithMonitoring.java:93)
at org.eclipse.net4j.signal.RequestWithMonitoring.requesting(RequestWithMonitoring.java:175)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedOutput(RequestWithConfirmation.java:119)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:346)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:104)
at org.eclipse.net4j.signal.RequestWithMonitoring.doExecute(RequestWithMonitoring.java:245)
at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:53)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:465)
at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:89)
at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:75)
at org.eclipse.net4j.signal.RequestWithMonitoring.send(RequestWithMonitoring.java:112)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:617)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.commitTransaction(CDOClientProtocol.java:420)
at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:63)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commitSynced(CDOTransactionImpl.java:1621)
... 26 more
I can't really decipher anything from this message and/or how to fix this...
[Updated on: Thu, 16 February 2017 11:34] Report message to a moderator
|
|
| | |
Re: CDO: Standalone Setup for programming with the API [message #1754514 is a reply to message #1754467] |
Sun, 19 February 2017 10:45 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello Eike,
thank you for your support, it's highly appreciated. Getting CDO to run is a very important task for me right now.
Eike Stepper wrote on Sat, 18 February 2017 02:21You must not change auditing or branching anymore after the first startup of the repo. Whenever you change those properties you must delete the DB and start freshly. Was that your problem?
I figured that CDO would need a different schema for scenarios with auditing and branching. I therefore restarted my test code on a fresh, empty MySQL schema. This resulted in the exception stacktrace shown above. So, I can definitly exclude a pre-existing schema as a source of error. My best guess from my current point of view is that CDO performs ALTER TABLE statements, and tries to access a modified table in the same transaction before calling commit(). Apparently, H2 can deal with this issue, but MySQL can't.
Eike Stepper wrote on Sat, 18 February 2017 02:33Something must have closed/removed the IChannel in the peer JVMConnector. Can you set a breakpoint in org.eclipse.spi.net4j.ChannelMultiplexer.removeChannel(InternalChannel) and post the stacktrace(s) when that happens?
Unfortunately the maven distribution, kindly provided by @Guillaume Hillairet, does not include JavaDoc and/or source code. So I am currently left without the CDO source code to work with. This will make things very difficult in the debugger. I can try to fetch the CDO source code directly from the Git repository and wire it up manually in my Eclipse workspace.
What I can already tell you right now:
org.eclipse.emf.cdo.util.CommitException: java.lang.IllegalStateException: peerChannel == null
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commitSynced(CDOTransactionImpl.java:1679)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1585)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1552)
at org.example.cdotest.CdoTest.runTest(CdoTest.java:38)
Caused by: java.lang.IllegalStateException: peerChannel == null
at org.eclipse.net4j.internal.jvm.JVMConnector.multiplexChannel(JVMConnector.java:78)
at org.eclipse.spi.net4j.Channel.handleBuffer(Channel.java:212)
at org.eclipse.net4j.buffer.BufferOutputStream.flushPrivate(BufferOutputStream.java:153)
at org.eclipse.net4j.buffer.BufferOutputStream.flushIfFilled(BufferOutputStream.java:145)
at org.eclipse.net4j.buffer.BufferOutputStream.write(BufferOutputStream.java:104)
The problem with the missing peer channel seems to be connected with 'org.eclipse.net4j.buffer.BufferOutputStream.flushIfFilled'. If I commit a small transaction with only a few objects, then it works as intended. However, when I add a larger amount of EObjects to the transaction resource and commit the transaction, then the buffer is flushed and things start going wrong.
I'll try to get the source code linked to my CDO JAR files, then I'll report back.
|
|
|
Re: CDO: Standalone Setup for programming with the API [message #1754517 is a reply to message #1754514] |
Sun, 19 February 2017 11:28 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello again,
as requested, I have installed a breakpoint on 'org.eclipse.spi.net4j.ChannelMultiplexer.removeChannel(InternalChannel)' and re-run my test code in debug mode. It turns out that the 'removeChannel' method is called twice, both times by non-main threads. Here are the stack traces of the method calls:
Daemon Thread [net4j-thread-7] (Suspended (entry into method removeChannel in ChannelMultiplexer))
JVMServerConnector(ChannelMultiplexer).removeChannel(InternalChannel) line: 378
JVMServerConnector(ChannelMultiplexer).closeChannel(InternalChannel) line: 220
JVMChannel(Channel).unregisterFromMultiplexer() line: 321
JVMChannel(Channel).doDeactivate() line: 303
JVMChannel(Lifecycle).internalDeactivate() line: 129
JVMChannel(Lifecycle).deactivate() line: 167
LifecycleUtil.deactivate(Object, boolean) line: 234
LifecycleUtil.deactivate(Object) line: 224
JVMServerConnector(ChannelMultiplexer).inverseCloseChannel(short) line: 226
JVMClientConnector(JVMConnector).deregisterChannelFromPeer(InternalChannel) line: 146
JVMClientConnector(ChannelMultiplexer).closeChannel(InternalChannel) line: 219
JVMChannel(Channel).unregisterFromMultiplexer() line: 321
JVMChannel(Channel).doDeactivate() line: 303
JVMChannel(Lifecycle).internalDeactivate() line: 129
JVMChannel(Lifecycle).deactivate() line: 167
LifecycleUtil.deactivate(Object, boolean) line: 234
LifecycleUtil.deactivate(Object) line: 224
SignalProtocol$SignalInputStream.closeChannel() line: 636
SignalProtocol$SignalInputStream(BufferInputStream).close() line: 177
IOUtil.closeSilent(Closeable) line: 302
RemoteExceptionIndication(Signal).runSync() line: 299
RemoteExceptionIndication(Signal).run() line: 162
ThreadPool(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1142
ThreadPoolExecutor$Worker.run() line: 617 [local variables unavailable]
Thread.run() line: 745
... and the second one:
Daemon Thread [net4j-thread-7] (Suspended (entry into method removeChannel in ChannelMultiplexer))
JVMClientConnector(ChannelMultiplexer).removeChannel(InternalChannel) line: 378
JVMClientConnector(ChannelMultiplexer).closeChannel(InternalChannel) line: 220
JVMChannel(Channel).unregisterFromMultiplexer() line: 321
JVMChannel(Channel).doDeactivate() line: 303
JVMChannel(Lifecycle).internalDeactivate() line: 129
JVMChannel(Lifecycle).deactivate() line: 167
LifecycleUtil.deactivate(Object, boolean) line: 234
LifecycleUtil.deactivate(Object) line: 224
SignalProtocol$SignalInputStream.closeChannel() line: 636
SignalProtocol$SignalInputStream(BufferInputStream).close() line: 177
IOUtil.closeSilent(Closeable) line: 302
RemoteExceptionIndication(Signal).runSync() line: 299
RemoteExceptionIndication(Signal).run() line: 162
ThreadPool(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1142
ThreadPoolExecutor$Worker.run() line: 617 [local variables unavailable]
Thread.run() line: 745
At least for me, this information is unfortunately rather inconclusive. What jumped at me is 'RemoteExceptionIndication'. Judging by the name of this class, it may indicate that another exception has been raised, which caused the termination of the JVM Channel. I looked at it in the debugger (I only have the bytecode for now, but the JDT debugger can deal with it), and here's the value of the field "RemoteExceptionIndication#t":
java.io.UTFDataFormatException: malformed input around byte 0
at java.io.DataInputStream.readUTF(DataInputStream.java:656)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at org.eclipse.net4j.util.io.ExtendedIOUtil.readString(ExtendedIOUtil.java:324)
at org.eclipse.net4j.util.io.ExtendedDataInputStream.readString(ExtendedDataInputStream.java:52)
at org.eclipse.net4j.util.io.ExtendedDataInput$Delegating.readString(ExtendedDataInput.java:153)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.OpenSessionIndication.indicating(OpenSessionIndication.java:89)
at org.eclipse.emf.cdo.server.internal.net4j.protocol.CDOServerIndicationWithMonitoring.indicating(CDOServerIndicationWithMonitoring.java:118)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:87)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100), org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:66)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283), org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
... again, unfortunately I can't make much of this stack trace. All I can tell is that some communication issue has occurred...
|
|
| |
Re: CDO: Standalone Setup for programming with the API [message #1754527 is a reply to message #1754520] |
Sun, 19 February 2017 14:04 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello again!
Eike Stepper wrote on Sun, 19 February 2017 07:17Your conclusions were right so far. Unfortunately I can't say more without debugging it myself. Do you see a chance to send me an executable test case or simple instructions on how to reproduce the problem?
I have prepared an Eclipse project as a *.zip file and attached it to this post. If you are using Eclipse, it should import cleanly via "File -> Import -> Archive File". It is a Maven project, so you need to run "maven clean" and "maven install" once to set up the dependencies (I think all Eclipse JDT installs nowadays ship with the maven plugin anyways).
Once the setup is done, you will find two JUnit tests in src/test/java:
- org.example.cdotest.MinimalCdoTest is a bare-bones minimal test to verify the CDO installation. This test should run successfully (it does on my machine).
- org.example.cdotest.GrabatsCdoTest is a more involved test. It loads the standard Grabats Ecore metamodels (details in this paper) and a larger instance model from the files in "src/test/resources". Then, it simply tries to persist this instance model in CDO. This might not be the fastest way to batch-load a model, but it should at least work. However, the test fails with the known "channel == null" exception.
I took the liberty to modify your CDOFacade a bit to make it more configurable from the caller side, but you should still recognize your code in there. I am essentially trying to recreate the benchmark from the paper linked above.
[Updated on: Sun, 19 February 2017 14:05] Report message to a moderator
|
|
|
Re: CDO: Standalone Setup for programming with the API [message #1754631 is a reply to message #1754527] |
Tue, 21 February 2017 08:16 |
|
I tried it now, but am running into various problems. First I had to figure out how to use Java 8 compliance:
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
Then these come up:
Running org.example.cdotest.GrabatsCdoTest
Loaded GRABATS set0.xmi into a String in 50ms.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.429 sec <<< FAILURE!
runTest(org.example.cdotest.GrabatsCdoTest) Time elapsed: 1.388 sec <<< ERROR!
java.io.IOException: Unable to delete file: C:\Users\Stepper\AppData\Local\Temp\1487662920962-0\repo.mv.db
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
at org.example.cdotest.GrabatsCdoTest.runTest(GrabatsCdoTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Looking at your models it strikes me that the PrimitiveTypes packages are at least not very optimal. I think you should use EString, EBoolean(Object), and EInteger(Object) instead.
Given that I can't run your Maven-based test project and that, even if I could run it, I'm not sure what exactly is in these Maven artifacts for CDO, could you try to install a regular CDO workspace? It's rather easy if you follow https://wiki.eclipse.org/CDO_Source_Installation . In that workspace you should create a Plug-in Project for your code, so that it' trivial to add the required dependencies from the target platform and execute it.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: CDO: Standalone Setup for programming with the API [message #1754633 is a reply to message #1754631] |
Tue, 21 February 2017 08:38 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello,
first of all, thanks for your efforts!
Eike Stepper wrote on Tue, 21 February 2017 03:16I tried it now, but am running into various problems. First I had to figure out how to use Java 8 compliance:
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
I'm sorry about that, I missed that. My bad.
Eike Stepper wrote on Tue, 21 February 2017 03:16
Then these come up:
Running org.example.cdotest.GrabatsCdoTest
Loaded GRABATS set0.xmi into a String in 50ms.
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.429 sec <<< FAILURE!
runTest(org.example.cdotest.GrabatsCdoTest) Time elapsed: 1.388 sec <<< ERROR!
java.io.IOException: Unable to delete file: C:\Users\Stepper\AppData\Local\Temp\1487662920962-0\repo.mv.db
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2381)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1679)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1575)
at org.example.cdotest.GrabatsCdoTest.runTest(GrabatsCdoTest.java:61)
It looks like Maven tried to execute the JUnit tests upon installation. We already know that the GrabatsCdoTest won't execute successfully, but this exception is indeed new to me. Basically the test just tries to clean up the H2 database files in the temp directory here.
Eike Stepper wrote on Tue, 21 February 2017 03:16Looking at your models it strikes me that the PrimitiveTypes packages are at least not very optimal. I think you should use EString, EBoolean(Object), and EInteger(Object) instead.
I fully agree with you, these models are not optimal (which is a very polite way to put it). However, I did not create them - they are the standard GRABATS Benchmark Models (please see this page for details). So they are unfortunately outside of my control.
Eike Stepper wrote on Tue, 21 February 2017 03:16Given that I can't run your Maven-based test project and that, even if I could run it, I'm not sure what exactly is in these Maven artifacts for CDO, could you try to install a regular CDO workspace? It's rather easy if you follow https://wiki.eclipse.org/CDO_Source_Installation . In that workspace you should create a Plug-in Project for your code, so that it' trivial to add the required dependencies from the target platform and execute it.
Alright, I wanted to avoid fiddling with Eclipse Plug-Ins (lots and lots of bad experience in the past), but if it will help me to get it working, then I'll try that next.
I'll report back after experimenting with the source installation. Until then, thanks a lot for all your help!
|
|
| |
Re: CDO: Standalone Setup for programming with the API [message #1754833 is a reply to message #1754658] |
Wed, 22 February 2017 22:28 |
Alan DW Messages: 119 Registered: March 2012 |
Senior Member |
|
|
Hello again,
as promised, I followed your instructions to the letter and installed the CDO Source workspace via Oomph. That process took a while but was surprisingly smooth. I have now the CDO sources on my machine, they compile without error, I can start the server, and all unit tests I tried run well. It looks like the installation has succeeded this time.
I took the tests in the project org.eclipse.emf.cdo.examples.hibernate.client as a starting point, created a plugin with the same settings and dependencies (except with JUnit 4 instead of 3), and copied some of the source code to make a basic test work. And indeed, the basic test (QuickStartTest) works very well when starting from my plugin. I have attached the entire plugin project to this post as an archive.
However, when I again tried to load the Grabats benchmark model, I got an exception on the client that is quite similar to what we have seen before (see src/test/java/org/example/cdotest/test/GrabatsTest.java):
org.eclipse.emf.cdo.util.CommitException: org.eclipse.net4j.util.lifecycle.LifecycleException: Not active: SignalProtocol[cdo]
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commitSynced(CDOTransactionImpl.java:1679)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1585)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commit(CDOTransactionImpl.java:1552)
at org.example.cdotest.test.GrabatsTest.runTest(GrabatsTest.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.eclipse.net4j.util.lifecycle.LifecycleException: Not active: SignalProtocol[cdo]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(LifecycleUtil.java:100)
at org.eclipse.net4j.signal.Signal.getProtocol(Signal.java:95)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequestWithMonitoring.getProtocol(CDOClientRequestWithMonitoring.java:59)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequestWithMonitoring$1.getPackageURICompressor(CDOClientRequestWithMonitoring.java:122)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDOPackageURI(CDODataOutputImpl.java:163)
at org.eclipse.emf.cdo.common.model.CDOClassifierRef.write(CDOClassifierRef.java:91)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDOClassifierRef(CDODataOutputImpl.java:153)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.writeSystemValues(BaseCDORevision.java:368)
at org.eclipse.emf.cdo.spi.common.revision.BaseCDORevision.write(BaseCDORevision.java:314)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:412)
at org.eclipse.emf.cdo.spi.common.protocol.CDODataOutputImpl.writeCDORevision(CDODataOutputImpl.java:404)
at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requestingCommit(CommitTransactionRequest.java:210)
at org.eclipse.emf.cdo.internal.net4j.protocol.CommitTransactionRequest.requesting(CommitTransactionRequest.java:146)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientRequestWithMonitoring.requesting(CDOClientRequestWithMonitoring.java:93)
at org.eclipse.net4j.signal.RequestWithMonitoring.requesting(RequestWithMonitoring.java:175)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExtendedOutput(RequestWithConfirmation.java:119)
at org.eclipse.net4j.signal.Signal.doOutput(Signal.java:346)
at org.eclipse.net4j.signal.RequestWithConfirmation.doExecute(RequestWithConfirmation.java:104)
at org.eclipse.net4j.signal.RequestWithMonitoring.doExecute(RequestWithMonitoring.java:245)
at org.eclipse.net4j.signal.SignalActor.execute(SignalActor.java:53)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalProtocol.java:465)
at org.eclipse.net4j.signal.RequestWithConfirmation.doSend(RequestWithConfirmation.java:89)
at org.eclipse.net4j.signal.RequestWithConfirmation.send(RequestWithConfirmation.java:75)
at org.eclipse.net4j.signal.RequestWithMonitoring.send(RequestWithMonitoring.java:112)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.send(CDOClientProtocol.java:617)
at org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientProtocol.commitTransaction(CDOClientProtocol.java:420)
at org.eclipse.emf.internal.cdo.transaction.CDOSingleTransactionStrategyImpl.commit(CDOSingleTransactionStrategyImpl.java:63)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.commitSynced(CDOTransactionImpl.java:1621)
... 27 more
On the server, the following message is printed when running the test:
[ERROR] Negative delay.
java.lang.IllegalArgumentException: Negative delay.
at java.util.Timer.scheduleAtFixedRate(Timer.java:325)
at org.eclipse.net4j.util.om.monitor.Monitor.scheduleAtFixedRate(Monitor.java:90)
at org.eclipse.net4j.signal.IndicationWithMonitoring$ReportingMonitor.<init>(IndicationWithMonitoring.java:144)
at org.eclipse.net4j.signal.IndicationWithMonitoring.indicating(IndicationWithMonitoring.java:84)
at org.eclipse.net4j.signal.IndicationWithResponse.doExtendedInput(IndicationWithResponse.java:100)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:377)
at org.eclipse.net4j.signal.IndicationWithResponse.execute(IndicationWithResponse.java:73)
at org.eclipse.net4j.signal.IndicationWithMonitoring.execute(IndicationWithMonitoring.java:66)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:283)
at org.eclipse.net4j.signal.Signal.run(Signal.java:162)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
I haven't touched any server configuration, I just used the "CDOServer" run configuration that was preinstalled in the workspace. As I said, the unit tests work. I did a git pull on the master branch of the CDO git repo, but I was already up-to-date after Oomph did its job.
Once again, I've hit a wall. If you would be so kind, would you mind downloading my plugin, extracting it to your workspace and give it a shot? No maven this time, just a plain old Eclipse/OSGi plugin project. After importing, it should look like this in the project explorer:
Reproduction Steps:
- Launch the "CDOServer" run configuration, wait for CDO to launch.
- Run the "GrabatsTest" as a regular JUnit test
- Just make sure that your workspace encoding is set to UTF-8, otherwise you might run into issues when the models are loaded by the test (the workspace had the default cp1252 encoding on my machine after installation).
Thanks!
Alan
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:14:05 GMT 2024
Powered by FUDForum. Page generated in 0.05036 seconds
|