Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO 0.8M5] Persisting Enums troubles
[CDO 0.8M5] Persisting Enums troubles [message #113706] Mon, 03 March 2008 12:13 Go to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #113733 is a reply to message #113706] Mon, 03 March 2008 15:03 Go to previous messageGo to next message
Eclipse UserFriend
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 #113781 is a reply to message #113733] Tue, 04 March 2008 07:57 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #113806 is a reply to message #113781] Tue, 04 March 2008 09:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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!


Re: [CDO 0.8M5] Persisting Enums troubles [message #113813 is a reply to message #113806] Tue, 04 March 2008 09:31 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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... ;)!

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?!

Best regards,
Matthias
Re: [CDO 0.8M5] Persisting Enums troubles [message #113866 is a reply to message #113813] Tue, 04 March 2008 12:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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


Re: [CDO 0.8M5] Persisting Enums troubles [message #113880 is a reply to message #113781] Tue, 04 March 2008 20:23 Go to previous messageGo to next message
Eclipse UserFriend
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 #113906 is a reply to message #113880] Wed, 05 March 2008 14:05 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey!

Oh nice, its working now ;)! Thank you!

Currently I am fighting with another "problem", but I think CDO is working
correctly.

Best regards,
Matthias

PS: I am really looking forward to come to EclipseCon next year.
Re: [CDO 0.8M5] Persisting Enums troubles [message #113972 is a reply to message #113906] Wed, 05 March 2008 18:05 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Matthias wrote:

> Hey!

> Oh nice, its working now ;)! Thank you!

> Currently I am fighting with another "problem", but I think CDO is working
> correctly.

Great to hear!
Tell me if you encounter other issues ;-)

Cheers
/Eike



> Best regards,
> Matthias

> PS: I am really looking forward to come to EclipseCon next year.


Re: [CDO 0.8M5] Persisting Enums troubles [message #114055 is a reply to message #113866] Fri, 07 March 2008 13:11 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #114126 is a reply to message #114055] Sat, 08 March 2008 07:05 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 #114285 is a reply to message #114272] Sun, 09 March 2008 18:30 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey Eike!

Thank your for your (detailed) answer! Yes, this flag made me a lot of
headcache ;) but now everything works fine... thanks

Best regards,
Matthias
Re: [CDO 0.8M5] Persisting Enums troubles [message #114310 is a reply to message #114285] Sun, 09 March 2008 20:01 Go to previous messageGo to next message
Eclipse UserFriend
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 #114502 is a reply to message #113880] Wed, 12 March 2008 10:02 Go to previous messageGo to next message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #114580 is a reply to message #114502] Wed, 12 March 2008 19:07 Go to previous messageGo to next message
Eclipse UserFriend
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 #114727 is a reply to message #114580] Fri, 14 March 2008 00:10 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey Eike!

Thanks it works now ;)!!

Bye,
Matthias
Re: [CDO 0.8M5] Persisting Enums troubles [message #615597 is a reply to message #113706] Mon, 03 March 2008 15:03 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615601 is a reply to message #113733] Tue, 04 March 2008 07:57 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #615603 is a reply to message #113781] Tue, 04 March 2008 09:17 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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!


Re: [CDO 0.8M5] Persisting Enums troubles [message #615604 is a reply to message #113806] Tue, 04 March 2008 09:31 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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... ;)!

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?!

Best regards,
Matthias
Re: [CDO 0.8M5] Persisting Enums troubles [message #615607 is a reply to message #113813] Tue, 04 March 2008 12:42 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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


Re: [CDO 0.8M5] Persisting Enums troubles [message #615608 is a reply to message #113781] Tue, 04 March 2008 20:23 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615610 is a reply to message #113880] Wed, 05 March 2008 14:05 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey!

Oh nice, its working now ;)! Thank you!

Currently I am fighting with another "problem", but I think CDO is working
correctly.

Best regards,
Matthias

PS: I am really looking forward to come to EclipseCon next year.
Re: [CDO 0.8M5] Persisting Enums troubles [message #615615 is a reply to message #113906] Wed, 05 March 2008 18:05 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
Matthias wrote:

> Hey!

> Oh nice, its working now ;)! Thank you!

> Currently I am fighting with another "problem", but I think CDO is working
> correctly.

Great to hear!
Tell me if you encounter other issues ;-)

Cheers
/Eike



> Best regards,
> Matthias

> PS: I am really looking forward to come to EclipseCon next year.


Re: [CDO 0.8M5] Persisting Enums troubles [message #615622 is a reply to message #113866] Fri, 07 March 2008 13:11 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #615636 is a reply to message #114055] Sat, 08 March 2008 07:05 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615639 is a reply to message #114126] Sat, 08 March 2008 16:58 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
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 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615644 is a reply to message #114130] Sun, 09 March 2008 13:33 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
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 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615646 is a reply to message #114260] Sun, 09 March 2008 17:26 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615647 is a reply to message #114272] Sun, 09 March 2008 18:30 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey Eike!

Thank your for your (detailed) answer! Yes, this flag made me a lot of
headcache ;) but now everything works fine... thanks

Best regards,
Matthias
Re: [CDO 0.8M5] Persisting Enums troubles [message #615649 is a reply to message #114285] Sun, 09 March 2008 20:01 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615846 is a reply to message #113880] Wed, 12 March 2008 10:02 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
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 #615855 is a reply to message #114502] Wed, 12 March 2008 19:07 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6579
Registered: July 2009
Senior Member
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 #615875 is a reply to message #114580] Fri, 14 March 2008 00:10 Go to previous message
Matthias Treitler is currently offline Matthias TreitlerFriend
Messages: 117
Registered: July 2009
Senior Member
Hey Eike!

Thanks it works now ;)!!

Bye,
Matthias
Previous Topic:teneo:circular loop on DB2 error
Next Topic:Disable the schemaExport on the hibernate
Goto Forum:
  


Current Time: Sun Jun 13 06:37:03 GMT 2021

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

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

Back to the top