Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Alan DW is currently offline Alan DWFriend
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 #1753784 is a reply to message #1753757] Fri, 10 February 2017 08:00 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
There's an client example in the same project: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.examples/src/org/eclipse/emf/cdo/examples/StandaloneContainerExample.java

Newer integration builds contain a special embedded repository, which is not just more convenient, but also more optimal in terms of resource cinsumption and performance. Please have a look at http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.server.embedded/src/org/eclipse/emf/cdo/server/embedded/CDOEmbeddedRepositoryConfig.java . Unfortunately there's no example for it, yet.


Re: CDO: Standalone Setup for programming with the API [message #1753807 is a reply to message #1753784] Fri, 10 February 2017 11:08 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
I've just added an example of the embedded repository usage: http://git.eclipse.org/c/cdo/cdo.git/tree/plugins/org.eclipse.emf.cdo.examples/src/org/eclipse/emf/cdo/examples/embedded

Re: CDO: Standalone Setup for programming with the API [message #1753855 is a reply to message #1753807] Fri, 10 February 2017 17:59 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
Messages: 119
Registered: March 2012
Senior Member
Hello Eike,

thank you for getting back to me and for the example code! I'll try to run this example now.

Best regards,

Alan
Re: CDO: Standalone Setup for programming with the API [message #1753857 is a reply to message #1753855] Fri, 10 February 2017 18:27 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
Messages: 119
Registered: March 2012
Senior Member
Hello,

sorry for the double post, I've run into yet another issue. I tried to compile your examples with both CDO 4.5.0 via maven (see this repository: https://github.com/ghillairet/cdo-maven) as well as by downloading the CDO 4.5. Drop-In-Folder from the official download site and using the contained JAR files, but in both cases the Java compiler tells me that CDOEmbeddedRepositoryConfig does not exist. And indeed, my Eclipse IDE can't find this class in any JAR that I currently have on my machine.

Am I missing something embarassingly trivial? Or is your example targeting a different CDO version than 4.5.0?

Sorry for the trouble.

Alan
Re: CDO: Standalone Setup for programming with the API [message #1753960 is a reply to message #1753857] Mon, 13 February 2017 12:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
You missed my comment about using "Newer integration builds" Wink

Please try http://download.eclipse.org/modeling/emf/cdo/updates/integration ...


Re: CDO: Standalone Setup for programming with the API [message #1754023 is a reply to message #1753960] Mon, 13 February 2017 21:38 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
Messages: 119
Registered: March 2012
Senior Member
Eike Stepper wrote on Mon, 13 February 2017 07:38
You missed my comment about using "Newer integration builds" Wink

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 #1754057 is a reply to message #1754023] Tue, 14 February 2017 08:23 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
I know of a CDO user who's working on a Maven/Tycho build for CDO, which could be a first step towards putting the resulting jars into a Maven repo. But I'm currently not aware of the status of that effort.

Currently the only options I know of are the big per-drop zips that we offer on our downloads page or the p2 repos on that page. Please note that the p2 director can also run as a standalone application: http://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_director.html


Re: CDO: Standalone Setup for programming with the API [message #1754217 is a reply to message #1753857] Wed, 15 February 2017 13:45 Go to previous messageGo to next message
Guillaume Hillairet is currently offline Guillaume HillairetFriend
Messages: 97
Registered: July 2009
Member
My maven build now includes the embedded server, the newly published version is 4.6.0.v20170210-0100. Check the README for more details https://github.com/ghillairet/cdo-maven/blob/master/README.md
Re: CDO: Standalone Setup for programming with the API [message #1754296 is a reply to message #1754217] Thu, 16 February 2017 09:12 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
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 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
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 #1754467 is a reply to message #1754296] Sat, 18 February 2017 07:21 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
You 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?

Re: CDO: Standalone Setup for programming with the API [message #1754469 is a reply to message #1754320] Sat, 18 February 2017 07:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Something 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?

Re: CDO: Standalone Setup for programming with the API [message #1754514 is a reply to message #1754467] Sun, 19 February 2017 10:45 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
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:21
You 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:33
Something 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 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
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 #1754520 is a reply to message #1754517] Sun, 19 February 2017 12:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Your 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?

Re: CDO: Standalone Setup for programming with the API [message #1754527 is a reply to message #1754520] Sun, 19 February 2017 14:04 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
Messages: 119
Registered: March 2012
Senior Member
Hello again!

Eike Stepper wrote on Sun, 19 February 2017 07:17
Your 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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
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.


Re: CDO: Standalone Setup for programming with the API [message #1754633 is a reply to message #1754631] Tue, 21 February 2017 08:38 Go to previous messageGo to next message
Alan DW is currently offline Alan DWFriend
Messages: 119
Registered: March 2012
Senior Member
Hello,

first of all, thanks for your efforts!

Eike Stepper wrote on Tue, 21 February 2017 03: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>




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


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


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 #1754658 is a reply to message #1754633] Tue, 21 February 2017 11:24 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
With the Oomph setup it should not be a big hazzle. Good luck! Wink

Re: CDO: Standalone Setup for programming with the API [message #1754833 is a reply to message #1754658] Wed, 22 February 2017 22:28 Go to previous message
Alan DW is currently offline Alan DWFriend
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:

http://i65.tinypic.com/344sdvo.png

Reproduction Steps:


  1. Launch the "CDOServer" run configuration, wait for CDO to launch.
  2. Run the "GrabatsTest" as a regular JUnit test
  3. 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
Previous Topic:error in opening xmi file
Next Topic:XSD generated switch method exceeds 65k size
Goto Forum:
  


Current Time: Thu Mar 28 14:15:34 GMT 2024

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

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

Back to the top