Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO 0.8M5] Persisting Enums troubles
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #113733 is a reply to message #113706] |
Mon, 03 March 2008 15:03 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
I've fixed the bug and committed to HEAD. If you're using checked out
sources please just update your workspace. If you installed a published
build you have to wait for the next I-build probably on Wednesday or
Thursday.
I hope the fix works for you?
Cheers
/Eike
Matthias schrieb:
> Hello!
>
> I have troubles persisting a eobject that has a attribute of a
> "ItemType" which is in fact an enumeration (EENnum).
>
> When trying to commit, i get the following error on the client:
> STACK 0
> java.lang.ClassCastException:
> at.quorum.octopus.model.topology.ItemType cannot be cast to
> java.lang.String
> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOTypeImpl$19.w riteValue(CDOTypeImpl.java:336)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionIm pl.writeValues(CDORevisionImpl.java:711)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionIm pl.write(CDORevisionImpl.java:155)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeRevisions(CommitTransactionRequest.java:188)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeNewObjects(CommitTransactionRequest.java:151)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:69)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:218)
>
>
>
> and on the server:
> Exception in thread "Thread-6" java.lang.OutOfMemoryError: Java heap
> space
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:72)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
>
> at java.lang.Thread.run(Thread.java:619)
>
>
> Do you have any solution for me?!?
> Matthias
>
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #113806 is a reply to message #113781] |
Tue, 04 March 2008 09:17 |
|
Hi Matthias,
Ouh, it could be that I tested with an existing DB schema. Did you wipe
your DB before testing again?
I'll have the time to look at this again this evening. Apologies for the
inconveniences ;-)
Cheers
/Eike
Matthias wrote:
> Hello Eike!
> I followed your instruction and now the bug is terminated, but I think (at
> looking a little at the changed source) that the mapping code isn't
> working yet...
> I get the following error on the server side:
> Exception in thread "Thread-6" org.eclipse.net4j.util.ImplementationError:
> Unrecognized CDOType: CUSTOM
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMapping(ClassMapping.java:425)
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMappings(ClassMapping.java:356)
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.<init>(ClassMapping.java:78)
> at
>
org.eclipse.emf.cdo.server.internal.db.HorizontalClassMappin g. <init>(HorizontalClassMapping.java:25)
> at
>
org.eclipse.emf.cdo.server.internal.db.HorizontalMappingStra tegy.createClassMapping(HorizontalMappingStrategy.java:114)
> at
>
org.eclipse.emf.cdo.server.internal.db.MappingStrategy.getCl assMapping(MappingStrategy.java:159)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapCl asses(DBStoreAccessor.java:147)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapPa ckages(DBStoreAccessor.java:131)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.writePa ckages(DBStoreWriter.java:82)
> at
>
org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.commit( DBStoreWriter.java:51)
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:180)
> at
>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
> at
>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> And on the client code a TimeOut Exception ;)!
> Best regards,
> Matthias!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #113866 is a reply to message #113813] |
Tue, 04 March 2008 12:42 |
|
Matthias wrote:
> Hey!
> Hmm, no i haven't wiped it out yet, because my *very first* commit in CDO
> is still delayed due the bug! So my database is still empty... ;)!
I see ;-)
> Another question, Eike:
> I have a "root/container" object named "Company", that contains one or
> more "Division". So there will be only one "Company" in the whole
> application context and for all connecting clients. So the client isn't
> able to create a "Company" object for his own, only create "Division" that
> get referenced by the "Company".
> But I have to create the "Company" somewhere and somewhen! Where and when
> should this happen?!? When the very first client connects to the CDO
> server?!? Or on the server side, at the first startup?!?
> What would be the best practice for such an use case?!
It should always be a client that opens a CDOTransaction, and commits
packages and/or instances. Let that be an initial commit or not.
For such initialization work, I suggest that you deploy the CDO client
plugin(s) to the server as well and open a CDOSession via a fast
IJVMConnector.
You can query the existance of a certain resource via
CDOView.hasResource() (inherited by CDOTransaction). Or you can use
CDOTransaction.getOrCreateResource() and test for existance of a certain
root object.
BTW You can listen for the addition of new repositories by registering an
IListener with the used container and check for IContainerEvents.
I hope this helps ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #113880 is a reply to message #113781] |
Tue, 04 March 2008 20:23 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
I think I fixed the bug. My first oversight was due to my focus on the HibernateStore integration. And now I have to admit that I don't have the full resources to test whether this new fix is sufficient to make it because I'm currently working abroad. But I hope that the additional two places where changed the code are all that we need to make it run properly. If not, I'll invite you to drink at EclipseCon ;-) I'd be happy if you tell me if it works...
Cheers
/Eike
Matthias schrieb:
> Hello Eike!
>
> I followed your instruction and now the bug is terminated, but I think
> (at looking a little at the changed source) that the mapping code isn't
> working yet...
>
> I get the following error on the server side:
> Exception in thread "Thread-6"
> org.eclipse.net4j.util.ImplementationError: Unrecognized CDOType: CUSTOM
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMapping(ClassMapping.java:425)
>
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMappings(ClassMapping.java:356)
>
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.<init>(ClassMapping.java:78)
>
> at
> org.eclipse.emf.cdo.server.internal.db.HorizontalClassMappin g. <init>(HorizontalClassMapping.java:25)
>
> at
> org.eclipse.emf.cdo.server.internal.db.HorizontalMappingStra tegy.createClassMapping(HorizontalMappingStrategy.java:114)
>
> at
> org.eclipse.emf.cdo.server.internal.db.MappingStrategy.getCl assMapping(MappingStrategy.java:159)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapCl asses(DBStoreAccessor.java:147)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapPa ckages(DBStoreAccessor.java:131)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.writePa ckages(DBStoreWriter.java:82)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.commit( DBStoreWriter.java:51)
>
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:180)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
>
> at java.lang.Thread.run(Thread.java:619)
>
> And on the client code a TimeOut Exception ;)!
>
> Best regards,
> Matthias!
>
|
|
| | | |
Re: [CDO 0.8M5] Persisting Enums troubles [message #114126 is a reply to message #114055] |
Sat, 08 March 2008 07:05 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
Usually a TransportException with a nested TimeoutException indicates
that the server was not able to send a response, most probably due to an
indication processing error. Did you see an exception in the server log?
That one would be more interesting than the client trace...
Only in case that you can't paste the server exception, I'd need the
whole client log to have a chance in guessing what happened.
Cheers
/Eike
Matthias schrieb:
> Hello Eike!
>
> Ok, thank you for the information!
>
> I followed your instructions and after the first start of my
> application I do the following:
>
> Resource res = trans.getOrCreateResource("/root/company);
>
> if (res.getContents().size() > 0) {
>
> EObject c = res.getContents().get(0);
> if (c != null && c instanceof Company) {
> System.out.println("Company already there");
> }
> } else {
> res.getContents().add(CompanyFactory.getCompany());
> }
> trans.commit();
>
> Everything works fine after the first start! But after the second run
> i get the following exception at the clients side at line "if
> res.getContents().size() ":
>
>
> org.eclipse.emf.cdo.protocol.util.TransportException:
> java.util.concurrent.TimeoutException: Timeout
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.send(CDO RevisionManagerImpl.java:262)
>
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.loadRevi sion(CDORevisionManagerImpl.java:221)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:282)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:144)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:1)
>
> at
> org.eclipse.emf.internal.cdo.CDOViewImpl.getRevision(CDOView Impl.java:287)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine$LoadTransition. execute(CDOStateMachine.java:576)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine$LoadTransition. execute(CDOStateMachine.java:1)
>
> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:161)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.read(CDOStateMa chine.java:179)
>
> at
> org.eclipse.emf.internal.cdo.CDOStore.getRevisionForReading( CDOStore.java:531)
>
> at org.eclipse.emf.internal.cdo.CDOStore.size(CDOStore.java:219 )
> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateSize(CDOObjectImpl.java:757)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.size(DelegatingE List.java:224)
>
> at
> at.quorum.octopus.navi.view.ModelNavigator.initModel(ModelNa vigator.java:67)
>
> at
> at.quorum.octopus.navi.view.ModelNavigator.<init>(ModelNavigator.java:42)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Nativ e
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(Native ConstructorAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De legatingConstructorAccessorImpl.java:27)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:5 13)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at
> org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI .createExecutableExtension(RegistryStrategyOSGI.java:170)
>
> at
> org.eclipse.core.internal.registry.ExtensionRegistry.createE xecutableExtension(ExtensionRegistry.java:863)
>
> at
> org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:243)
>
> at
> org.eclipse.core.internal.registry.ConfigurationElementHandl e.createExecutableExtension(ConfigurationElementHandle.java: 51)
>
> at
> org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:244)
> at
> org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java:240)
>
> at
> org.eclipse.ui.internal.registry.ViewDescriptor.createView(V iewDescriptor.java:71)
>
> at
> org.eclipse.ui.internal.ViewReference.createPartHelper(ViewR eference.java:328)
>
> at
> org.eclipse.ui.internal.ViewReference.createPart(ViewReferen ce.java:230)
> at
> org.eclipse.ui.internal.WorkbenchPartReference.getPart(Workb enchPartReference.java:594)
>
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:30 0)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:53 1)
> at
> org.eclipse.ui.internal.presentations.PresentablePart.setVis ible(PresentablePart.java:180)
>
> at
> org.eclipse.ui.internal.presentations.util.PresentablePartFo lder.select(PresentablePartFolder.java:270)
>
> at
> org.eclipse.ui.internal.presentations.util.LeftToRightTabOrd er.select(LeftToRightTabOrder.java:65)
>
> at
> org.eclipse.ui.internal.presentations.util.TabbedStackPresen tation.selectPart(TabbedStackPresentation.java:473)
>
> at
> org.eclipse.ui.internal.PartStack.refreshPresentationSelecti on(PartStack.java:1256)
>
> at
> org.eclipse.ui.internal.PartStack.setSelection(PartStack.jav a:1209)
> at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:16 08)
> at
> org.eclipse.ui.internal.PartStack.createControl(PartStack.ja va:649)
> at
> org.eclipse.ui.internal.PartStack.createControl(PartStack.ja va:576)
> at
> org.eclipse.ui.internal.PartSashContainer.createControl(Part SashContainer.java:564)
>
> at
> org.eclipse.ui.internal.PerspectiveHelper.activate(Perspecti veHelper.java:270)
>
> at
> org.eclipse.ui.internal.Perspective.onActivate(Perspective.j ava:931)
> at
> org.eclipse.ui.internal.WorkbenchPage.onActivate(WorkbenchPa ge.java:2497)
> at
> org.eclipse.ui.internal.WorkbenchWindow$23.run(WorkbenchWind ow.java:2832)
> at
> org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.internal.WorkbenchWindow.setActivePage(Workbe nchWindow.java:2813)
>
> at
> org.eclipse.ui.internal.WorkbenchWindow.busyOpenPage(Workben chWindow.java:732)
>
> at
> org.eclipse.ui.internal.Workbench$20.runWithException(Workbe nch.java:1031)
>
> at
> org.eclipse.ui.internal.StartupThreading$StartupRunnable.run (StartupThreading.java:31)
>
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:130)
>
> at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3737)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3374)
> at
> org.eclipse.ui.application.WorkbenchAdvisor.openWindows(Work benchAdvisor.java:801)
>
> at
> org.eclipse.ui.internal.Workbench$25.runWithException(Workbe nch.java:1350)
>
> at
> org.eclipse.ui.internal.StartupThreading$StartupRunnable.run (StartupThreading.java:31)
>
> at
> org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.j ava:175)
> at
> org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchroniz er.java:118)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:4183)
> at
> org.eclipse.ui.internal.StartupThreading.runWithoutException s(StartupThreading.java:94)
>
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1345)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2322)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 22)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:474)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:469)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at at.quorum.octopus.rcp.Application.start(Application.java:20)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 564)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1251)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1227)
> Caused by: java.util.concurrent.TimeoutException: Timeout
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:152)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:4 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:29)
>
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.send(CDO RevisionManagerImpl.java:254)
>
> ... 85 more
>
> What am I doing wrong here?!? Do I have to take care about the
> revisioning of CDOObjects?!?
> Best regards,
> Matthias
>
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #114129 is a reply to message #114126] |
Sat, 08 March 2008 16:58 |
Matthias Treitler Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Hey Eike!
Hmm... I do not have the faintest idea what I am doing wrong here!
On the server side everything looks fine... no exception correct, queries
log and so on!
On the client i obtain a session, query if the package registry is empty,
get my resource and the call resource.getContents is doing well. But
querying elements or calling the size from that received collection gives
me a timeout exception as posted before...
Hope you can help me... with that information... I will provide you any
information about my problem if you tell me how and what...
Best regards,
Matthias
PS: I am using HEAD.
Here the server logs:
TCPSelector [debug] Accepting
sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036]
TCPSelector [debug] Accepted socketChannel
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug.lifecycle] Activating
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.connector] Setting state CONNECTING (was disconnected)
for ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.lifecycle] Activating Channel[Control]
TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@40
TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@40
Worker.daemon = false
Worker.activationTimeout = 2000
Worker.deactivationTimeout = 2000
Worker.activationLatch = java.util.concurrent.CountDownLatch@8f2ca6[Count
= 0]
Worker.workerThread = Thread[ReceiveSerializer-1,5,main]
QueueWorker.queue =
QueueWorker.pollMillis = 100
TCPSelector [debug.lifecycle.dump] DUMP ControlChannel@41
Channel.channelID = 0
Channel.channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
Channel.channelIndex = -1
Channel.receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
Channel.receiveHandler = null
Channel.receiveSerializer = ChannelReceiveSerializer@40
Channel.sendQueue =
registrations = SynchronizingCorrelator{}
TCPSelector [debug] Ordering server operation REGISTER
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug] Executing server operation REGISTER
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug] Registering java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.connector] Setting state CONNECTED (was connecting) for
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.lifecycle.dump] DUMP TCPServerConnector@42
Connector.userID = null
Connector.protocolFactoryRegistry =
org.eclipse.net4j.acceptors[tcp]=Factory[org.eclipse.net4j.a cceptors,
tcp]
org.eclipse.net4j.Negotiators[challenge]=Factory[org.eclipse .net4j.Negotiators,
challenge]
org.eclipse.net4j.connectors[tcp]=Factory[org.eclipse.net4j. connectors,
tcp]
org.eclipse.net4j.randomizers[default]=Factory[org.eclipse.n et4j.randomizers,
default]
org.eclipse.net4j.userManagers[file]=Factory[org.eclipse.net 4j.userManagers,
file]
org.eclipse.net4j.executorServices[default]=Factory[org.ecli pse.net4j.executorServices,
default]
org.eclipse.net4j.serverProtocols[cdo]=Factory[org.eclipse.n et4j.serverProtocols,
cdo]
org.eclipse.net4j.selectors[tcp]=Factory[org.eclipse.net4j.s electors,
tcp]
org.eclipse.net4j.bufferProviders[default]=Factory[org.eclip se.net4j.bufferProviders,
default]
Connector.protocolPostProcessors =
org.eclipse.net4j.internal.util.security.ChallengeNegotiator Configurer @12f9ee
org.eclipse.internal.net4j.Net4jTransportInjector@1d6a56e
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@106fc94
Connector.negotiator = null
Connector.negotiationContext = null
Connector.bufferProvider = BufferPool[4.096]
Connector.receiveExecutor =
java.util.concurrent.ThreadPoolExecutor@1d8d39f
Connector.nextChannelID = 1
Connector.channels =
Connector.channelsLock =
org.eclipse.net4j.util.concurrent.RWLock@8b677f[Write locks = 0, Read
locks = 0]
Connector.connectorState = CONNECTED
Connector.channelListener =
org.eclipse.internal.net4j.connector.Connector$1@37d490
Connector.finishedConnecting =
java.util.concurrent.CountDownLatch@1647278[Count = 1]
Connector.finishedNegotiating =
java.util.concurrent.CountDownLatch@1972e3a[Count = 1]
TCPConnector.socketChannel = java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPConnector.selector = TCPSelector
TCPConnector.selectionKey = sun.nio.ch.SelectionKeyImpl@1d840d9
TCPConnector.writeQueue =
TCPConnector.inputBuffer = null
TCPConnector.controlChannel = Channel[Control]
TCPConnector.host = null
TCPConnector.port = 0
acceptor = TCPAcceptor[0.0.0.0:2.036]
TCPSelector [debug.acceptor] Added connector
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Created Buffer@43
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f
TCPSelector [debug.lifecycle] Activating SignalProtocol[cdo]
TCPSelector [debug.lifecycle.dump] DUMP CDOServerProtocol@44
Protocol.channel = Channel[-32.768]
Protocol.bufferProvider = BufferPool[4.096]
Protocol.executorService = java.util.concurrent.ThreadPoolExecutor@1d8d39f
Protocol.infraStructure =
org.eclipse.emf.cdo.internal.server.PluginRepositoryProvider @c792d4
SignalProtocol.streamWrapper = null
SignalProtocol.signals =
SignalProtocol.nextCorrelationID = 1
TCPSelector [debug.connector] Opening channel 0 with protocol cdo
TCPSelector [debug.lifecycle] Activating Channel[0]
TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@45
TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@45
Worker.daemon = false
Worker.activationTimeout = 2000
Worker.deactivationTimeout = 2000
Worker.activationLatch =
java.util.concurrent.CountDownLatch@102a0a5[Count = 0]
Worker.workerThread = Thread[ReceiveSerializer0,5,main]
QueueWorker.queue =
QueueWorker.pollMillis = 100
TCPSelector [debug.lifecycle.dump] DUMP Channel@46
channelID = 1
channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
channelIndex = 0
receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
receiveHandler = SignalProtocol[cdo]
receiveSerializer = ChannelReceiveSerializer@45
sendQueue =
TCPSelector [debug.buffer] Created Buffer@47
TCPSelector [debug.buffer] Obtained Buffer@47
TCPSelector [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[Control]
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug.buffer] Retaining Buffer@43
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 4 bytes
03 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 1
ReceiveSerializer0 [debug.signal] Got signal id 1
Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
Thread-5 [debug.protocol] Read repositoryName: repo1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read disableLegacyObjects: false
Thread-5 [debug.signal] ================ Responding OpenSessionIndication
Thread-5 [debug.session] Opening session 4
Thread-5 [debug.lifecycle] Activating Session[4, Channel[0]]
Thread-5 [debug.lifecycle.dump] DUMP Session@48
sessionManager = SessionManager@8
protocol = SignalProtocol[cdo]
sessionID = 4
disableLegacyObjects = false
views =
protocolListener = org.eclipse.emf.cdo.internal.server.Session$1@b05236
Thread-5 [debug.protocol] Writing sessionID: 4
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.protocol] Writing repositoryUUID:
1ff5d226-b1f0-40fb-aba2-0c31b38c764f
Thread-5 [debug.protocol] Writing package info:
uri=http:///at/quorum/octopus/model/topology.ecore, dynamic=false,
metaIDRange=[MID1:MID102]
Thread-5 [debug.model] Writing CDOID of type 4 (META)
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 117 bytes (EOS)
00 00 00 00 00 00 00 04 01 00 24 31 66 66 35 64 32 32 36 2d 62 31 66 30 2d
34 30 66 62 2d 61 62 61 32 2d 30 63 33 31 62 33 38 63 37 36 34 66 00 01 00
2e 68 74 74 70 3a 2f 2f 2f 61 74 2f 71 75 6f 72 75 6d 2f 6f 63 74 6f 70 75
73 2f 6d 6f 64 65 6c 2f 74 6f 70 6f 6c 6f 67 79 2e 65 63 6f 72 65 00 00 04
00 00 00 00 00 00 00 01 00 00 00 66 00 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 11 bytes (EOS)
00 00 00 02 00 02 00 00 00 01 01
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 2
ReceiveSerializer0 [debug.signal] Got signal id 2
Thread-5 [debug.signal] ================ Indicating ViewsChangedIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.signal] ================ Responding ViewsChangedIndication
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 5 bytes (EOS)
00 00 00 01 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 26 bytes (EOS)
00 00 00 03 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79
00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 3
ReceiveSerializer0 [debug.signal] Got signal id 3
Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read path: /octopus/company
Thread-5 [debug.signal] ================ Responding ResourceIDIndication
Thread-5 [debug.protocol] Writing ID: OID1
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 13 bytes (EOS)
00 00 00 02 01 00 00 00 00 00 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 26 bytes (EOS)
00 00 00 04 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79
00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 4
ReceiveSerializer0 [debug.signal] Got signal id 3
Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read path: /octopus/company
Thread-5 [debug.signal] ================ Responding ResourceIDIndication
Thread-5 [debug.protocol] Writing ID: OID1
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 13 bytes (EOS)
00 00 00 03 01 00 00 00 00 00 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 27 bytes (EOS)
00 00 00 05 00 06 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01 00 00
00 00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 5
ReceiveSerializer0 [debug.signal] Got signal id 6
Thread-5 [debug.signal] ================ Indicating LoadRevisionIndication
Thread-5 [debug.protocol] Read referenceChunk: -1
Thread-5 [debug.protocol] Reading 1 IDs
Thread-5 [debug.model] Reading CDOID of type 1 (OBJECT)
Thread-5 [debug.protocol] Read ID: OID1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.signal] ================ Responding LoadRevisionIndication
Thread-5 [debug.protocol] Writing 1 revisions
Thread-5 [debug.revision] Writing revision: ID=OID1,
classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0, 0),
className=CDOResource, version=1, created=1.204.994.605.537, revised=0,
resource=OID1, container=NULL, feature=0
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.model] Writing CDOID of type 0 (NULL)
Thread-5 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
type=STRING, referenceType=null): /octopus/company
Thread-5 [debug.revision] Writing feature CDOFeature(ID=2, name=contents,
type=OBJECT, referenceType=CDOClass(ID=0, name=CDOObject)): size=1
Thread-5 [debug.revision]
OID3(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
Thread-5 [perf.revision.writing] CDOResource@OID1v1 = 0 millis
Thread-5 [debug.protocol] Writing 0 additional revisions
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 141 bytes (EOS)
00 00 00 04 01 00 2d 68 74 74 70 3a 2f 2f 77 77 77 2e 65 63 6c 69 70 73 65
2e 6f 72 67 2f 65 6d 66 2f 43 44 4f 2f 72 65 73 6f 75 72 63 65 2f 31 2e 30
2e 30 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 01 00 00 01 18 70
46 7e 1e 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00
01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79 00 00 00 00 01 00
00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #114130 is a reply to message #114129] |
Sun, 09 March 2008 06:37 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
I think I got it from the log:
Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
If I exclude a bug in CDO with respect to your effect it is much likely
that you missed to generate your model with CDO support. Have you
followed the descriptions in
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO ?
Cheers
/Eike
Matthias schrieb:
> Hey Eike!
>
> Hmm... I do not have the faintest idea what I am doing wrong here! On
> the server side everything looks fine... no exception correct, queries
> log and so on!
>
> On the client i obtain a session, query if the package registry is
> empty, get my resource and the call resource.getContents is doing
> well. But querying elements or calling the size from that received
> collection gives me a timeout exception as posted before...
> Hope you can help me... with that information... I will provide you
> any information about my problem if you tell me how and what...
>
> Best regards,
> Matthias
>
> PS: I am using HEAD.
>
> Here the server logs:
> TCPSelector [debug] Accepting
> sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036]
> TCPSelector [debug] Accepted socketChannel
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug.lifecycle] Activating
> ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.connector] Setting state CONNECTING (was
> disconnected) for ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.lifecycle] Activating Channel[Control]
> TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@40
> TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@40
> Worker.daemon = false
> Worker.activationTimeout = 2000
> Worker.deactivationTimeout = 2000
> Worker.activationLatch =
> java.util.concurrent.CountDownLatch@8f2ca6[Count = 0]
> Worker.workerThread = Thread[ReceiveSerializer-1,5,main]
> QueueWorker.queue = QueueWorker.pollMillis = 100
>
> TCPSelector [debug.lifecycle.dump] DUMP ControlChannel@41
> Channel.channelID = 0
> Channel.channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
> Channel.channelIndex = -1
> Channel.receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Channel.receiveHandler = null
> Channel.receiveSerializer = ChannelReceiveSerializer@40
> Channel.sendQueue = registrations = SynchronizingCorrelator{}
>
> TCPSelector [debug] Ordering server operation REGISTER
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug] Executing server operation REGISTER
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug] Registering
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug.connector] Setting state CONNECTED (was connecting)
> for ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.lifecycle.dump] DUMP TCPServerConnector@42
> Connector.userID = null
> Connector.protocolFactoryRegistry =
> org.eclipse.net4j.acceptors[tcp]=Factory[org.eclipse.net4j.a cceptors,
> tcp]
>
> org.eclipse.net4j.Negotiators[challenge]=Factory[org.eclipse .net4j.Negotiators,
> challenge]
>
> org.eclipse.net4j.connectors[tcp]=Factory[org.eclipse.net4j. connectors,
> tcp]
>
> org.eclipse.net4j.randomizers[default]=Factory[org.eclipse.n et4j.randomizers,
> default]
>
> org.eclipse.net4j.userManagers[file]=Factory[org.eclipse.net 4j.userManagers,
> file]
>
> org.eclipse.net4j.executorServices[default]=Factory[org.ecli pse.net4j.executorServices,
> default]
>
> org.eclipse.net4j.serverProtocols[cdo]=Factory[org.eclipse.n et4j.serverProtocols,
> cdo]
>
> org.eclipse.net4j.selectors[tcp]=Factory[org.eclipse.net4j.s electors,
> tcp]
>
> org.eclipse.net4j.bufferProviders[default]=Factory[org.eclip se.net4j.bufferProviders,
> default]
> Connector.protocolPostProcessors =
> org.eclipse.net4j.internal.util.security.ChallengeNegotiator Configurer @12f9ee
>
> org.eclipse.internal.net4j.Net4jTransportInjector@1d6a56e
> org.eclipse.net4j.internal.tcp.TCPSelectorInjector@106fc94
> Connector.negotiator = null
> Connector.negotiationContext = null
> Connector.bufferProvider = BufferPool[4.096]
> Connector.receiveExecutor =
> java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Connector.nextChannelID = 1
> Connector.channels = Connector.channelsLock =
> org.eclipse.net4j.util.concurrent.RWLock@8b677f[Write locks = 0, Read
> locks = 0]
> Connector.connectorState = CONNECTED
> Connector.channelListener =
> org.eclipse.internal.net4j.connector.Connector$1@37d490
> Connector.finishedConnecting =
> java.util.concurrent.CountDownLatch@1647278[Count = 1]
> Connector.finishedNegotiating =
> java.util.concurrent.CountDownLatch@1972e3a[Count = 1]
> TCPConnector.socketChannel = java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPConnector.selector = TCPSelector
> TCPConnector.selectionKey = sun.nio.ch.SelectionKeyImpl@1d840d9
> TCPConnector.writeQueue = TCPConnector.inputBuffer = null
> TCPConnector.controlChannel = Channel[Control]
> TCPConnector.host = null
> TCPConnector.port = 0
> acceptor = TCPAcceptor[0.0.0.0:2.036]
>
> TCPSelector [debug.acceptor] Added connector
> ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Created Buffer@43
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 12 bytes
> 02 00 00 00 01 00 00 00 03 63 64 6f TCPSelector [debug.lifecycle]
> Activating SignalProtocol[cdo]
> TCPSelector [debug.lifecycle.dump] DUMP CDOServerProtocol@44
> Protocol.channel = Channel[-32.768]
> Protocol.bufferProvider = BufferPool[4.096]
> Protocol.executorService =
> java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Protocol.infraStructure =
> org.eclipse.emf.cdo.internal.server.PluginRepositoryProvider @c792d4
> SignalProtocol.streamWrapper = null
> SignalProtocol.signals = SignalProtocol.nextCorrelationID = 1
>
> TCPSelector [debug.connector] Opening channel 0 with protocol cdo
> TCPSelector [debug.lifecycle] Activating Channel[0]
> TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@45
> TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@45
> Worker.daemon = false
> Worker.activationTimeout = 2000
> Worker.deactivationTimeout = 2000
> Worker.activationLatch =
> java.util.concurrent.CountDownLatch@102a0a5[Count = 0]
> Worker.workerThread = Thread[ReceiveSerializer0,5,main]
> QueueWorker.queue = QueueWorker.pollMillis = 100
>
> TCPSelector [debug.lifecycle.dump] DUMP Channel@46
> channelID = 1
> channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
> channelIndex = 0
> receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
> receiveHandler = SignalProtocol[cdo]
> receiveSerializer = ChannelReceiveSerializer@45
> sendQueue =
> TCPSelector [debug.buffer] Created Buffer@47
> TCPSelector [debug.buffer] Obtained Buffer@47
> TCPSelector [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[Control]
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug.buffer] Retaining Buffer@43
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 4 bytes
> 03 00 00 01 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 16 bytes (EOS)
> 00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00 TCPSelector
> [debug.channel] Handling buffer from multiplexer: Buffer@43 -->
> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 1
> ReceiveSerializer0 [debug.signal] Got signal id 1
> Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
> Thread-5 [debug.protocol] Read repositoryName: repo1
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read disableLegacyObjects: false
> Thread-5 [debug.signal] ================ Responding OpenSessionIndication
> Thread-5 [debug.session] Opening session 4
> Thread-5 [debug.lifecycle] Activating Session[4, Channel[0]]
> Thread-5 [debug.lifecycle.dump] DUMP Session@48
> sessionManager = SessionManager@8
> protocol = SignalProtocol[cdo]
> sessionID = 4
> disableLegacyObjects = false
> views = protocolListener =
> org.eclipse.emf.cdo.internal.server.Session$1@b05236
>
> Thread-5 [debug.protocol] Writing sessionID: 4
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.protocol] Writing repositoryUUID:
> 1ff5d226-b1f0-40fb-aba2-0c31b38c764f
> Thread-5 [debug.protocol] Writing package info:
> uri=http:///at/quorum/octopus/model/topology.ecore, dynamic=false,
> metaIDRange=[MID1:MID102]
> Thread-5 [debug.model] Writing CDOID of type 4 (META)
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 117 bytes (EOS)
> 00 00 00 00 00 00 00 04 01 00 24 31 66 66 35 64 32 32 36 2d 62 31 66
> 30 2d 34 30 66 62 2d 61 62 61 32 2d 30 63 33 31 62 33 38 63 37 36 34
> 66 00 01 00 2e 68 74 74 70 3a 2f 2f 2f 61 74 2f 71 75 6f 72 75 6d 2f
> 6f 63 74 6f 70 75 73 2f 6d 6f 64 65 6c 2f 74 6f 70 6f 6c 6f 67 79 2e
> 65 63 6f 72 65 00 00 04 00 00 00 00 00 00 00 01 00 00 00 66 00 00 00
> 00 00 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 11 bytes (EOS)
> 00 00 00 02 00 02 00 00 00 01 01 TCPSelector [debug.channel] Handling
> buffer from multiplexer: Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 2
> ReceiveSerializer0 [debug.signal] Got signal id 2
> Thread-5 [debug.signal] ================ Indicating
> ViewsChangedIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.signal] ================ Responding
> ViewsChangedIndication
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 5 bytes (EOS)
> 00 00 00 01 01 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 26 bytes (EOS)
> 00 00 00 03 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61
> 6e 79 00 TCPSelector [debug.channel] Handling buffer from multiplexer:
> Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 3
> ReceiveSerializer0 [debug.signal] Got signal id 3
> Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read path: /octopus/company
> Thread-5 [debug.signal] ================ Responding ResourceIDIndication
> Thread-5 [debug.protocol] Writing ID: OID1
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 13 bytes (EOS)
> 00 00 00 02 01 00 00 00 00 00 00 00 01 TCPSelector [debug.buffer]
> Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 26 bytes (EOS)
> 00 00 00 04 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61
> 6e 79 00 TCPSelector [debug.channel] Handling buffer from multiplexer:
> Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 4
> ReceiveSerializer0 [debug.signal] Got signal id 3
> Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read path: /octopus/company
> Thread-5 [debug.signal] ================ Responding ResourceIDIndication
> Thread-5 [debug.protocol] Writing ID: OID1
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 13 bytes (EOS)
> 00 00 00 03 01 00 00 00 00 00 00 00 01 TCPSelector [debug.buffer]
> Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 27 bytes (EOS)
> 00 00 00 05 00 06 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01
> 00 00 00 00 TCPSelector [debug.channel] Handling buffer from
> multiplexer: Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 5
> ReceiveSerializer0 [debug.signal] Got signal id 6
> Thread-5 [debug.signal] ================ Indicating
> LoadRevisionIndication
> Thread-5 [debug.protocol] Read referenceChunk: -1
> Thread-5 [debug.protocol] Reading 1 IDs
> Thread-5 [debug.model] Reading CDOID of type 1 (OBJECT)
> Thread-5 [debug.protocol] Read ID: OID1
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.signal] ================ Responding
> LoadRevisionIndication
> Thread-5 [debug.protocol] Writing 1 revisions
> Thread-5 [debug.revision] Writing revision: ID=OID1,
> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
> 0), className=CDOResource, version=1, created=1.204.994.605.537,
> revised=0, resource=OID1, container=NULL, feature=0
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.model] Writing CDOID of type 0 (NULL)
> Thread-5 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
> type=STRING, referenceType=null): /octopus/company
> Thread-5 [debug.revision] Writing feature CDOFeature(ID=2,
> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
> name=CDOObject)): size=1
> Thread-5 [debug.revision]
> OID3(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
> Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
> Thread-5 [perf.revision.writing] CDOResource@OID1v1 = 0 millis
> Thread-5 [debug.protocol] Writing 0 additional revisions
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 141 bytes (EOS)
> 00 00 00 04 01 00 2d 68 74 74 70 3a 2f 2f 77 77 77 2e 65 63 6c 69 70
> 73 65 2e 6f 72 67 2f 65 6d 66 2f 43 44 4f 2f 72 65 73 6f 75 72 63 65
> 2f 31 2e 30 2e 30 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
> 01 00 00 01 18 70 46 7e 1e 00 00 00 00 00 00 00 00 01 00 00 00 00 00
> 00 00 01 00 00 00 00 00 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d
> 70 61 6e 79 00 00 00 00 01 00 00 00 00 02 00 00 00 00 00 00 00 03 00
> 00 00 00 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
>
>
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #114246 is a reply to message #114130] |
Sun, 09 March 2008 13:33 |
Matthias Treitler Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Hi!
Thank you for your answer! But I have converted my model to be CDO
compliant and I do not detect any differences between your tests provided
in the CVS and my implementation!
Maybe I have to run CDO Weaver?!? I already tried to convert all my
detected bundles but I always get the following exception:
Weaving 1 bundles
null
java.lang.NullPointerException
at
org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
at org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
at
org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
at
org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
!
So you think this line indicates that might cause the error:
Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
type=STRING, referenceType=null): /octopus/company
Thread-6 [debug.revision] Writing feature CDOFeature(ID=2, name=contents,
type=OBJECT, referenceType=CDOClass(ID=0, name=CDOObject)): size=1
Thread-6 [debug.revision]
OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
Why does the server "think" that I have legacy objects?!? What does it
mean?
Best regards,
Matthias
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #114260 is a reply to message #114246] |
Sun, 09 March 2008 17:15 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
Comments below...
Matthias schrieb:
> Hi!
>
> Thank you for your answer! But I have converted my model to be CDO
> compliant and I do not detect any differences between your tests
> provided in the CVS and my implementation!
>
> Maybe I have to run CDO Weaver?!?
No, no! Don't use the weaver if you intend to use models that you
generated for CDO!
The weaver is needed to turn on the CDO legacy system and to convert
legacy models for usage with CDO at runtime.
You don't want to do that with your own models.
> I already tried to convert all my detected bundles but I always get
> the following exception:
> Weaving 1 bundles
> null
> java.lang.NullPointerException
> at
> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
>
> at
> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
> at
> org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
>
> at
> org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
>
Apart from the fact that you don't want to use the weaver, I will look
into this issue later...
> So you think this line indicates that might cause the error:
>
> Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
> type=STRING, referenceType=null): /octopus/company
> Thread-6 [debug.revision] Writing feature CDOFeature(ID=2,
> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
> name=CDOObject)): size=1
> Thread-6 [debug.revision]
> OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
> Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
>
> Why does the server "think" that I have legacy objects?!? What does it
> mean?
In fact that can indicate one of the following:
1) You actually have legacy objects (in case you didn't generate
CDOObjectImpls)
2) You just configured the client CDOSession to support legacy objects.
How did you open the session? There's a utility class:
CDOUtil.openSession(..., boolean disableLegacyObjects);
You should call it with disableLegacyObjects==true. If you create the
session differently you should call setDisableLegacyObjects(true) before
activating the session object.
After activating the session the value can't be changed anymore. At any
time it can bequeried: CDOSession.isDisableLegacyObjects()
Have you tried to use your model with the UI that comes with CDO? Does
it work there?
Cheers
/Eike
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #114272 is a reply to message #114260] |
Sun, 09 March 2008 17:26 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------010600010607000800050407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Matthias,
I just saw the following in your log:
Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
Thread-5 [debug.protocol] Read repositoryName: repo1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] *Read disableLegacyObjects: false *
So it's pretty clear how the problem can be fixed: Open your session
with disableLegacyObjects=true
Background: Usually it's only a performance and a resource penalty
incured when you open a session with legacy system support but it should
not fail. Due to our efforts to integrate Hibernate at the server side
the whole legacy system is temporarily broken. This is not that nice but
I currently know of nobody actually using the legacy system.
Btw. for more convenience I've already added two features to preserve
accidental use of the legacy system:
1) Opening a session with legacy support throws an exception if the
legacy system is not available
2) Attaching legacy objects to a session w/o legacy support throws an
exception
Both changes are committed and are contained in todays builds.
Cheers
/Eike
Eike Stepper schrieb:
> Hi Matthias,
>
> Comments below...
>
>
>
> Matthias schrieb:
>> Hi!
>>
>> Thank you for your answer! But I have converted my model to be CDO
>> compliant and I do not detect any differences between your tests
>> provided in the CVS and my implementation!
>>
>> Maybe I have to run CDO Weaver?!?
> No, no! Don't use the weaver if you intend to use models that you
> generated for CDO!
> The weaver is needed to turn on the CDO legacy system and to convert
> legacy models for usage with CDO at runtime.
> You don't want to do that with your own models.
>
>> I already tried to convert all my detected bundles but I always get
>> the following exception:
>> Weaving 1 bundles
>> null
>> java.lang.NullPointerException
>> at
>> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
>>
>> at
>> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
>> at
>> org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
>>
>> at
>> org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
>>
> Apart from the fact that you don't want to use the weaver, I will look
> into this issue later...
>
>> So you think this line indicates that might cause the error:
>>
>> Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
>> type=STRING, referenceType=null): /octopus/company
>> Thread-6 [debug.revision] Writing feature CDOFeature(ID=2,
>> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
>> name=CDOObject)): size=1
>> Thread-6 [debug.revision]
>> OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
>> Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
>>
>> Why does the server "think" that I have legacy objects?!? What does
>> it mean?
> In fact that can indicate one of the following:
> 1) You actually have legacy objects (in case you didn't generate
> CDOObjectImpls)
> 2) You just configured the client CDOSession to support legacy objects.
>
> How did you open the session? There's a utility class:
> CDOUtil.openSession(..., boolean disableLegacyObjects);
>
> You should call it with disableLegacyObjects==true. If you create the
> session differently you should call setDisableLegacyObjects(true)
> before activating the session object.
> After activating the session the value can't be changed anymore. At
> any time it can bequeried: CDOSession.isDisableLegacyObjects()
>
>
> Have you tried to use your model with the UI that comes with CDO? Does
> it work there?
>
> Cheers
> /Eike
--------------010600010607000800050407
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Matthias,<br>
<br>
I just saw the following in your log:<br>
<br>
Thread-5 [debug.signal] ================ Indicating
OpenSessionIndication
<br>
Thread-5 [debug.protocol] Read repositoryName: repo1
<br>
Thread-5 [debug.buffer] Retaining Buffer@43
<br>
Thread-5 [debug.protocol] <b>Read disableLegacyObjects: false
</b><br>
<br>
So it's pretty clear how the problem can be fixed: Open your session
with disableLegacyObjects=true<br>
<br>
Background: Usually it's only a performance and a resource penalty
incured when you open a session with legacy system support but it
should not fail. Due to our efforts to integrate Hibernate at the
server side the whole legacy system is temporarily broken. This is not
that nice but I currently know of nobody actually using the legacy
system.<br>
<br>
Btw. for more convenience I've already added two features to preserve
accidental use of the legacy system:<br>
1) Opening a session with legacy support throws an exception if the
legacy system is not available<br>
2) Attaching legacy objects to a session w/o legacy support throws an
exception<br>
<br>
Both changes are committed and are contained in todays builds.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fr15vs$9vf$1@build.eclipse.org" type="cite">Hi
Matthias,
<br>
<br>
Comments below...
<br>
<br>
<br>
<br>
Matthias schrieb:
<br>
<blockquote type="cite">Hi!
<br>
<br>
Thank you for your answer! But I have converted my model to be CDO
compliant and I do not detect any differences between your tests
provided in the CVS and my implementation!
<br>
<br>
Maybe I have to run CDO Weaver?!? </blockquote>
No, no! Don't use the weaver if you intend to use models that you
generated for CDO!
<br>
The weaver is needed to turn on the CDO legacy system and to convert
legacy models for usage with CDO at runtime.
<br>
You don't want to do that with your own models.
<br>
<br>
<blockquote type="cite">I already tried to convert all my detected
bundles but I always get the following exception:
<br>
Weaving 1 bundles
<br>
null
<br>
java.lang.NullPointerException
<br>
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #114310 is a reply to message #114285] |
Sun, 09 March 2008 20:01 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Matthias schrieb:
> Hey Eike!
>
> Thank your for your (detailed) answer! Yes, this flag made me a lot of
> headcache ;) but now everything works fine... thanks
Good to hear.
The current default to support legacy objects is historical left-over.
If you feel that the legacy support should be off by default, please
file a Bugzilla.
Enjoy the rest of your weekend ;-)
/Eike
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #114580 is a reply to message #114502] |
Wed, 12 March 2008 19:07 |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Matthias,
Sorry, my fault again. I converted the enum to String after the delta of the modification was calculated. I fixed that in HEAD and added test code.
Cheers
/Eike
Matthias schrieb:
> Hey Eike!
>
> I have deleted my existing Derby DB for my project and restarted the
> shipped CDO server on CVS.
>
> I started my own project and when inserting data or modifying data to
> the model repository I get the following exception:
>
> java.lang.ClassCastException: at.quorum.octopus.model.topology.ItemType
> cannot be cast to java.lang.String
> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOTypeImpl$20.w riteValue(CDOTypeImpl.java:338)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.delta.CDOSing leValueFeatureDeltaImpl.write(CDOSingleValueFeatureDeltaImpl .java:71)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.delta.CDORevi sionDeltaImpl.write(CDORevisionDeltaImpl.java:111)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:103)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:236)
>
>
>
> Its a kind of weird because it worked for me after you fixed that bug as
> posted previously... even on updating model entities :)
>
> This exception is only thrown when updating a model entity not creating
> one... (as I can remember)
>
> Best regards,
> Matthias
>
>
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #615597 is a reply to message #113706] |
Mon, 03 March 2008 15:03 |
|
Hi Matthias,
I've fixed the bug and committed to HEAD. If you're using checked out
sources please just update your workspace. If you installed a published
build you have to wait for the next I-build probably on Wednesday or
Thursday.
I hope the fix works for you?
Cheers
/Eike
Matthias schrieb:
> Hello!
>
> I have troubles persisting a eobject that has a attribute of a
> "ItemType" which is in fact an enumeration (EENnum).
>
> When trying to commit, i get the following error on the client:
> STACK 0
> java.lang.ClassCastException:
> at.quorum.octopus.model.topology.ItemType cannot be cast to
> java.lang.String
> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOTypeImpl$19.w riteValue(CDOTypeImpl.java:336)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionIm pl.writeValues(CDORevisionImpl.java:711)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionIm pl.write(CDORevisionImpl.java:155)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeRevisions(CommitTransactionRequest.java:188)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.writeNewObjects(CommitTransactionRequest.java:151)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:69)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:218)
>
>
>
> and on the server:
> Exception in thread "Thread-6" java.lang.OutOfMemoryError: Java heap
> space
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:72)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
>
> at java.lang.Thread.run(Thread.java:619)
>
>
> Do you have any solution for me?!?
> Matthias
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #615603 is a reply to message #113781] |
Tue, 04 March 2008 09:17 |
|
Hi Matthias,
Ouh, it could be that I tested with an existing DB schema. Did you wipe
your DB before testing again?
I'll have the time to look at this again this evening. Apologies for the
inconveniences ;-)
Cheers
/Eike
Matthias wrote:
> Hello Eike!
> I followed your instruction and now the bug is terminated, but I think (at
> looking a little at the changed source) that the mapping code isn't
> working yet...
> I get the following error on the server side:
> Exception in thread "Thread-6" org.eclipse.net4j.util.ImplementationError:
> Unrecognized CDOType: CUSTOM
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMapping(ClassMapping.java:425)
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMappings(ClassMapping.java:356)
> at
>
org.eclipse.emf.cdo.server.internal.db.ClassMapping.<init>(ClassMapping.java:78)
> at
>
org.eclipse.emf.cdo.server.internal.db.HorizontalClassMappin g. <init>(HorizontalClassMapping.java:25)
> at
>
org.eclipse.emf.cdo.server.internal.db.HorizontalMappingStra tegy.createClassMapping(HorizontalMappingStrategy.java:114)
> at
>
org.eclipse.emf.cdo.server.internal.db.MappingStrategy.getCl assMapping(MappingStrategy.java:159)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapCl asses(DBStoreAccessor.java:147)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapPa ckages(DBStoreAccessor.java:131)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.writePa ckages(DBStoreWriter.java:82)
> at
>
org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
> at
>
org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.commit( DBStoreWriter.java:51)
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:180)
> at
>
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
> at
>
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
> at
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
> at java.lang.Thread.run(Thread.java:619)
> And on the client code a TimeOut Exception ;)!
> Best regards,
> Matthias!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO 0.8M5] Persisting Enums troubles [message #615607 is a reply to message #113813] |
Tue, 04 March 2008 12:42 |
|
Matthias wrote:
> Hey!
> Hmm, no i haven't wiped it out yet, because my *very first* commit in CDO
> is still delayed due the bug! So my database is still empty... ;)!
I see ;-)
> Another question, Eike:
> I have a "root/container" object named "Company", that contains one or
> more "Division". So there will be only one "Company" in the whole
> application context and for all connecting clients. So the client isn't
> able to create a "Company" object for his own, only create "Division" that
> get referenced by the "Company".
> But I have to create the "Company" somewhere and somewhen! Where and when
> should this happen?!? When the very first client connects to the CDO
> server?!? Or on the server side, at the first startup?!?
> What would be the best practice for such an use case?!
It should always be a client that opens a CDOTransaction, and commits
packages and/or instances. Let that be an initial commit or not.
For such initialization work, I suggest that you deploy the CDO client
plugin(s) to the server as well and open a CDOSession via a fast
IJVMConnector.
You can query the existance of a certain resource via
CDOView.hasResource() (inherited by CDOTransaction). Or you can use
CDOTransaction.getOrCreateResource() and test for existance of a certain
root object.
BTW You can listen for the addition of new repositories by registering an
IListener with the used container and check for IContainerEvents.
I hope this helps ;-)
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615608 is a reply to message #113781] |
Tue, 04 March 2008 20:23 |
|
Hi Matthias,
I think I fixed the bug. My first oversight was due to my focus on the HibernateStore integration. And now I have to admit that I don't have the full resources to test whether this new fix is sufficient to make it because I'm currently working abroad. But I hope that the additional two places where changed the code are all that we need to make it run properly. If not, I'll invite you to drink at EclipseCon ;-) I'd be happy if you tell me if it works...
Cheers
/Eike
Matthias schrieb:
> Hello Eike!
>
> I followed your instruction and now the bug is terminated, but I think
> (at looking a little at the changed source) that the mapping code isn't
> working yet...
>
> I get the following error on the server side:
> Exception in thread "Thread-6"
> org.eclipse.net4j.util.ImplementationError: Unrecognized CDOType: CUSTOM
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMapping(ClassMapping.java:425)
>
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.createAt tributeMappings(ClassMapping.java:356)
>
> at
> org.eclipse.emf.cdo.server.internal.db.ClassMapping.<init>(ClassMapping.java:78)
>
> at
> org.eclipse.emf.cdo.server.internal.db.HorizontalClassMappin g. <init>(HorizontalClassMapping.java:25)
>
> at
> org.eclipse.emf.cdo.server.internal.db.HorizontalMappingStra tegy.createClassMapping(HorizontalMappingStrategy.java:114)
>
> at
> org.eclipse.emf.cdo.server.internal.db.MappingStrategy.getCl assMapping(MappingStrategy.java:159)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapCl asses(DBStoreAccessor.java:147)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.mapPa ckages(DBStoreAccessor.java:131)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.writePa ckages(DBStoreWriter.java:82)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
>
> at
> org.eclipse.emf.cdo.server.internal.db.DBStoreWriter.commit( DBStoreWriter.java:51)
>
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:180)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
>
> at java.lang.Thread.run(Thread.java:619)
>
> And on the client code a TimeOut Exception ;)!
>
> Best regards,
> Matthias!
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Re: [CDO 0.8M5] Persisting Enums troubles [message #615636 is a reply to message #114055] |
Sat, 08 March 2008 07:05 |
|
Hi Matthias,
Usually a TransportException with a nested TimeoutException indicates
that the server was not able to send a response, most probably due to an
indication processing error. Did you see an exception in the server log?
That one would be more interesting than the client trace...
Only in case that you can't paste the server exception, I'd need the
whole client log to have a chance in guessing what happened.
Cheers
/Eike
Matthias schrieb:
> Hello Eike!
>
> Ok, thank you for the information!
>
> I followed your instructions and after the first start of my
> application I do the following:
>
> Resource res = trans.getOrCreateResource("/root/company);
>
> if (res.getContents().size() > 0) {
>
> EObject c = res.getContents().get(0);
> if (c != null && c instanceof Company) {
> System.out.println("Company already there");
> }
> } else {
> res.getContents().add(CompanyFactory.getCompany());
> }
> trans.commit();
>
> Everything works fine after the first start! But after the second run
> i get the following exception at the clients side at line "if
> res.getContents().size() ":
>
>
> org.eclipse.emf.cdo.protocol.util.TransportException:
> java.util.concurrent.TimeoutException: Timeout
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.send(CDO RevisionManagerImpl.java:262)
>
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.loadRevi sion(CDORevisionManagerImpl.java:221)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:282)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:144)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.CDORevisionRe solverImpl.getRevision(CDORevisionResolverImpl.java:1)
>
> at
> org.eclipse.emf.internal.cdo.CDOViewImpl.getRevision(CDOView Impl.java:287)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine$LoadTransition. execute(CDOStateMachine.java:576)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine$LoadTransition. execute(CDOStateMachine.java:1)
>
> at
> org.eclipse.net4j.util.fsm.FiniteStateMachine.process(Finite StateMachine.java:161)
>
> at
> org.eclipse.emf.internal.cdo.CDOStateMachine.read(CDOStateMa chine.java:179)
>
> at
> org.eclipse.emf.internal.cdo.CDOStore.getRevisionForReading( CDOStore.java:531)
>
> at org.eclipse.emf.internal.cdo.CDOStore.size(CDOStore.java:219 )
> at
> org.eclipse.emf.internal.cdo.CDOObjectImpl$CDOStoreEList.del egateSize(CDOObjectImpl.java:757)
>
> at
> org.eclipse.emf.common.util.DelegatingEList.size(DelegatingE List.java:224)
>
> at
> at.quorum.octopus.navi.view.ModelNavigator.initModel(ModelNa vigator.java:67)
>
> at
> at.quorum.octopus.navi.view.ModelNavigator.<init>(ModelNavigator.java:42)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Nativ e
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(Native ConstructorAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De legatingConstructorAccessorImpl.java:27)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:5 13)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at
> org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI .createExecutableExtension(RegistryStrategyOSGI.java:170)
>
> at
> org.eclipse.core.internal.registry.ExtensionRegistry.createE xecutableExtension(ExtensionRegistry.java:863)
>
> at
> org.eclipse.core.internal.registry.ConfigurationElement.crea teExecutableExtension(ConfigurationElement.java:243)
>
> at
> org.eclipse.core.internal.registry.ConfigurationElementHandl e.createExecutableExtension(ConfigurationElementHandle.java: 51)
>
> at
> org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugi n.java:244)
> at
> org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.internal.WorkbenchPlugin.createExtension(Work benchPlugin.java:240)
>
> at
> org.eclipse.ui.internal.registry.ViewDescriptor.createView(V iewDescriptor.java:71)
>
> at
> org.eclipse.ui.internal.ViewReference.createPartHelper(ViewR eference.java:328)
>
> at
> org.eclipse.ui.internal.ViewReference.createPart(ViewReferen ce.java:230)
> at
> org.eclipse.ui.internal.WorkbenchPartReference.getPart(Workb enchPartReference.java:594)
>
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:30 0)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:53 1)
> at
> org.eclipse.ui.internal.presentations.PresentablePart.setVis ible(PresentablePart.java:180)
>
> at
> org.eclipse.ui.internal.presentations.util.PresentablePartFo lder.select(PresentablePartFolder.java:270)
>
> at
> org.eclipse.ui.internal.presentations.util.LeftToRightTabOrd er.select(LeftToRightTabOrder.java:65)
>
> at
> org.eclipse.ui.internal.presentations.util.TabbedStackPresen tation.selectPart(TabbedStackPresentation.java:473)
>
> at
> org.eclipse.ui.internal.PartStack.refreshPresentationSelecti on(PartStack.java:1256)
>
> at
> org.eclipse.ui.internal.PartStack.setSelection(PartStack.jav a:1209)
> at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:16 08)
> at
> org.eclipse.ui.internal.PartStack.createControl(PartStack.ja va:649)
> at
> org.eclipse.ui.internal.PartStack.createControl(PartStack.ja va:576)
> at
> org.eclipse.ui.internal.PartSashContainer.createControl(Part SashContainer.java:564)
>
> at
> org.eclipse.ui.internal.PerspectiveHelper.activate(Perspecti veHelper.java:270)
>
> at
> org.eclipse.ui.internal.Perspective.onActivate(Perspective.j ava:931)
> at
> org.eclipse.ui.internal.WorkbenchPage.onActivate(WorkbenchPa ge.java:2497)
> at
> org.eclipse.ui.internal.WorkbenchWindow$23.run(WorkbenchWind ow.java:2832)
> at
> org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.internal.WorkbenchWindow.setActivePage(Workbe nchWindow.java:2813)
>
> at
> org.eclipse.ui.internal.WorkbenchWindow.busyOpenPage(Workben chWindow.java:732)
>
> at
> org.eclipse.ui.internal.Workbench$20.runWithException(Workbe nch.java:1031)
>
> at
> org.eclipse.ui.internal.StartupThreading$StartupRunnable.run (StartupThreading.java:31)
>
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:130)
>
> at
> org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3737)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3374)
> at
> org.eclipse.ui.application.WorkbenchAdvisor.openWindows(Work benchAdvisor.java:801)
>
> at
> org.eclipse.ui.internal.Workbench$25.runWithException(Workbe nch.java:1350)
>
> at
> org.eclipse.ui.internal.StartupThreading$StartupRunnable.run (StartupThreading.java:31)
>
> at
> org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.j ava:175)
> at
> org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchroniz er.java:118)
> at org.eclipse.swt.widgets.Display.syncExec(Display.java:4183)
> at
> org.eclipse.ui.internal.StartupThreading.runWithoutException s(StartupThreading.java:94)
>
> at org.eclipse.ui.internal.Workbench.init(Workbench.java:1345)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2322)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 22)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:474)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:288)
>
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:469)
>
> at
> org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at at.quorum.octopus.rcp.Application.start(Application.java:20)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:193)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:362)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:175)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 564)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1251)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1227)
> Caused by: java.util.concurrent.TimeoutException: Timeout
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:152)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:4 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:29)
>
> at
> org.eclipse.emf.internal.cdo.CDORevisionManagerImpl.send(CDO RevisionManagerImpl.java:254)
>
> ... 85 more
>
> What am I doing wrong here?!? Do I have to take care about the
> revisioning of CDOObjects?!?
> Best regards,
> Matthias
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615639 is a reply to message #114126] |
Sat, 08 March 2008 16:58 |
Matthias Treitler Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Hey Eike!
Hmm... I do not have the faintest idea what I am doing wrong here!
On the server side everything looks fine... no exception correct, queries
log and so on!
On the client i obtain a session, query if the package registry is empty,
get my resource and the call resource.getContents is doing well. But
querying elements or calling the size from that received collection gives
me a timeout exception as posted before...
Hope you can help me... with that information... I will provide you any
information about my problem if you tell me how and what...
Best regards,
Matthias
PS: I am using HEAD.
Here the server logs:
TCPSelector [debug] Accepting
sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036]
TCPSelector [debug] Accepted socketChannel
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug.lifecycle] Activating
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.connector] Setting state CONNECTING (was disconnected)
for ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.lifecycle] Activating Channel[Control]
TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@40
TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@40
Worker.daemon = false
Worker.activationTimeout = 2000
Worker.deactivationTimeout = 2000
Worker.activationLatch = java.util.concurrent.CountDownLatch@8f2ca6[Count
= 0]
Worker.workerThread = Thread[ReceiveSerializer-1,5,main]
QueueWorker.queue =
QueueWorker.pollMillis = 100
TCPSelector [debug.lifecycle.dump] DUMP ControlChannel@41
Channel.channelID = 0
Channel.channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
Channel.channelIndex = -1
Channel.receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
Channel.receiveHandler = null
Channel.receiveSerializer = ChannelReceiveSerializer@40
Channel.sendQueue =
registrations = SynchronizingCorrelator{}
TCPSelector [debug] Ordering server operation REGISTER
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug] Executing server operation REGISTER
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338]
TCPSelector [debug] Registering java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.connector] Setting state CONNECTED (was connecting) for
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug.lifecycle.dump] DUMP TCPServerConnector@42
Connector.userID = null
Connector.protocolFactoryRegistry =
org.eclipse.net4j.acceptors[tcp]=Factory[org.eclipse.net4j.a cceptors,
tcp]
org.eclipse.net4j.Negotiators[challenge]=Factory[org.eclipse .net4j.Negotiators,
challenge]
org.eclipse.net4j.connectors[tcp]=Factory[org.eclipse.net4j. connectors,
tcp]
org.eclipse.net4j.randomizers[default]=Factory[org.eclipse.n et4j.randomizers,
default]
org.eclipse.net4j.userManagers[file]=Factory[org.eclipse.net 4j.userManagers,
file]
org.eclipse.net4j.executorServices[default]=Factory[org.ecli pse.net4j.executorServices,
default]
org.eclipse.net4j.serverProtocols[cdo]=Factory[org.eclipse.n et4j.serverProtocols,
cdo]
org.eclipse.net4j.selectors[tcp]=Factory[org.eclipse.net4j.s electors,
tcp]
org.eclipse.net4j.bufferProviders[default]=Factory[org.eclip se.net4j.bufferProviders,
default]
Connector.protocolPostProcessors =
org.eclipse.net4j.internal.util.security.ChallengeNegotiator Configurer @12f9ee
org.eclipse.internal.net4j.Net4jTransportInjector@1d6a56e
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@106fc94
Connector.negotiator = null
Connector.negotiationContext = null
Connector.bufferProvider = BufferPool[4.096]
Connector.receiveExecutor =
java.util.concurrent.ThreadPoolExecutor@1d8d39f
Connector.nextChannelID = 1
Connector.channels =
Connector.channelsLock =
org.eclipse.net4j.util.concurrent.RWLock@8b677f[Write locks = 0, Read
locks = 0]
Connector.connectorState = CONNECTED
Connector.channelListener =
org.eclipse.internal.net4j.connector.Connector$1@37d490
Connector.finishedConnecting =
java.util.concurrent.CountDownLatch@1647278[Count = 1]
Connector.finishedNegotiating =
java.util.concurrent.CountDownLatch@1972e3a[Count = 1]
TCPConnector.socketChannel = java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPConnector.selector = TCPSelector
TCPConnector.selectionKey = sun.nio.ch.SelectionKeyImpl@1d840d9
TCPConnector.writeQueue =
TCPConnector.inputBuffer = null
TCPConnector.controlChannel = Channel[Control]
TCPConnector.host = null
TCPConnector.port = 0
acceptor = TCPAcceptor[0.0.0.0:2.036]
TCPSelector [debug.acceptor] Added connector
ServerTCPConnector[127.0.0.1:1.338]
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Created Buffer@43
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f
TCPSelector [debug.lifecycle] Activating SignalProtocol[cdo]
TCPSelector [debug.lifecycle.dump] DUMP CDOServerProtocol@44
Protocol.channel = Channel[-32.768]
Protocol.bufferProvider = BufferPool[4.096]
Protocol.executorService = java.util.concurrent.ThreadPoolExecutor@1d8d39f
Protocol.infraStructure =
org.eclipse.emf.cdo.internal.server.PluginRepositoryProvider @c792d4
SignalProtocol.streamWrapper = null
SignalProtocol.signals =
SignalProtocol.nextCorrelationID = 1
TCPSelector [debug.connector] Opening channel 0 with protocol cdo
TCPSelector [debug.lifecycle] Activating Channel[0]
TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@45
TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@45
Worker.daemon = false
Worker.activationTimeout = 2000
Worker.deactivationTimeout = 2000
Worker.activationLatch =
java.util.concurrent.CountDownLatch@102a0a5[Count = 0]
Worker.workerThread = Thread[ReceiveSerializer0,5,main]
QueueWorker.queue =
QueueWorker.pollMillis = 100
TCPSelector [debug.lifecycle.dump] DUMP Channel@46
channelID = 1
channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
channelIndex = 0
receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
receiveHandler = SignalProtocol[cdo]
receiveSerializer = ChannelReceiveSerializer@45
sendQueue =
TCPSelector [debug.buffer] Created Buffer@47
TCPSelector [debug.buffer] Obtained Buffer@47
TCPSelector [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[Control]
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug.buffer] Retaining Buffer@43
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 4 bytes
03 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 1
ReceiveSerializer0 [debug.signal] Got signal id 1
Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
Thread-5 [debug.protocol] Read repositoryName: repo1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read disableLegacyObjects: false
Thread-5 [debug.signal] ================ Responding OpenSessionIndication
Thread-5 [debug.session] Opening session 4
Thread-5 [debug.lifecycle] Activating Session[4, Channel[0]]
Thread-5 [debug.lifecycle.dump] DUMP Session@48
sessionManager = SessionManager@8
protocol = SignalProtocol[cdo]
sessionID = 4
disableLegacyObjects = false
views =
protocolListener = org.eclipse.emf.cdo.internal.server.Session$1@b05236
Thread-5 [debug.protocol] Writing sessionID: 4
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.protocol] Writing repositoryUUID:
1ff5d226-b1f0-40fb-aba2-0c31b38c764f
Thread-5 [debug.protocol] Writing package info:
uri=http:///at/quorum/octopus/model/topology.ecore, dynamic=false,
metaIDRange=[MID1:MID102]
Thread-5 [debug.model] Writing CDOID of type 4 (META)
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 117 bytes (EOS)
00 00 00 00 00 00 00 04 01 00 24 31 66 66 35 64 32 32 36 2d 62 31 66 30 2d
34 30 66 62 2d 61 62 61 32 2d 30 63 33 31 62 33 38 63 37 36 34 66 00 01 00
2e 68 74 74 70 3a 2f 2f 2f 61 74 2f 71 75 6f 72 75 6d 2f 6f 63 74 6f 70 75
73 2f 6d 6f 64 65 6c 2f 74 6f 70 6f 6c 6f 67 79 2e 65 63 6f 72 65 00 00 04
00 00 00 00 00 00 00 01 00 00 00 66 00 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 11 bytes (EOS)
00 00 00 02 00 02 00 00 00 01 01
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 2
ReceiveSerializer0 [debug.signal] Got signal id 2
Thread-5 [debug.signal] ================ Indicating ViewsChangedIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.signal] ================ Responding ViewsChangedIndication
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 5 bytes (EOS)
00 00 00 01 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 26 bytes (EOS)
00 00 00 03 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79
00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 3
ReceiveSerializer0 [debug.signal] Got signal id 3
Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read path: /octopus/company
Thread-5 [debug.signal] ================ Responding ResourceIDIndication
Thread-5 [debug.protocol] Writing ID: OID1
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 13 bytes (EOS)
00 00 00 02 01 00 00 00 00 00 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 26 bytes (EOS)
00 00 00 04 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79
00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 4
ReceiveSerializer0 [debug.signal] Got signal id 3
Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] Read path: /octopus/company
Thread-5 [debug.signal] ================ Responding ResourceIDIndication
Thread-5 [debug.protocol] Writing ID: OID1
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 13 bytes (EOS)
00 00 00 03 01 00 00 00 00 00 00 00 01
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Obtained Buffer@43
TCPSelector [debug.buffer] Read 27 bytes (EOS)
00 00 00 05 00 06 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01 00 00
00 00
TCPSelector [debug.channel] Handling buffer from multiplexer: Buffer@43
--> Channel[0]
ReceiveSerializer0 [debug.signal] Received buffer for correlation 5
ReceiveSerializer0 [debug.signal] Got signal id 6
Thread-5 [debug.signal] ================ Indicating LoadRevisionIndication
Thread-5 [debug.protocol] Read referenceChunk: -1
Thread-5 [debug.protocol] Reading 1 IDs
Thread-5 [debug.model] Reading CDOID of type 1 (OBJECT)
Thread-5 [debug.protocol] Read ID: OID1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.signal] ================ Responding LoadRevisionIndication
Thread-5 [debug.protocol] Writing 1 revisions
Thread-5 [debug.revision] Writing revision: ID=OID1,
classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0, 0),
className=CDOResource, version=1, created=1.204.994.605.537, revised=0,
resource=OID1, container=NULL, feature=0
Thread-5 [debug.buffer] Obtained Buffer@47
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
Thread-5 [debug.model] Writing CDOID of type 0 (NULL)
Thread-5 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
type=STRING, referenceType=null): /octopus/company
Thread-5 [debug.revision] Writing feature CDOFeature(ID=2, name=contents,
type=OBJECT, referenceType=CDOClass(ID=0, name=CDOObject)): size=1
Thread-5 [debug.revision]
OID3(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
Thread-5 [perf.revision.writing] CDOResource@OID1v1 = 0 millis
Thread-5 [debug.protocol] Writing 0 additional revisions
Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
Channel[0]
Thread-5 [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = true
TCPSelector [debug] Setting interest READ|WRITE (was read)
TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
TCPSelector [debug.buffer] Writing 141 bytes (EOS)
00 00 00 04 01 00 2d 68 74 74 70 3a 2f 2f 77 77 77 2e 65 63 6c 69 70 73 65
2e 6f 72 67 2f 65 6d 66 2f 43 44 4f 2f 72 65 73 6f 75 72 63 65 2f 31 2e 30
2e 30 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 01 00 00 01 18 70
46 7e 1e 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00
01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61 6e 79 00 00 00 00 01 00
00 00 00 02 00 00 00 00 00 00 00 03 00 00 00 00
TCPSelector [debug.buffer] Retaining Buffer@47
TCPSelector [debug] Ordering server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Executing server operation INTEREST WRITE
java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
remote=/127.0.0.1:1338] = false
TCPSelector [debug] Setting interest READ (was read|write)
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615640 is a reply to message #114129] |
Sun, 09 March 2008 06:37 |
|
Hi Matthias,
I think I got it from the log:
Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
If I exclude a bug in CDO with respect to your effect it is much likely
that you missed to generate your model with CDO support. Have you
followed the descriptions in
http://wiki.eclipse.org/Preparing_EMF_Models_for_CDO ?
Cheers
/Eike
Matthias schrieb:
> Hey Eike!
>
> Hmm... I do not have the faintest idea what I am doing wrong here! On
> the server side everything looks fine... no exception correct, queries
> log and so on!
>
> On the client i obtain a session, query if the package registry is
> empty, get my resource and the call resource.getContents is doing
> well. But querying elements or calling the size from that received
> collection gives me a timeout exception as posted before...
> Hope you can help me... with that information... I will provide you
> any information about my problem if you tell me how and what...
>
> Best regards,
> Matthias
>
> PS: I am using HEAD.
>
> Here the server logs:
> TCPSelector [debug] Accepting
> sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036]
> TCPSelector [debug] Accepted socketChannel
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug.lifecycle] Activating
> ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.connector] Setting state CONNECTING (was
> disconnected) for ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.lifecycle] Activating Channel[Control]
> TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@40
> TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@40
> Worker.daemon = false
> Worker.activationTimeout = 2000
> Worker.deactivationTimeout = 2000
> Worker.activationLatch =
> java.util.concurrent.CountDownLatch@8f2ca6[Count = 0]
> Worker.workerThread = Thread[ReceiveSerializer-1,5,main]
> QueueWorker.queue = QueueWorker.pollMillis = 100
>
> TCPSelector [debug.lifecycle.dump] DUMP ControlChannel@41
> Channel.channelID = 0
> Channel.channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
> Channel.channelIndex = -1
> Channel.receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Channel.receiveHandler = null
> Channel.receiveSerializer = ChannelReceiveSerializer@40
> Channel.sendQueue = registrations = SynchronizingCorrelator{}
>
> TCPSelector [debug] Ordering server operation REGISTER
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug] Executing server operation REGISTER
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug] Registering
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338]
> TCPSelector [debug.connector] Setting state CONNECTED (was connecting)
> for ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug.lifecycle.dump] DUMP TCPServerConnector@42
> Connector.userID = null
> Connector.protocolFactoryRegistry =
> org.eclipse.net4j.acceptors[tcp]=Factory[org.eclipse.net4j.a cceptors,
> tcp]
>
> org.eclipse.net4j.Negotiators[challenge]=Factory[org.eclipse .net4j.Negotiators,
> challenge]
>
> org.eclipse.net4j.connectors[tcp]=Factory[org.eclipse.net4j. connectors,
> tcp]
>
> org.eclipse.net4j.randomizers[default]=Factory[org.eclipse.n et4j.randomizers,
> default]
>
> org.eclipse.net4j.userManagers[file]=Factory[org.eclipse.net 4j.userManagers,
> file]
>
> org.eclipse.net4j.executorServices[default]=Factory[org.ecli pse.net4j.executorServices,
> default]
>
> org.eclipse.net4j.serverProtocols[cdo]=Factory[org.eclipse.n et4j.serverProtocols,
> cdo]
>
> org.eclipse.net4j.selectors[tcp]=Factory[org.eclipse.net4j.s electors,
> tcp]
>
> org.eclipse.net4j.bufferProviders[default]=Factory[org.eclip se.net4j.bufferProviders,
> default]
> Connector.protocolPostProcessors =
> org.eclipse.net4j.internal.util.security.ChallengeNegotiator Configurer @12f9ee
>
> org.eclipse.internal.net4j.Net4jTransportInjector@1d6a56e
> org.eclipse.net4j.internal.tcp.TCPSelectorInjector@106fc94
> Connector.negotiator = null
> Connector.negotiationContext = null
> Connector.bufferProvider = BufferPool[4.096]
> Connector.receiveExecutor =
> java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Connector.nextChannelID = 1
> Connector.channels = Connector.channelsLock =
> org.eclipse.net4j.util.concurrent.RWLock@8b677f[Write locks = 0, Read
> locks = 0]
> Connector.connectorState = CONNECTED
> Connector.channelListener =
> org.eclipse.internal.net4j.connector.Connector$1@37d490
> Connector.finishedConnecting =
> java.util.concurrent.CountDownLatch@1647278[Count = 1]
> Connector.finishedNegotiating =
> java.util.concurrent.CountDownLatch@1972e3a[Count = 1]
> TCPConnector.socketChannel = java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPConnector.selector = TCPSelector
> TCPConnector.selectionKey = sun.nio.ch.SelectionKeyImpl@1d840d9
> TCPConnector.writeQueue = TCPConnector.inputBuffer = null
> TCPConnector.controlChannel = Channel[Control]
> TCPConnector.host = null
> TCPConnector.port = 0
> acceptor = TCPAcceptor[0.0.0.0:2.036]
>
> TCPSelector [debug.acceptor] Added connector
> ServerTCPConnector[127.0.0.1:1.338]
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Created Buffer@43
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 12 bytes
> 02 00 00 00 01 00 00 00 03 63 64 6f TCPSelector [debug.lifecycle]
> Activating SignalProtocol[cdo]
> TCPSelector [debug.lifecycle.dump] DUMP CDOServerProtocol@44
> Protocol.channel = Channel[-32.768]
> Protocol.bufferProvider = BufferPool[4.096]
> Protocol.executorService =
> java.util.concurrent.ThreadPoolExecutor@1d8d39f
> Protocol.infraStructure =
> org.eclipse.emf.cdo.internal.server.PluginRepositoryProvider @c792d4
> SignalProtocol.streamWrapper = null
> SignalProtocol.signals = SignalProtocol.nextCorrelationID = 1
>
> TCPSelector [debug.connector] Opening channel 0 with protocol cdo
> TCPSelector [debug.lifecycle] Activating Channel[0]
> TCPSelector [debug.lifecycle] Activating ChannelReceiveSerializer@45
> TCPSelector [debug.lifecycle.dump] DUMP ChannelReceiveSerializer@45
> Worker.daemon = false
> Worker.activationTimeout = 2000
> Worker.deactivationTimeout = 2000
> Worker.activationLatch =
> java.util.concurrent.CountDownLatch@102a0a5[Count = 0]
> Worker.workerThread = Thread[ReceiveSerializer0,5,main]
> QueueWorker.queue = QueueWorker.pollMillis = 100
>
> TCPSelector [debug.lifecycle.dump] DUMP Channel@46
> channelID = 1
> channelMultiplexer = ServerTCPConnector[127.0.0.1:1.338]
> channelIndex = 0
> receiveExecutor = java.util.concurrent.ThreadPoolExecutor@1d8d39f
> receiveHandler = SignalProtocol[cdo]
> receiveSerializer = ChannelReceiveSerializer@45
> sendQueue =
> TCPSelector [debug.buffer] Created Buffer@47
> TCPSelector [debug.buffer] Obtained Buffer@47
> TCPSelector [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[Control]
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug.buffer] Retaining Buffer@43
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 4 bytes
> 03 00 00 01 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 16 bytes (EOS)
> 00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00 TCPSelector
> [debug.channel] Handling buffer from multiplexer: Buffer@43 -->
> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 1
> ReceiveSerializer0 [debug.signal] Got signal id 1
> Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
> Thread-5 [debug.protocol] Read repositoryName: repo1
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read disableLegacyObjects: false
> Thread-5 [debug.signal] ================ Responding OpenSessionIndication
> Thread-5 [debug.session] Opening session 4
> Thread-5 [debug.lifecycle] Activating Session[4, Channel[0]]
> Thread-5 [debug.lifecycle.dump] DUMP Session@48
> sessionManager = SessionManager@8
> protocol = SignalProtocol[cdo]
> sessionID = 4
> disableLegacyObjects = false
> views = protocolListener =
> org.eclipse.emf.cdo.internal.server.Session$1@b05236
>
> Thread-5 [debug.protocol] Writing sessionID: 4
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.protocol] Writing repositoryUUID:
> 1ff5d226-b1f0-40fb-aba2-0c31b38c764f
> Thread-5 [debug.protocol] Writing package info:
> uri=http:///at/quorum/octopus/model/topology.ecore, dynamic=false,
> metaIDRange=[MID1:MID102]
> Thread-5 [debug.model] Writing CDOID of type 4 (META)
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 117 bytes (EOS)
> 00 00 00 00 00 00 00 04 01 00 24 31 66 66 35 64 32 32 36 2d 62 31 66
> 30 2d 34 30 66 62 2d 61 62 61 32 2d 30 63 33 31 62 33 38 63 37 36 34
> 66 00 01 00 2e 68 74 74 70 3a 2f 2f 2f 61 74 2f 71 75 6f 72 75 6d 2f
> 6f 63 74 6f 70 75 73 2f 6d 6f 64 65 6c 2f 74 6f 70 6f 6c 6f 67 79 2e
> 65 63 6f 72 65 00 00 04 00 00 00 00 00 00 00 01 00 00 00 66 00 00 00
> 00 00 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 11 bytes (EOS)
> 00 00 00 02 00 02 00 00 00 01 01 TCPSelector [debug.channel] Handling
> buffer from multiplexer: Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 2
> ReceiveSerializer0 [debug.signal] Got signal id 2
> Thread-5 [debug.signal] ================ Indicating
> ViewsChangedIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.signal] ================ Responding
> ViewsChangedIndication
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 5 bytes (EOS)
> 00 00 00 01 01 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 26 bytes (EOS)
> 00 00 00 03 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61
> 6e 79 00 TCPSelector [debug.channel] Handling buffer from multiplexer:
> Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 3
> ReceiveSerializer0 [debug.signal] Got signal id 3
> Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read path: /octopus/company
> Thread-5 [debug.signal] ================ Responding ResourceIDIndication
> Thread-5 [debug.protocol] Writing ID: OID1
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 13 bytes (EOS)
> 00 00 00 02 01 00 00 00 00 00 00 00 01 TCPSelector [debug.buffer]
> Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 26 bytes (EOS)
> 00 00 00 04 00 03 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d 70 61
> 6e 79 00 TCPSelector [debug.channel] Handling buffer from multiplexer:
> Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 4
> ReceiveSerializer0 [debug.signal] Got signal id 3
> Thread-5 [debug.signal] ================ Indicating ResourceIDIndication
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.protocol] Read path: /octopus/company
> Thread-5 [debug.signal] ================ Responding ResourceIDIndication
> Thread-5 [debug.protocol] Writing ID: OID1
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 13 bytes (EOS)
> 00 00 00 03 01 00 00 00 00 00 00 00 01 TCPSelector [debug.buffer]
> Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
> TCPSelector [debug] Reading java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Obtained Buffer@43
> TCPSelector [debug.buffer] Read 27 bytes (EOS)
> 00 00 00 05 00 06 00 00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 01
> 00 00 00 00 TCPSelector [debug.channel] Handling buffer from
> multiplexer: Buffer@43 --> Channel[0]
> ReceiveSerializer0 [debug.signal] Received buffer for correlation 5
> ReceiveSerializer0 [debug.signal] Got signal id 6
> Thread-5 [debug.signal] ================ Indicating
> LoadRevisionIndication
> Thread-5 [debug.protocol] Read referenceChunk: -1
> Thread-5 [debug.protocol] Reading 1 IDs
> Thread-5 [debug.model] Reading CDOID of type 1 (OBJECT)
> Thread-5 [debug.protocol] Read ID: OID1
> Thread-5 [debug.buffer] Retaining Buffer@43
> Thread-5 [debug.signal] ================ Responding
> LoadRevisionIndication
> Thread-5 [debug.protocol] Writing 1 revisions
> Thread-5 [debug.revision] Writing revision: ID=OID1,
> classRef=CDOClassRef(http://www.eclipse.org/emf/CDO/resource/1.0.0,
> 0), className=CDOResource, version=1, created=1.204.994.605.537,
> revised=0, resource=OID1, container=NULL, feature=0
> Thread-5 [debug.buffer] Obtained Buffer@47
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.model] Writing CDOID of type 1 (OBJECT)
> Thread-5 [debug.model] Writing CDOID of type 0 (NULL)
> Thread-5 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
> type=STRING, referenceType=null): /octopus/company
> Thread-5 [debug.revision] Writing feature CDOFeature(ID=2,
> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
> name=CDOObject)): size=1
> Thread-5 [debug.revision]
> OID3(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
> Thread-5 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
> Thread-5 [perf.revision.writing] CDOResource@OID1v1 = 0 millis
> Thread-5 [debug.protocol] Writing 0 additional revisions
> Thread-5 [debug.channel] Handling buffer from client: Buffer@47 -->
> Channel[0]
> Thread-5 [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = true
> TCPSelector [debug] Setting interest READ|WRITE (was read)
> TCPSelector [debug] Writing java.nio.channels.SocketChannel[connected
> local=/127.0.0.1:2036 remote=/127.0.0.1:1338]
> TCPSelector [debug.buffer] Writing 141 bytes (EOS)
> 00 00 00 04 01 00 2d 68 74 74 70 3a 2f 2f 77 77 77 2e 65 63 6c 69 70
> 73 65 2e 6f 72 67 2f 65 6d 66 2f 43 44 4f 2f 72 65 73 6f 75 72 63 65
> 2f 31 2e 30 2e 30 00 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
> 01 00 00 01 18 70 46 7e 1e 00 00 00 00 00 00 00 00 01 00 00 00 00 00
> 00 00 01 00 00 00 00 00 01 00 10 2f 6f 63 74 6f 70 75 73 2f 63 6f 6d
> 70 61 6e 79 00 00 00 00 01 00 00 00 00 02 00 00 00 00 00 00 00 03 00
> 00 00 00 TCPSelector [debug.buffer] Retaining Buffer@47
> TCPSelector [debug] Ordering server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Executing server operation INTEREST WRITE
> java.nio.channels.SocketChannel[connected local=/127.0.0.1:2036
> remote=/127.0.0.1:1338] = false
> TCPSelector [debug] Setting interest READ (was read|write)
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615644 is a reply to message #114130] |
Sun, 09 March 2008 13:33 |
Matthias Treitler Messages: 117 Registered: July 2009 |
Senior Member |
|
|
Hi!
Thank you for your answer! But I have converted my model to be CDO
compliant and I do not detect any differences between your tests provided
in the CVS and my implementation!
Maybe I have to run CDO Weaver?!? I already tried to convert all my
detected bundles but I always get the following exception:
Weaving 1 bundles
null
java.lang.NullPointerException
at
org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
at org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
at
org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
at
org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
!
So you think this line indicates that might cause the error:
Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
type=STRING, referenceType=null): /octopus/company
Thread-6 [debug.revision] Writing feature CDOFeature(ID=2, name=contents,
type=OBJECT, referenceType=CDOClass(ID=0, name=CDOObject)): size=1
Thread-6 [debug.revision]
OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
Why does the server "think" that I have legacy objects?!? What does it
mean?
Best regards,
Matthias
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615645 is a reply to message #114246] |
Sun, 09 March 2008 17:15 |
|
Hi Matthias,
Comments below...
Matthias schrieb:
> Hi!
>
> Thank you for your answer! But I have converted my model to be CDO
> compliant and I do not detect any differences between your tests
> provided in the CVS and my implementation!
>
> Maybe I have to run CDO Weaver?!?
No, no! Don't use the weaver if you intend to use models that you
generated for CDO!
The weaver is needed to turn on the CDO legacy system and to convert
legacy models for usage with CDO at runtime.
You don't want to do that with your own models.
> I already tried to convert all my detected bundles but I always get
> the following exception:
> Weaving 1 bundles
> null
> java.lang.NullPointerException
> at
> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
>
> at
> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
> at
> org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
>
> at
> org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
>
> at
> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
>
Apart from the fact that you don't want to use the weaver, I will look
into this issue later...
> So you think this line indicates that might cause the error:
>
> Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
> type=STRING, referenceType=null): /octopus/company
> Thread-6 [debug.revision] Writing feature CDOFeature(ID=2,
> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
> name=CDOObject)): size=1
> Thread-6 [debug.revision]
> OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
> Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
>
> Why does the server "think" that I have legacy objects?!? What does it
> mean?
In fact that can indicate one of the following:
1) You actually have legacy objects (in case you didn't generate
CDOObjectImpls)
2) You just configured the client CDOSession to support legacy objects.
How did you open the session? There's a utility class:
CDOUtil.openSession(..., boolean disableLegacyObjects);
You should call it with disableLegacyObjects==true. If you create the
session differently you should call setDisableLegacyObjects(true) before
activating the session object.
After activating the session the value can't be changed anymore. At any
time it can bequeried: CDOSession.isDisableLegacyObjects()
Have you tried to use your model with the UI that comes with CDO? Does
it work there?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO 0.8M5] Persisting Enums troubles [message #615646 is a reply to message #114260] |
Sun, 09 March 2008 17:26 |
|
This is a multi-part message in MIME format.
--------------010600010607000800050407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Matthias,
I just saw the following in your log:
Thread-5 [debug.signal] ================ Indicating OpenSessionIndication
Thread-5 [debug.protocol] Read repositoryName: repo1
Thread-5 [debug.buffer] Retaining Buffer@43
Thread-5 [debug.protocol] *Read disableLegacyObjects: false *
So it's pretty clear how the problem can be fixed: Open your session
with disableLegacyObjects=true
Background: Usually it's only a performance and a resource penalty
incured when you open a session with legacy system support but it should
not fail. Due to our efforts to integrate Hibernate at the server side
the whole legacy system is temporarily broken. This is not that nice but
I currently know of nobody actually using the legacy system.
Btw. for more convenience I've already added two features to preserve
accidental use of the legacy system:
1) Opening a session with legacy support throws an exception if the
legacy system is not available
2) Attaching legacy objects to a session w/o legacy support throws an
exception
Both changes are committed and are contained in todays builds.
Cheers
/Eike
Eike Stepper schrieb:
> Hi Matthias,
>
> Comments below...
>
>
>
> Matthias schrieb:
>> Hi!
>>
>> Thank you for your answer! But I have converted my model to be CDO
>> compliant and I do not detect any differences between your tests
>> provided in the CVS and my implementation!
>>
>> Maybe I have to run CDO Weaver?!?
> No, no! Don't use the weaver if you intend to use models that you
> generated for CDO!
> The weaver is needed to turn on the CDO legacy system and to convert
> legacy models for usage with CDO at runtime.
> You don't want to do that with your own models.
>
>> I already tried to convert all my detected bundles but I always get
>> the following exception:
>> Weaving 1 bundles
>> null
>> java.lang.NullPointerException
>> at
>> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.getSourceLocat ions(CDOWeaver.java:413)
>>
>> at
>> org.eclipse.emf.cdo.internal.weaver.CDOWeaver.weave(CDOWeave r.java:99)
>> at
>> org.eclipse.emf.cdo.weaver.internal.ui.dialogs.ConfirmWeaveD ialog$2.run(ConfirmWeaveDialog.java:153)
>>
>> at
>> org.eclipse.net4j.util.ui.widgets.MonitorDialog$1.run(Monito rDialog.java:65)
>>
>> at
>> org.eclipse.jface.operation.ModalContext$ModalContextThread. run(ModalContext.java:119)
>>
> Apart from the fact that you don't want to use the weaver, I will look
> into this issue later...
>
>> So you think this line indicates that might cause the error:
>>
>> Thread-6 [debug.revision] Writing feature CDOFeature(ID=9, name=path,
>> type=STRING, referenceType=null): /octopus/company
>> Thread-6 [debug.revision] Writing feature CDOFeature(ID=2,
>> name=contents, type=OBJECT, referenceType=CDOClass(ID=0,
>> name=CDOObject)): size=1
>> Thread-6 [debug.revision]
>> OID2(CDOClassRef(http:///at/quorum/octopus/model/topology.ecore, 1))
>> Thread-6 [debug.model] Writing CDOID of type 2 (LEGACY_OBJECT)
>>
>> Why does the server "think" that I have legacy objects?!? What does
>> it mean?
> In fact that can indicate one of the following:
> 1) You actually have legacy objects (in case you didn't generate
> CDOObjectImpls)
> 2) You just configured the client CDOSession to support legacy objects.
>
> How did you open the session? There's a utility class:
> CDOUtil.openSession(..., boolean disableLegacyObjects);
>
> You should call it with disableLegacyObjects==true. If you create the
> session differently you should call setDisableLegacyObjects(true)
> before activating the session object.
> After activating the session the value can't be changed anymore. At
> any time it can bequeried: CDOSession.isDisableLegacyObjects()
>
>
> Have you tried to use your model with the UI that comes with CDO? Does
> it work there?
>
> Cheers
> /Eike
--------------010600010607000800050407
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Matthias,<br>
<br>
I just saw the following in your log:<br>
<br>
Thread-5 [debug.signal] ================ Indicating
OpenSessionIndication
<br>
Thread-5 [debug.protocol] Read repositoryName: repo1
<br>
Thread-5 [debug.buffer] Retaining Buffer@43
<br>
Thread-5 [debug.protocol] <b>Read disableLegacyObjects: false
</b><br>
<br>
So it's pretty clear how the problem can be fixed: Open your session
with disableLegacyObjects=true<br>
<br>
Background: Usually it's only a performance and a resource penalty
incured when you open a session with legacy system support but it
should not fail. Due to our efforts to integrate Hibernate at the
server side the whole legacy system is temporarily broken. This is not
that nice but I currently know of nobody actually using the legacy
system.<br>
<br>
Btw. for more convenience I've already added two features to preserve
accidental use of the legacy system:<br>
1) Opening a session with legacy support throws an exception if the
legacy system is not available<br>
2) Attaching legacy objects to a session w/o legacy support throws an
exception<br>
<br>
Both changes are committed and are contained in todays builds.<br>
<br>
Cheers<br>
/Eike<br>
<br>
<br>
Eike Stepper schrieb:
<blockquote cite="mid:fr15vs$9vf$1@build.eclipse.org" type="cite">Hi
Matthias,
<br>
<br>
Comments below...
<br>
<br>
<br>
<br>
Matthias schrieb:
<br>
<blockquote type="cite">Hi!
<br>
<br>
Thank you for your answer! But I have converted my model to be CDO
compliant and I do not detect any differences between your tests
provided in the CVS and my implementation!
<br>
<br>
Maybe I have to run CDO Weaver?!? </blockquote>
No, no! Don't use the weaver if you intend to use models that you
generated for CDO!
<br>
The weaver is needed to turn on the CDO legacy system and to convert
legacy models for usage with CDO at runtime.
<br>
You don't want to do that with your own models.
<br>
<br>
<blockquote type="cite">I already tried to convert all my detected
bundles but I always get the following exception:
<br>
Weaving 1 bundles
<br>
null
<br>
java.lang.NullPointerException
<br>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Re: [CDO 0.8M5] Persisting Enums troubles [message #615855 is a reply to message #114502] |
Wed, 12 March 2008 19:07 |
|
Hi Matthias,
Sorry, my fault again. I converted the enum to String after the delta of the modification was calculated. I fixed that in HEAD and added test code.
Cheers
/Eike
Matthias schrieb:
> Hey Eike!
>
> I have deleted my existing Derby DB for my project and restarted the
> shipped CDO server on CVS.
>
> I started my own project and when inserting data or modifying data to
> the model repository I get the following exception:
>
> java.lang.ClassCastException: at.quorum.octopus.model.topology.ItemType
> cannot be cast to java.lang.String
> at
> org.eclipse.emf.cdo.internal.protocol.model.CDOTypeImpl$20.w riteValue(CDOTypeImpl.java:338)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.delta.CDOSing leValueFeatureDeltaImpl.write(CDOSingleValueFeatureDeltaImpl .java:71)
>
> at
> org.eclipse.emf.cdo.internal.protocol.revision.delta.CDORevi sionDeltaImpl.write(CDORevisionDeltaImpl.java:111)
>
> at
> org.eclipse.emf.internal.cdo.protocol.CommitTransactionReque st.requesting(CommitTransactionRequest.java:103)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:48)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:237)
>
> at org.eclipse.net4j.signal.SignalActor.send(SignalActor.java:5 0)
> at
> org.eclipse.net4j.signal.failover.NOOPFailOverStrategy.send( NOOPFailOverStrategy.java:34)
>
> at
> org.eclipse.emf.internal.cdo.CDOTransactionImpl.commit(CDOTr ansactionImpl.java:236)
>
>
>
> Its a kind of weird because it worked for me after you fixed that bug as
> posted previously... even on updating model entities :)
>
> This exception is only thrown when updating a model entity not creating
> one... (as I can remember)
>
> Best regards,
> Matthias
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Tue Sep 24 21:47:18 GMT 2024
Powered by FUDForum. Page generated in 0.10013 seconds
|