Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO] Loss of connectivity hosing the client
[CDO] Loss of connectivity hosing the client [message #126491] Tue, 01 July 2008 07:57 Go to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Hi, I'm wondering how best to handle network drops and loss of
connectivity in client code when using CDO. So far my experience has been
that this completely hoses the client beyond all repair, so that it must
be restarted (in certain cases it not only ceases to function but becomes
unresponsive waiting on a response from the server which never comes.) I
am using the HTTP connector.

Things I have tried to attempt to recover from network outages:
1) Close the transaction, open a new one. (throws an exception)
2) Close the session, open a new one.
3) Close the session's channel.
4) Disconnect the session's connector and reconnect it.

I've tried these steps in various orders and combinations with one
another, all to no avail. The only thing that gets the client working
again is to restart the whole application--needless to say this is far
from desirable. What is the "right" way to do this (assuming there is
one)?

My experience so far has been that CDO works great when you use it exactly
as you're supposed to (which takes some figuring out since it doesn't have
much documentation yet). It has the makings of a great project, I hope it
continues to grow!

Tom
Re: [CDO] Loss of connectivity hosing the client [message #126506 is a reply to message #126491] Tue, 01 July 2008 08:19 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Addendum: On further experimentation I discovered that the editor that
comes shipped with CDO seems to handle dropouts just fine without having
to close/reopen transactions or sessions, so this appears to be yet
another case of CDO doing what it's supposed to as long one uses it
correctly, which I am apparently not :)
Re: [CDO] Loss of connectivity hosing the client [message #126519 is a reply to message #126506] Tue, 01 July 2008 15:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Thomas,

I've added the EMF newsgroup to the recipients since EMF is the new home
base of CDO since it graduated from incubation.

CDO itself uses timeouts to cope with server processing and partial
network failure. So it's mainly an issue of setting appropriate timeouts.
In addition there is the Net4j concept of IFailoverStrategy which will
undergo a complete re-think during the 2.0 stream. Related Bugzillas:

201267: Failover strategy for CDO/NET4J
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201267

203167: Multiple CDO Servers (failover+loadbalancing)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203167

235042: Provide exchangeable protocol facade
https://bugs.eclipse.org/bugs/show_bug.cgi?id=235042

I also have the feeling that the most subtle challenge with respect to
synchronous/timed-out requests is in the UI and the correct usage of CDO.
Could you please elaborate a bit on your particular UI?

Cheers
/Eike


Thomas Crockett schrieb:
> Addendum: On further experimentation I discovered that the editor that
> comes shipped with CDO seems to handle dropouts just fine without
> having to close/reopen transactions or sessions, so this appears to be
> yet another case of CDO doing what it's supposed to as long one uses
> it correctly, which I am apparently not :)
>
Re: [CDO] Loss of connectivity hosing the client [message #126531 is a reply to message #126519] Tue, 01 July 2008 17:53 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
I'm getting this error a lot (even when using the shipped CDO editor) when
I force a dropout (by disconnecting my ethernet cable for instance):

[ERROR] java.io.IOException: Invalid operation code: 60
org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException: Invalid
operation code: 60
at
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
at
org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
at
org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
at
org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
at
org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
at
org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
at
org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
at
org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
at
org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.io.IOException: Invalid operation code: 60
at
org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
at
org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
... 17 more
Re: [CDO] Loss of connectivity hosing the client [message #126544 is a reply to message #126519] Tue, 01 July 2008 18:12 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Could you please elaborate a bit on your particular UI?

My UI is a highly customized GEF editor that allows one to annotate images
(very large tiled images taken by robots in orbit and on the surface of
Mars, if you're curious :) My model is the annotations themselves; they
can be 3d points placed on the terrain, or 2d points tied to pixel
coordinates where range data is unavailable. The way one edits the model
is by dragging these image markers around, changing their names, etc. I
enforce that all edits to the model take place in the display thread.

Currently I have a singleton "PlacesManager" which basically wraps the
details of CDO and only exposes what's necessary. Its main API are
commit() and rollback(), the implementations of which defer to its
privately held CDOTransaction. It has a static CDOSession which it builds
as follows:

session = CDOSessionFactory.get(IPluginContainer.INSTANCE, uri);

When building the PlacesManager's transaction I use these options:

transaction.setInvalidationNotificationsEnabled(true);
transaction.setCommitTimeout(10000);

As a side note, I use setInvalidationNotificationsEnabled(true) so that
multiple users can annotate images collaboratively and see each others'
edits appear instantly on their screen--that feature is a big reason I
chose CDO in the first place :)

Any other info you need? I would just give you a full code dump but NASA
is fairly prickly about letting us release code, even when it has nothing
to do with flying spacecraft.

Tom
Re: [CDO] Loss of connectivity hosing the client [message #126556 is a reply to message #126531] Tue, 01 July 2008 18:18 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
And incidentally once I see this message the CDO editor is hosed :( I have
to restart to get it back into a working state. Should I post a bug for
this?

Thomas Crockett wrote:

> I'm getting this error a lot (even when using the shipped CDO editor) when
> I force a dropout (by disconnecting my ethernet cable for instance):

> [ERROR] java.io.IOException: Invalid operation code: 60
> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException: Invalid
> operation code: 60
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
> at
> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
> at
>
org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
> at
>
org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
> at
>
org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
> at
>
org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
> at
> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: Invalid operation code: 60
> at
>
org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
> ... 17 more
Re: [CDO] Loss of connectivity hosing the client [message #126570 is a reply to message #126531] Wed, 02 July 2008 06:48 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Thomas,

I forgot to mention that the HTTP transport connector implementation is
brand new!
What you describe looks like a bug since a (partial) network failure
should not cause the client to die with an exception.
Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..." so
that you can track the progress.

Cheers
/Eike


Thomas Crockett schrieb:
> I'm getting this error a lot (even when using the shipped CDO editor)
> when I force a dropout (by disconnecting my ethernet cable for instance):
>
> [ERROR] java.io.IOException: Invalid operation code: 60
> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException:
> Invalid operation code: 60
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
>
> at
> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
>
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>
> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
>
> at
> org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
>
> at
> org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
>
> at
> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: Invalid operation code: 60
> at
> org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
>
> ... 17 more
>
Re: [CDO] Loss of connectivity hosing the client [message #126580 is a reply to message #126556] Wed, 02 July 2008 06:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Thomas,

In addition to fixing the root cause in the underlying transport (see my
other comment) we should look if we can make the CDO UI better when it
comes to abnormal situations. I suggest that a separate Bugzilla on the
EMF/CDO component is appropriate.

Cheers
/Eike



Thomas Crockett schrieb:
> And incidentally once I see this message the CDO editor is hosed :( I
> have to restart to get it back into a working state. Should I post a
> bug for this?
>
> Thomas Crockett wrote:
>
>> I'm getting this error a lot (even when using the shipped CDO editor)
>> when I force a dropout (by disconnecting my ethernet cable for
>> instance):
>
>> [ERROR] java.io.IOException: Invalid operation code: 60
>> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException:
>> Invalid operation code: 60
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
>
>> at
>> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
>>
>> at
>> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
>>
>> at
> org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
>
>> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
>> at
>> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>>
>> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
>>
>> at
> org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
>
>> at
> org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
>
>> at
>> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>> Caused by: java.io.IOException: Invalid operation code: 60
>> at
> org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
>
>> ... 17 more
>
>
Re: [CDO] Loss of connectivity hosing the client [message #126592 is a reply to message #126544] Wed, 02 July 2008 07:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas,

Comments below...


Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Could you please elaborate a bit on your particular UI?
>
> My UI is a highly customized GEF editor that allows one to annotate
> images (very large tiled images taken by robots in orbit and on the
> surface of Mars, if you're curious :) My model is the annotations
> themselves; they can be 3d points placed on the terrain, or 2d points
> tied to pixel coordinates where range data is unavailable. The way one
> edits the model is by dragging these image markers around, changing
> their names, etc. I enforce that all edits to the model take place in
> the display thread.
Hey that sounds like a really nice application!!
So your UI is completely self-made, as opposed to built on what CDO
provides.
Maybe it'd be a good idea to write some tutorial or thelike in the wiki
about how to build own UIs on top of CDO core, once we are through the
CDO "[UI] Improve stability on core failures" Bugzilla that you're going
to enter.


> Currently I have a singleton "PlacesManager" which basically wraps the
> details of CDO and only exposes what's necessary. Its main API are
> commit() and rollback(), the implementations of which defer to its
> privately held CDOTransaction. It has a static CDOSession which it
> builds as follows:
>
> session = CDOSessionFactory.get(IPluginContainer.INSTANCE, uri);
Are you building a standalone application (as opposed to be run in OSGi)?
org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
(OSGi and PDE would prevent you from having access to this class) and
you should use the CDOSessionConfiguration instead.
The examples plugin demonstrates the use of CDO in standalone environments:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project


> When building the PlacesManager's transaction I use these options:
>
> transaction.setInvalidationNotificationsEnabled(true);
> transaction.setCommitTimeout(10000);
>
> As a side note, I use setInvalidationNotificationsEnabled(true) so
> that multiple users can annotate images collaboratively and see each
> others' edits appear instantly on their screen--that feature is a big
> reason I chose CDO in the first place :)
The setInvalidationNotificationsEnabled(true) is convenience mechanism
to have a bit more of a distributed shared experience in unmodified EMF
editors out-of-the-box.
You might be able to build even better UIs if you register an IListener
or a CDOEventHandler directly with the CDOSession. See the CDOEditor for
an example (should also be part of the wiki).

Note that Simon is also working on (we plan to merge a first solution
this week):
233490: Change Subscription
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233490


> Any other info you need? I would just give you a full code dump but
> NASA is fairly prickly about letting us release code, even when it has
> nothing to do with flying spacecraft.
A pity that not everybody is committed to open source (other than just
using it) ;-)
Let's see if our work on Net4j HTTP and CDO UI stability is already
sufficient.


Cheers
/Eike
Re: [CDO] Loss of connectivity hosing the client [message #126631 is a reply to message #126592] Thu, 03 July 2008 12:49 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
>> Eike Stepper wrote:
>
> Are you building a standalone application (as opposed to be run in OSGi)?
> org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
> (OSGi and PDE would prevent you from having access to this class) and
> you should use the CDOSessionConfiguration instead.
> The examples plugin demonstrates the use of CDO in standalone environments:
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project

No, I'm building an eclipse RCP app and I would like to make use of the
niceties of OSGi. What is the right way to do that? That
CDOSessionConfiguration looks like a lot of extra work.
Re: [CDO] Loss of connectivity hosing the client [message #126644 is a reply to message #126570] Thu, 03 July 2008 13:04 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Hi Thomas,

> I forgot to mention that the HTTP transport connector implementation is
> brand new!
> What you describe looks like a bug since a (partial) network failure
> should not cause the client to die with an exception.
> Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..." so
> that you can track the progress.

Ok, I've tried the TCP connector and it still doesn't seem to work very
well when a disconnection occurs. For instance, I had open your CDO UI and
was examining and changing some objects in my model repository. Then I
closed my laptop and drove home from work. Now at home, nothing works
without restarting the app. Trying to open a new transaction creates a job
which spins forever. Same goes for trying to close the current session.
Attempting to open a new session does nothing.

As a side note, I'm wondering if it would be possible to write a
completely stateless connector, based on the principles of REST. Is that
feasible, or is the assumption of a long-lived, stateful connection
between the client and the server endemic to the architecture of Net4j?
Re: [CDO] Loss of connectivity hosing the client [message #126673 is a reply to message #126644] Fri, 04 July 2008 09:08 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Hi Thomas,
>
>> I forgot to mention that the HTTP transport connector implementation
>> is brand new!
>> What you describe looks like a bug since a (partial) network failure
>> should not cause the client to die with an exception.
>> Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..."
>> so that you can track the progress.
>
> Ok, I've tried the TCP connector and it still doesn't seem to work
> very well when a disconnection occurs. For instance, I had open your
> CDO UI and was examining and changing some objects in my model
> repository. Then I closed my laptop and drove home from work. Now at
> home, nothing works without restarting the app. Trying to open a new
> transaction creates a job which spins forever. Same goes for trying to
> close the current session. Attempting to open a new session does nothing.
As I said in the other post we should look if we can make the CDO UI
better when it comes to abnormal situations.
I think that a Bugzilla on the EMF/CDO component is appropriate.


> As a side note, I'm wondering if it would be possible to write a
> completely stateless connector, based on the principles of REST. Is
> that feasible, or is the assumption of a long-lived, stateful
> connection between the client and the server endemic to the
> architecture of Net4j?
I find this particular question hard to answer due to the extensible
architecture of Net4j but I will try ;-)

The transport core of Net4j could be characterized as a layer for
asynchronous and bidirectional switching of buffers through virtual
channels the latters potentially ending in separate VMs. The signalling
layer on top of that provide a more convenient API to application
protocol developers who want to think in terms of requests, optional
responses and streams to transfer the signal data without worrying about
the underlying characteristics of the transport.

While an IChannel is the logical context for the buffer transfers they
are delegated to an IChannelMultiplexer which is currently only
implemented by the provided IConnectors (TCP, HTTP and JVM). In addition
to channel multiplexing a connector manages the underlying physical
connection and is, thus, the only concept that is not bidirectional.
Consequently connectors have different implementations for the active
(client) and the passive (server) side. Active connectors are *opened*
by clients and passive connectors are *accepted* by IAcceptors.

Back to your question:

I don't think that anything in Net4j prevents a developer from
developing REST style application protocols (note that HTTP usually also
uses stateful TCP connections underneath). I think it depends more on
the nature and requirements of the application that a protocol is
developed for whether the protocol can be stateless or not.

In the case of CDO I doubt that. Of course you can move any state
management from the server to the clients if only you transfer enough
data with each request. I'd say the current design (and possibly the sum
of requirements) of CDO is not very well-suited for a REST-style
protocol. Please consider essential (yet optional) features like
asynchronous change notification and the like.

Did that answer your question?

Cheers
/Eike
Re: [CDO] Loss of connectivity hosing the client [message #126684 is a reply to message #126631] Fri, 04 July 2008 09:21 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas Crockett schrieb:
>
>>> Eike Stepper wrote:
>>
>> Are you building a standalone application (as opposed to be run in
>> OSGi)?
>> org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
>> (OSGi and PDE would prevent you from having access to this class) and
>> you should use the CDOSessionConfiguration instead.
>> The examples plugin demonstrates the use of CDO in standalone
>> environments:
>>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project
>
>
> No, I'm building an eclipse RCP app and I would like to make use of
> the niceties of OSGi. What is the right way to do that? That
> CDOSessionConfiguration looks like a lot of extra work.
Basically CDOSessionConfiguration is the way to go. The extra work is
needed to handle all the different extensibility dimensions. In the 2.0
stream there will also come an additional extensibility dimension to be
able to decouple CDO from Net4j and use other technologies like
direct/local communication or the ECF framework without going through Net4j.

Both Net4j and CDO try to separate the service aspects from the
component wiring. Actually there is only a single violation to this
concept:
org.eclipse.internal.net4j.connector.Connector.protocolFacto ryRegistry.
Most probably this one will be replaced by an IProtocolProvider during
the 2.0 stream, too.

While I think that the service aspects (API) are very optimized and
narrowed with respect to the needs of the application developer I always
felt that the wiring concepts are not very close to optimal. What makes
the story a challenge is that all components are supposed to run in very
different environments, for example pure OSGi, Eclipse, Web containers,
EJB containers or standalone. Depending of the environment I thought
about OSGi services, declarative services, Spring and Spring DM and
others. I'm very open to suggestins here.

Cheers
/Eike
Re: [CDO] Loss of connectivity hosing the client [message #126747 is a reply to message #126673] Mon, 07 July 2008 17:23 Go to previous messageGo to next message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Thomas Crockett schrieb:
>> Ok, I've tried the TCP connector and it still doesn't seem to work
>> very well when a disconnection occurs. For instance, I had open your
>> CDO UI and was examining and changing some objects in my model
>> repository. Then I closed my laptop and drove home from work. Now at
>> home, nothing works without restarting the app. Trying to open a new
>> transaction creates a job which spins forever. Same goes for trying to
>> close the current session. Attempting to open a new session does nothing.
> As I said in the other post we should look if we can make the CDO UI
> better when it comes to abnormal situations.
> I think that a Bugzilla on the EMF/CDO component is appropriate.

What I'm trying to say is that I don't think this is a UI issue at all, it
is a bug with some component of the core architecture: session, connector,
channel, or what, I'm not sure. I'm eager to hear that I'm actually wrong
about this and there is a way to regain a healthy connection once things
get out of step between client and server without restarting the whole
app, but until you tell me how to do that I will maintain that this is not
a UI issue ;)

>> As a side note, I'm wondering if it would be possible to write a
>> completely stateless connector, based on the principles of REST. Is
>> that feasible, or is the assumption of a long-lived, stateful
>> connection between the client and the server endemic to the
>> architecture of Net4j?
> I find this particular question hard to answer due to the extensible
> architecture of Net4j but I will try ;-)

> The transport core of Net4j could be characterized as a layer for
> asynchronous and bidirectional switching of buffers through virtual
> channels the latters potentially ending in separate VMs. The signalling
> layer on top of that provide a more convenient API to application
> protocol developers who want to think in terms of requests, optional
> responses and streams to transfer the signal data without worrying about
> the underlying characteristics of the transport.

> While an IChannel is the logical context for the buffer transfers they
> are delegated to an IChannelMultiplexer which is currently only
> implemented by the provided IConnectors (TCP, HTTP and JVM). In addition
> to channel multiplexing a connector manages the underlying physical
> connection and is, thus, the only concept that is not bidirectional.
> Consequently connectors have different implementations for the active
> (client) and the passive (server) side. Active connectors are *opened*
> by clients and passive connectors are *accepted* by IAcceptors.

> Back to your question:

> I don't think that anything in Net4j prevents a developer from
> developing REST style application protocols (note that HTTP usually also
> uses stateful TCP connections underneath). I think it depends more on
> the nature and requirements of the application that a protocol is
> developed for whether the protocol can be stateless or not.

> In the case of CDO I doubt that. Of course you can move any state
> management from the server to the clients if only you transfer enough
> data with each request. I'd say the current design (and possibly the sum
> of requirements) of CDO is not very well-suited for a REST-style
> protocol. Please consider essential (yet optional) features like
> asynchronous change notification and the like.

> Did that answer your question?

Yes, thanks!

> Cheers
> /Eike
Re: [CDO] Loss of connectivity hosing the client [message #126761 is a reply to message #126747] Mon, 07 July 2008 17:53 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Thomas Crockett schrieb:
>>> Ok, I've tried the TCP connector and it still doesn't seem to work
>>> very well when a disconnection occurs. For instance, I had open your
>>> CDO UI and was examining and changing some objects in my model
>>> repository. Then I closed my laptop and drove home from work. Now at
>>> home, nothing works without restarting the app. Trying to open a new
>>> transaction creates a job which spins forever. Same goes for trying
>>> to close the current session. Attempting to open a new session does
>>> nothing.
>> As I said in the other post we should look if we can make the CDO UI
>> better when it comes to abnormal situations.
>> I think that a Bugzilla on the EMF/CDO component is appropriate.
>
> What I'm trying to say is that I don't think this is a UI issue at
> all, it is a bug with some component of the core architecture:
> session, connector, channel, or what, I'm not sure. I'm eager to hear
> that I'm actually wrong about this and there is a way to regain a
> healthy connection once things get out of step between client and
> server without restarting the whole app, but until you tell me how to
> do that I will maintain that this is not a UI issue ;)
Ok, it seems that I still don't understand completely.
The "core" architecture of CDO (i.e. CDOSession) is not expected to
survive disconnects in the underlying Net4j transport layer.
Well, there's the concept of an IFailOverStrategy but this needs to be
re-thought in 2.0.
In the end that means that after the IChannel of the CDOSession has been
closed (for example due to network failure) it is not usable anymore and
you need a new one.

I have not tested what happens if the network failure coincidents entry
of standby mode on the client box (Windows?).
Do you have the feeling that this might cause a problem, say, because
the CDOSession does never receive the DEACTIVATED event of the IChannel?
Personally I think this is very unlikely.

In another discussion we have just realized that the default timeout for
most of the CDO read-access requests is NO_TIMEOUT which means "wait
forever".
That should certainly be changed.

In any way you should file a Bugzilla, UI-related or not ;-)

Cheers
/Eike
Re: [CDO] Loss of connectivity hosing the client [message #619335 is a reply to message #126491] Tue, 01 July 2008 08:19 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Addendum: On further experimentation I discovered that the editor that
comes shipped with CDO seems to handle dropouts just fine without having
to close/reopen transactions or sessions, so this appears to be yet
another case of CDO doing what it's supposed to as long one uses it
correctly, which I am apparently not :)
Re: [CDO] Loss of connectivity hosing the client [message #619336 is a reply to message #126506] Tue, 01 July 2008 15:51 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Hi Thomas,

I've added the EMF newsgroup to the recipients since EMF is the new home
base of CDO since it graduated from incubation.

CDO itself uses timeouts to cope with server processing and partial
network failure. So it's mainly an issue of setting appropriate timeouts.
In addition there is the Net4j concept of IFailoverStrategy which will
undergo a complete re-think during the 2.0 stream. Related Bugzillas:

201267: Failover strategy for CDO/NET4J
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201267

203167: Multiple CDO Servers (failover+loadbalancing)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203167

235042: Provide exchangeable protocol facade
https://bugs.eclipse.org/bugs/show_bug.cgi?id=235042

I also have the feeling that the most subtle challenge with respect to
synchronous/timed-out requests is in the UI and the correct usage of CDO.
Could you please elaborate a bit on your particular UI?

Cheers
/Eike


Thomas Crockett schrieb:
> Addendum: On further experimentation I discovered that the editor that
> comes shipped with CDO seems to handle dropouts just fine without
> having to close/reopen transactions or sessions, so this appears to be
> yet another case of CDO doing what it's supposed to as long one uses
> it correctly, which I am apparently not :)
>


Re: [CDO] Loss of connectivity hosing the client [message #619337 is a reply to message #126519] Tue, 01 July 2008 17:53 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
I'm getting this error a lot (even when using the shipped CDO editor) when
I force a dropout (by disconnecting my ethernet cable for instance):

[ERROR] java.io.IOException: Invalid operation code: 60
org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException: Invalid
operation code: 60
at
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
at
org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
at
org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
at
org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
at
org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
at
org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
at
org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
at
org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
at
org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
at
org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.io.IOException: Invalid operation code: 60
at
org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
at
org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
at
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
... 17 more
Re: [CDO] Loss of connectivity hosing the client [message #619338 is a reply to message #126519] Tue, 01 July 2008 18:12 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Could you please elaborate a bit on your particular UI?

My UI is a highly customized GEF editor that allows one to annotate images
(very large tiled images taken by robots in orbit and on the surface of
Mars, if you're curious :) My model is the annotations themselves; they
can be 3d points placed on the terrain, or 2d points tied to pixel
coordinates where range data is unavailable. The way one edits the model
is by dragging these image markers around, changing their names, etc. I
enforce that all edits to the model take place in the display thread.

Currently I have a singleton "PlacesManager" which basically wraps the
details of CDO and only exposes what's necessary. Its main API are
commit() and rollback(), the implementations of which defer to its
privately held CDOTransaction. It has a static CDOSession which it builds
as follows:

session = CDOSessionFactory.get(IPluginContainer.INSTANCE, uri);

When building the PlacesManager's transaction I use these options:

transaction.setInvalidationNotificationsEnabled(true);
transaction.setCommitTimeout(10000);

As a side note, I use setInvalidationNotificationsEnabled(true) so that
multiple users can annotate images collaboratively and see each others'
edits appear instantly on their screen--that feature is a big reason I
chose CDO in the first place :)

Any other info you need? I would just give you a full code dump but NASA
is fairly prickly about letting us release code, even when it has nothing
to do with flying spacecraft.

Tom
Re: [CDO] Loss of connectivity hosing the client [message #619339 is a reply to message #126531] Tue, 01 July 2008 18:18 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
And incidentally once I see this message the CDO editor is hosed :( I have
to restart to get it back into a working state. Should I post a bug for
this?

Thomas Crockett wrote:

> I'm getting this error a lot (even when using the shipped CDO editor) when
> I force a dropout (by disconnecting my ethernet cable for instance):

> [ERROR] java.io.IOException: Invalid operation code: 60
> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException: Invalid
> operation code: 60
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
> at
> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
> at
>
org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
> at
>
org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
> at
>
org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
> at
>
org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
> at
> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: Invalid operation code: 60
> at
>
org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
> at
>
org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
> ... 17 more
Re: [CDO] Loss of connectivity hosing the client [message #619340 is a reply to message #126531] Wed, 02 July 2008 06:48 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Hi Thomas,

I forgot to mention that the HTTP transport connector implementation is
brand new!
What you describe looks like a bug since a (partial) network failure
should not cause the client to die with an exception.
Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..." so
that you can track the progress.

Cheers
/Eike


Thomas Crockett schrieb:
> I'm getting this error a lot (even when using the shipped CDO editor)
> when I force a dropout (by disconnecting my ethernet cable for instance):
>
> [ERROR] java.io.IOException: Invalid operation code: 60
> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException:
> Invalid operation code: 60
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
>
> at
> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
>
> at
> org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
>
> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at
> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>
> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
>
> at
> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
>
> at
> org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
>
> at
> org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
>
> at
> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: java.io.IOException: Invalid operation code: 60
> at
> org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
>
> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
>
> ... 17 more
>


Re: [CDO] Loss of connectivity hosing the client [message #619341 is a reply to message #126556] Wed, 02 July 2008 06:51 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Hi Thomas,

In addition to fixing the root cause in the underlying transport (see my
other comment) we should look if we can make the CDO UI better when it
comes to abnormal situations. I suggest that a separate Bugzilla on the
EMF/CDO component is appropriate.

Cheers
/Eike



Thomas Crockett schrieb:
> And incidentally once I see this message the CDO editor is hosed :( I
> have to restart to get it back into a working state. Should I post a
> bug for this?
>
> Thomas Crockett wrote:
>
>> I'm getting this error a lot (even when using the shipped CDO editor)
>> when I force a dropout (by disconnecting my ethernet cable for
>> instance):
>
>> [ERROR] java.io.IOException: Invalid operation code: 60
>> org.eclipse.net4j.util.io.IORuntimeException: java.io.IOException:
>> Invalid operation code: 60
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:239)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.multiple xChannel(HTTPClientConnector.java:98)
>
>> at
>> org.eclipse.internal.net4j.channel.Channel.handleBuffer(Chan nel.java:157)
>>
>> at
>> org.eclipse.net4j.buffer.BufferOutputStream.flush(BufferOutp utStream.java:87)
>>
>> at
> org.eclipse.net4j.buffer.BufferOutputStream.flushWithEOS(Buf ferOutputStream.java:96)
>
>> at
> org.eclipse.net4j.signal.RequestWithConfirmation.execute(Req uestWithConfirmation.java:50)
>
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
>> at
>> org.eclipse.net4j.signal.SignalProtocol.startSignal(SignalPr otocol.java:236)
>>
>> 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.emf.internal.cdo.CDOSessionImpl.sendViewsNotific ation(CDOSessionImpl.java:781)
>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.attach(CDOSessio nImpl.java:626)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:304)
>>
>> at
>> org.eclipse.emf.internal.cdo.CDOSessionImpl.openView(CDOSess ionImpl.java:1)
>>
>> at
> org.eclipse.emf.cdo.internal.ui.actions.OpenViewAction.doRun (OpenViewAction.java:37)
>
>> at
> org.eclipse.net4j.util.ui.actions.LongRunningAction$1.run(Lo ngRunningAction.java:164)
>
>> at
>> org.eclipse.net4j.util.om.monitor.MonitoredJob.run(Monitored Job.java:48)
>> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
>> Caused by: java.io.IOException: Invalid operation code: 60
>> at
> org.eclipse.net4j.http.internal.common.HTTPConnector.readInp utOperations(HTTPConnector.java:171)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector$4.handle In(HTTPClientConnector.java:230)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.request( HTTPClientConnector.java:195)
>
>> at
> org.eclipse.net4j.internal.http.HTTPClientConnector.tryOpera tionsRequest(HTTPClientConnector.java:219)
>
>> ... 17 more
>
>


Re: [CDO] Loss of connectivity hosing the client [message #619342 is a reply to message #126544] Wed, 02 July 2008 07:12 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Thomas,

Comments below...


Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Could you please elaborate a bit on your particular UI?
>
> My UI is a highly customized GEF editor that allows one to annotate
> images (very large tiled images taken by robots in orbit and on the
> surface of Mars, if you're curious :) My model is the annotations
> themselves; they can be 3d points placed on the terrain, or 2d points
> tied to pixel coordinates where range data is unavailable. The way one
> edits the model is by dragging these image markers around, changing
> their names, etc. I enforce that all edits to the model take place in
> the display thread.
Hey that sounds like a really nice application!!
So your UI is completely self-made, as opposed to built on what CDO
provides.
Maybe it'd be a good idea to write some tutorial or thelike in the wiki
about how to build own UIs on top of CDO core, once we are through the
CDO "[UI] Improve stability on core failures" Bugzilla that you're going
to enter.


> Currently I have a singleton "PlacesManager" which basically wraps the
> details of CDO and only exposes what's necessary. Its main API are
> commit() and rollback(), the implementations of which defer to its
> privately held CDOTransaction. It has a static CDOSession which it
> builds as follows:
>
> session = CDOSessionFactory.get(IPluginContainer.INSTANCE, uri);
Are you building a standalone application (as opposed to be run in OSGi)?
org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
(OSGi and PDE would prevent you from having access to this class) and
you should use the CDOSessionConfiguration instead.
The examples plugin demonstrates the use of CDO in standalone environments:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project


> When building the PlacesManager's transaction I use these options:
>
> transaction.setInvalidationNotificationsEnabled(true);
> transaction.setCommitTimeout(10000);
>
> As a side note, I use setInvalidationNotificationsEnabled(true) so
> that multiple users can annotate images collaboratively and see each
> others' edits appear instantly on their screen--that feature is a big
> reason I chose CDO in the first place :)
The setInvalidationNotificationsEnabled(true) is convenience mechanism
to have a bit more of a distributed shared experience in unmodified EMF
editors out-of-the-box.
You might be able to build even better UIs if you register an IListener
or a CDOEventHandler directly with the CDOSession. See the CDOEditor for
an example (should also be part of the wiki).

Note that Simon is also working on (we plan to merge a first solution
this week):
233490: Change Subscription
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233490


> Any other info you need? I would just give you a full code dump but
> NASA is fairly prickly about letting us release code, even when it has
> nothing to do with flying spacecraft.
A pity that not everybody is committed to open source (other than just
using it) ;-)
Let's see if our work on Net4j HTTP and CDO UI stability is already
sufficient.


Cheers
/Eike


Re: [CDO] Loss of connectivity hosing the client [message #619345 is a reply to message #126592] Thu, 03 July 2008 12:49 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
>> Eike Stepper wrote:
>
> Are you building a standalone application (as opposed to be run in OSGi)?
> org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
> (OSGi and PDE would prevent you from having access to this class) and
> you should use the CDOSessionConfiguration instead.
> The examples plugin demonstrates the use of CDO in standalone environments:
>
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project

No, I'm building an eclipse RCP app and I would like to make use of the
niceties of OSGi. What is the right way to do that? That
CDOSessionConfiguration looks like a lot of extra work.
Re: [CDO] Loss of connectivity hosing the client [message #619346 is a reply to message #126570] Thu, 03 July 2008 13:04 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Hi Thomas,

> I forgot to mention that the HTTP transport connector implementation is
> brand new!
> What you describe looks like a bug since a (partial) network failure
> should not cause the client to die with an exception.
> Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..." so
> that you can track the progress.

Ok, I've tried the TCP connector and it still doesn't seem to work very
well when a disconnection occurs. For instance, I had open your CDO UI and
was examining and changing some objects in my model repository. Then I
closed my laptop and drove home from work. Now at home, nothing works
without restarting the app. Trying to open a new transaction creates a job
which spins forever. Same goes for trying to close the current session.
Attempting to open a new session does nothing.

As a side note, I'm wondering if it would be possible to write a
completely stateless connector, based on the principles of REST. Is that
feasible, or is the assumption of a long-lived, stateful connection
between the client and the server endemic to the architecture of Net4j?
Re: [CDO] Loss of connectivity hosing the client [message #619348 is a reply to message #126644] Fri, 04 July 2008 09:08 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Hi Thomas,
>
>> I forgot to mention that the HTTP transport connector implementation
>> is brand new!
>> What you describe looks like a bug since a (partial) network failure
>> should not cause the client to die with an exception.
>> Please file a Bugzilla on the EMF/Net4j component with "[HTTP] ..."
>> so that you can track the progress.
>
> Ok, I've tried the TCP connector and it still doesn't seem to work
> very well when a disconnection occurs. For instance, I had open your
> CDO UI and was examining and changing some objects in my model
> repository. Then I closed my laptop and drove home from work. Now at
> home, nothing works without restarting the app. Trying to open a new
> transaction creates a job which spins forever. Same goes for trying to
> close the current session. Attempting to open a new session does nothing.
As I said in the other post we should look if we can make the CDO UI
better when it comes to abnormal situations.
I think that a Bugzilla on the EMF/CDO component is appropriate.


> As a side note, I'm wondering if it would be possible to write a
> completely stateless connector, based on the principles of REST. Is
> that feasible, or is the assumption of a long-lived, stateful
> connection between the client and the server endemic to the
> architecture of Net4j?
I find this particular question hard to answer due to the extensible
architecture of Net4j but I will try ;-)

The transport core of Net4j could be characterized as a layer for
asynchronous and bidirectional switching of buffers through virtual
channels the latters potentially ending in separate VMs. The signalling
layer on top of that provide a more convenient API to application
protocol developers who want to think in terms of requests, optional
responses and streams to transfer the signal data without worrying about
the underlying characteristics of the transport.

While an IChannel is the logical context for the buffer transfers they
are delegated to an IChannelMultiplexer which is currently only
implemented by the provided IConnectors (TCP, HTTP and JVM). In addition
to channel multiplexing a connector manages the underlying physical
connection and is, thus, the only concept that is not bidirectional.
Consequently connectors have different implementations for the active
(client) and the passive (server) side. Active connectors are *opened*
by clients and passive connectors are *accepted* by IAcceptors.

Back to your question:

I don't think that anything in Net4j prevents a developer from
developing REST style application protocols (note that HTTP usually also
uses stateful TCP connections underneath). I think it depends more on
the nature and requirements of the application that a protocol is
developed for whether the protocol can be stateless or not.

In the case of CDO I doubt that. Of course you can move any state
management from the server to the clients if only you transfer enough
data with each request. I'd say the current design (and possibly the sum
of requirements) of CDO is not very well-suited for a REST-style
protocol. Please consider essential (yet optional) features like
asynchronous change notification and the like.

Did that answer your question?

Cheers
/Eike


Re: [CDO] Loss of connectivity hosing the client [message #619349 is a reply to message #126631] Fri, 04 July 2008 09:21 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Thomas Crockett schrieb:
>
>>> Eike Stepper wrote:
>>
>> Are you building a standalone application (as opposed to be run in
>> OSGi)?
>> org.eclipse.emf.internal.cdo.CDOSessionFactory is an internal class
>> (OSGi and PDE would prevent you from having access to this class) and
>> you should use the CDOSessionConfiguration instead.
>> The examples plugin demonstrates the use of CDO in standalone
>> environments:
>>
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/examples/org.eclipse.emf.cdo.examples/src/o rg/eclipse/emf/cdo/examples/?root=Modeling_Project
>
>
> No, I'm building an eclipse RCP app and I would like to make use of
> the niceties of OSGi. What is the right way to do that? That
> CDOSessionConfiguration looks like a lot of extra work.
Basically CDOSessionConfiguration is the way to go. The extra work is
needed to handle all the different extensibility dimensions. In the 2.0
stream there will also come an additional extensibility dimension to be
able to decouple CDO from Net4j and use other technologies like
direct/local communication or the ECF framework without going through Net4j.

Both Net4j and CDO try to separate the service aspects from the
component wiring. Actually there is only a single violation to this
concept:
org.eclipse.internal.net4j.connector.Connector.protocolFacto ryRegistry.
Most probably this one will be replaced by an IProtocolProvider during
the 2.0 stream, too.

While I think that the service aspects (API) are very optimized and
narrowed with respect to the needs of the application developer I always
felt that the wiring concepts are not very close to optimal. What makes
the story a challenge is that all components are supposed to run in very
different environments, for example pure OSGi, Eclipse, Web containers,
EJB containers or standalone. Depending of the environment I thought
about OSGi services, declarative services, Spring and Spring DM and
others. I'm very open to suggestins here.

Cheers
/Eike


Re: [CDO] Loss of connectivity hosing the client [message #619354 is a reply to message #126673] Mon, 07 July 2008 17:23 Go to previous message
Tom Crockett is currently offline Tom CrockettFriend
Messages: 54
Registered: July 2009
Member
Eike Stepper wrote:

> Thomas Crockett schrieb:
>> Ok, I've tried the TCP connector and it still doesn't seem to work
>> very well when a disconnection occurs. For instance, I had open your
>> CDO UI and was examining and changing some objects in my model
>> repository. Then I closed my laptop and drove home from work. Now at
>> home, nothing works without restarting the app. Trying to open a new
>> transaction creates a job which spins forever. Same goes for trying to
>> close the current session. Attempting to open a new session does nothing.
> As I said in the other post we should look if we can make the CDO UI
> better when it comes to abnormal situations.
> I think that a Bugzilla on the EMF/CDO component is appropriate.

What I'm trying to say is that I don't think this is a UI issue at all, it
is a bug with some component of the core architecture: session, connector,
channel, or what, I'm not sure. I'm eager to hear that I'm actually wrong
about this and there is a way to regain a healthy connection once things
get out of step between client and server without restarting the whole
app, but until you tell me how to do that I will maintain that this is not
a UI issue ;)

>> As a side note, I'm wondering if it would be possible to write a
>> completely stateless connector, based on the principles of REST. Is
>> that feasible, or is the assumption of a long-lived, stateful
>> connection between the client and the server endemic to the
>> architecture of Net4j?
> I find this particular question hard to answer due to the extensible
> architecture of Net4j but I will try ;-)

> The transport core of Net4j could be characterized as a layer for
> asynchronous and bidirectional switching of buffers through virtual
> channels the latters potentially ending in separate VMs. The signalling
> layer on top of that provide a more convenient API to application
> protocol developers who want to think in terms of requests, optional
> responses and streams to transfer the signal data without worrying about
> the underlying characteristics of the transport.

> While an IChannel is the logical context for the buffer transfers they
> are delegated to an IChannelMultiplexer which is currently only
> implemented by the provided IConnectors (TCP, HTTP and JVM). In addition
> to channel multiplexing a connector manages the underlying physical
> connection and is, thus, the only concept that is not bidirectional.
> Consequently connectors have different implementations for the active
> (client) and the passive (server) side. Active connectors are *opened*
> by clients and passive connectors are *accepted* by IAcceptors.

> Back to your question:

> I don't think that anything in Net4j prevents a developer from
> developing REST style application protocols (note that HTTP usually also
> uses stateful TCP connections underneath). I think it depends more on
> the nature and requirements of the application that a protocol is
> developed for whether the protocol can be stateless or not.

> In the case of CDO I doubt that. Of course you can move any state
> management from the server to the clients if only you transfer enough
> data with each request. I'd say the current design (and possibly the sum
> of requirements) of CDO is not very well-suited for a REST-style
> protocol. Please consider essential (yet optional) features like
> asynchronous change notification and the like.

> Did that answer your question?

Yes, thanks!

> Cheers
> /Eike
Re: [CDO] Loss of connectivity hosing the client [message #619355 is a reply to message #126747] Mon, 07 July 2008 17:53 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6496
Registered: July 2009
Senior Member
Thomas Crockett schrieb:
> Eike Stepper wrote:
>
>> Thomas Crockett schrieb:
>>> Ok, I've tried the TCP connector and it still doesn't seem to work
>>> very well when a disconnection occurs. For instance, I had open your
>>> CDO UI and was examining and changing some objects in my model
>>> repository. Then I closed my laptop and drove home from work. Now at
>>> home, nothing works without restarting the app. Trying to open a new
>>> transaction creates a job which spins forever. Same goes for trying
>>> to close the current session. Attempting to open a new session does
>>> nothing.
>> As I said in the other post we should look if we can make the CDO UI
>> better when it comes to abnormal situations.
>> I think that a Bugzilla on the EMF/CDO component is appropriate.
>
> What I'm trying to say is that I don't think this is a UI issue at
> all, it is a bug with some component of the core architecture:
> session, connector, channel, or what, I'm not sure. I'm eager to hear
> that I'm actually wrong about this and there is a way to regain a
> healthy connection once things get out of step between client and
> server without restarting the whole app, but until you tell me how to
> do that I will maintain that this is not a UI issue ;)
Ok, it seems that I still don't understand completely.
The "core" architecture of CDO (i.e. CDOSession) is not expected to
survive disconnects in the underlying Net4j transport layer.
Well, there's the concept of an IFailOverStrategy but this needs to be
re-thought in 2.0.
In the end that means that after the IChannel of the CDOSession has been
closed (for example due to network failure) it is not usable anymore and
you need a new one.

I have not tested what happens if the network failure coincidents entry
of standby mode on the client box (Windows?).
Do you have the feeling that this might cause a problem, say, because
the CDOSession does never receive the DEACTIVATED event of the IChannel?
Personally I think this is very unlikely.

In another discussion we have just realized that the default timeout for
most of the CDO read-access requests is NO_TIMEOUT which means "wait
forever".
That should certainly be changed.

In any way you should file a Bugzilla, UI-related or not ;-)

Cheers
/Eike


Previous Topic:[EMF Compare] Comparing restructured models
Next Topic:Status of JCR Mmgmt project?
Goto Forum:
  


Current Time: Sun May 24 23:30:47 GMT 2020

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

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

Back to the top