Home » Modeling » EMF » [CDO] Connection timeout
|
| Re: [CDO] Connection timeout [message #429333 is a reply to message #429299] |
Mon, 20 April 2009 06:32   |
|
This is a multi-part message in MIME format.
--------------010703090102000103010401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Egidijus,
If you have a Net4j-based CDOSession you can set the timeout on the
underlying Net4j ISignalProtocol:
session.options().getProtocol().setTimeout(1000L);
This applies to all read access signals. The only write access signal is
the CommitTransactionRequest which is prepared to handle larger amounts
of data properly without timeouts. I.e. the timeout counter is reset
periodically while the server is processing the commit data. I'm
currently not sure if there is an easy way to configure the respective
timeout value programmatically at runtime. --> bugzilla ;-)
In either case you should be able to recognize connection loss by
registering a listener to the IConnector, the IChannel or the IProtocol
of the CDOSession:
| EventUtil.addListener(session.options().getProtocol(), *new *LifecycleEventAdapter()
{
@Override
*protected **void *onDeactivated(ILifecycle lifecycle)
{
}
});|
If no fail-over support is configured, connection loss results in
deactivation of the CDOSession itself. so you can also add this listener
to the session.
Cheers
/Eike
----
http://thegordian.blogspot.com
Egidijus Vaisnora schrieb:
>
> I can provide timeout for opening channel
> ITCPConnector.setOpenChannelTimeout(), but I am not able to find
> timeout settings for data commit or reading. Is any available?
> At current time, if connection is lost and user attempts to
> commit, UI freezes (waits till commit completes) till connection is
> restored...
--------------010703090102000103010401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Egidijus,<br>
<br>
If you have a Net4j-based CDOSession you can set the timeout on the
underlying Net4j ISignalProtocol:<br>
<br>
session.options().getProtocol().setTimeout(1000L);<br>
<br>
This applies to all read access signals. The only write access signal
is the CommitTransactionRequest which is prepared to handle larger
amounts of data properly without timeouts. I.e. the timeout counter is
reset periodically while the server is processing the commit data. I'm
currently not sure if there is an easy way to configure the respective
timeout value programmatically at runtime. --> bugzilla ;-)<br>
<br>
In either case you should be able to recognize connection loss by
registering a listener to the IConnector, the IChannel or the IProtocol
of the CDOSession:<br>
<br>
<title></title>
<style type="text/css">
<!--code { font-family: Courier New, Courier; font-size: 10pt; margin: 0px; }-->
</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<!-- ======================================================== -->
<!-- = Java Sourcecode to HTML automatically converted code = --><!-- = Java2Html Converter 5.0 [2006-02-26] by Markus Gebhard markus@jave.de = -->
<!-- = Further information: http://www.java2html.de = -->
<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
<!-- start source code --> <td align="left" nowrap="nowrap"
valign="top"> <code><font color="#ffffff"> </font ><font
color="#000000">EventUtil.addListener</font><font color="#000000">(</font><font
color="#000000">session.options</font><font color="#000000">()</font><font
color="#000000">.getProtocol</font><font color="#000000">()</font><font
color="#000000">, </font><font color="#7f0055"><b>new </b></font><font
color="#000000">LifecycleEventAdapter</font><font color="#000000">()</font><br>
<font color="#ffffff"> </font ><font color="#000000">{</font><br>
<font color="#ffffff"> </font><font color="#646464">@Override</font><br>
<font color="#ffffff"> </font><font color="#7f0055"><b>protected </b></font><font
color="#7f0055"><b>void </b></font><font color="#000000">onDeactivated</font><font
color="#000000">(</font><font color="#000000">ILifecycle lifecycle</font><font
color="#000000">)</font><br>
<font color="#ffffff"> </font><font color="#000000">{</font><br>
<font color="#ffffff"> </font><font color="#000000">}</font><br>
<font color="#ffffff"> </font ><font color="#000000">})</font><font
color="#000000">;</font></code> </td>
<!-- end source code --> </tr>
</tbody>
</table>
</div>
<!-- = END of automatically generated HTML code = -->
<!-- ======================================================== --><br>
If no fail-over support is configured, connection loss results in
deactivation of the CDOSession itself. so you can also add this
listener to the session.<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<br>
<br>
<br>
Egidijus Vaisnora schrieb:
<blockquote cite="mid:gsa19r$6ch$1@build.eclipse.org" type="cite"><br>
I can provide timeout for opening channel
ITCPConnector.setOpenChannelTimeout(), but I am not able to find
timeout settings for data commit or reading. Is any available?
<br>
At current time, if connection is lost and user attempts to commit,
UI freezes (waits till commit completes) till connection is restored...
<br>
</blockquote>
</body>
</html>
--------------010703090102000103010401--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Connection timeout [message #429368 is a reply to message #429333] |
Tue, 21 April 2009 13:39 |
 Egidijus Vaisnora
Messages: 47
Registered: July 2009 |
Member |
|
|
Eike,
If I have correctly understood, if I am using CDO based session, then I am not able to handle timeout, right?
Actually , idea is not to customize timeout, but make proper feedback to user on time out: show dialog with actions like
"retry", "cancel" - in any case UI must be responsive even if connection is lost. It could be something like to pass my
commit/update strategy (like CDOTransactionStrategy), what my application must do, when timeout appeared. I suppose we shall
have new enhancment here :)
Thanks,
Eike Stepper wrote:
> Egidijus,
>
> If you have a Net4j-based CDOSession you can set the timeout on the
> underlying Net4j ISignalProtocol:
>
> session.options().getProtocol().setTimeout(1000L);
>
> This applies to all read access signals. The only write access signal is
> the CommitTransactionRequest which is prepared to handle larger amounts
> of data properly without timeouts. I.e. the timeout counter is reset
> periodically while the server is processing the commit data. I'm
> currently not sure if there is an easy way to configure the respective
> timeout value programmatically at runtime. --> bugzilla ;-)
>
> In either case you should be able to recognize connection loss by
> registering a listener to the IConnector, the IChannel or the IProtocol
> of the CDOSession:
>
> | EventUtil.addListener(session.options().getProtocol(), *new *LifecycleEventAdapter()
> {
> @Override
> *protected **void *onDeactivated(ILifecycle lifecycle)
> {
> }
> });|
>
>
> If no fail-over support is configured, connection loss results in
> deactivation of the CDOSession itself. so you can also add this listener
> to the session.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>
> Egidijus Vaisnora schrieb:
>>
>> I can provide timeout for opening channel
>> ITCPConnector.setOpenChannelTimeout(), but I am not able to find
>> timeout settings for data commit or reading. Is any available?
>> At current time, if connection is lost and user attempts to
>> commit, UI freezes (waits till commit completes) till connection is
>> restored...
|
|
|
| Re: [CDO] Connection timeout [message #429503 is a reply to message #429368] |
Fri, 24 April 2009 09:12 |
|
Egidijus Vaisnora schrieb:
> Eike,
>
> If I have correctly understood, if I am using CDO based session,
Do you mean a Net4j-based CDOSession?
> then I am not able to handle timeout, right?
> Actually , idea is not to customize timeout, but make proper
> feedback to user on time out: show dialog with actions like "retry",
> "cancel" - in any case UI must be responsive even if connection is
> lost. It could be something like to pass my commit/update strategy
> (like CDOTransactionStrategy), what my application must do, when
> timeout appeared. I suppose we shall have new enhancment here :)
I never thought about using a custom CDOTransactionStrategy for this
purpose, though it might be possible. Simon, can you comment on this?
I have the feeling what's really missing is a good strategy for
exceptions and exception handling within CDO. Can you file an
enhancement request where we can start a discussion around this topic?
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> Thanks,
>
> Eike Stepper wrote:
>> Egidijus,
>>
>> If you have a Net4j-based CDOSession you can set the timeout on the
>> underlying Net4j ISignalProtocol:
>>
>> session.options().getProtocol().setTimeout(1000L);
>>
>> This applies to all read access signals. The only write access signal
>> is the CommitTransactionRequest which is prepared to handle larger
>> amounts of data properly without timeouts. I.e. the timeout counter
>> is reset periodically while the server is processing the commit data.
>> I'm currently not sure if there is an easy way to configure the
>> respective timeout value programmatically at runtime. --> bugzilla ;-)
>>
>> In either case you should be able to recognize connection loss by
>> registering a listener to the IConnector, the IChannel or the
>> IProtocol of the CDOSession:
>>
>> | EventUtil.addListener(session.options().getProtocol(), *new
>> *LifecycleEventAdapter()
>> {
>> @Override
>> *protected **void *onDeactivated(ILifecycle lifecycle)
>> {
>> }
>> });|
>>
>>
>> If no fail-over support is configured, connection loss results in
>> deactivation of the CDOSession itself. so you can also add this
>> listener to the session.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>
>> Egidijus Vaisnora schrieb:
>>>
>>> I can provide timeout for opening channel
>>> ITCPConnector.setOpenChannelTimeout(), but I am not able to find
>>> timeout settings for data commit or reading. Is any available?
>>> At current time, if connection is lost and user attempts to
>>> commit, UI freezes (waits till commit completes) till connection is
>>> restored...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Connection timeout [message #429558 is a reply to message #429503] |
Fri, 24 April 2009 15:00 |
Egidijus Vaisnora
Messages: 47
Registered: July 2009 |
Member |
|
|
Added enchantment request at https://bugs.eclipse.org/bugs/show_bug.cgi?id=273594
> Do you mean a Net4j-based CDOSession?
Seems it is Net4j-based session... At least it has getProtocol().setTimeout() :). Ok, I have possibility to change timeout for
reading data. But still there are no commit timeout... Should I add as separate issue to bugzilla or let it be part of reported
enchantment?
Eike Stepper wrote:
> Egidijus Vaisnora schrieb:
>> Eike,
>>
>> If I have correctly understood, if I am using CDO based session,
> Do you mean a Net4j-based CDOSession?
>
>> then I am not able to handle timeout, right?
>> Actually , idea is not to customize timeout, but make proper
>> feedback to user on time out: show dialog with actions like "retry",
>> "cancel" - in any case UI must be responsive even if connection is
>> lost. It could be something like to pass my commit/update strategy
>> (like CDOTransactionStrategy), what my application must do, when
>> timeout appeared. I suppose we shall have new enhancment here :)
> I never thought about using a custom CDOTransactionStrategy for this
> purpose, though it might be possible. Simon, can you comment on this?
>
> I have the feeling what's really missing is a good strategy for
> exceptions and exception handling within CDO. Can you file an
> enhancement request where we can start a discussion around this topic?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
>
>
>> Thanks,
>>
>> Eike Stepper wrote:
>>> Egidijus,
>>>
>>> If you have a Net4j-based CDOSession you can set the timeout on the
>>> underlying Net4j ISignalProtocol:
>>>
>>> session.options().getProtocol().setTimeout(1000L);
>>>
>>> This applies to all read access signals. The only write access signal
>>> is the CommitTransactionRequest which is prepared to handle larger
>>> amounts of data properly without timeouts. I.e. the timeout counter
>>> is reset periodically while the server is processing the commit data.
>>> I'm currently not sure if there is an easy way to configure the
>>> respective timeout value programmatically at runtime. --> bugzilla ;-)
>>>
>>> In either case you should be able to recognize connection loss by
>>> registering a listener to the IConnector, the IChannel or the
>>> IProtocol of the CDOSession:
>>>
>>> | EventUtil.addListener(session.options().getProtocol(), *new
>>> *LifecycleEventAdapter()
>>> {
>>> @Override
>>> *protected **void *onDeactivated(ILifecycle lifecycle)
>>> {
>>> }
>>> });|
>>>
>>>
>>> If no fail-over support is configured, connection loss results in
>>> deactivation of the CDOSession itself. so you can also add this
>>> listener to the session.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>>
>>>
>>>
>>> Egidijus Vaisnora schrieb:
>>>> I can provide timeout for opening channel
>>>> ITCPConnector.setOpenChannelTimeout(), but I am not able to find
>>>> timeout settings for data commit or reading. Is any available?
>>>> At current time, if connection is lost and user attempts to
>>>> commit, UI freezes (waits till commit completes) till connection is
>>>> restored...
|
|
|
| Re: [CDO] Connection timeout [message #429568 is a reply to message #429558] |
Fri, 24 April 2009 19:51 |
|
Egidijus Vaisnora schrieb:
> Added enchantment request at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=273594
>
> > Do you mean a Net4j-based CDOSession?
>
> Seems it is Net4j-based session... At least it has
> getProtocol().setTimeout() :). Ok, I have possibility to change
> timeout for reading data. But still there are no commit timeout...
> Should I add as separate issue to bugzilla or let it be part of
> reported enchantment?
Yes, be so kind ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> Eike Stepper wrote:
>> Egidijus Vaisnora schrieb:
>>> Eike,
>>>
>>> If I have correctly understood, if I am using CDO based session,
>> Do you mean a Net4j-based CDOSession?
>>
>>> then I am not able to handle timeout, right?
>>> Actually , idea is not to customize timeout, but make proper
>>> feedback to user on time out: show dialog with actions like "retry",
>>> "cancel" - in any case UI must be responsive even if connection is
>>> lost. It could be something like to pass my commit/update strategy
>>> (like CDOTransactionStrategy), what my application must do, when
>>> timeout appeared. I suppose we shall have new enhancment here :)
>> I never thought about using a custom CDOTransactionStrategy for this
>> purpose, though it might be possible. Simon, can you comment on this?
>>
>> I have the feeling what's really missing is a good strategy for
>> exceptions and exception handling within CDO. Can you file an
>> enhancement request where we can start a discussion around this topic?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>>
>>
>>> Thanks,
>>>
>>> Eike Stepper wrote:
>>>> Egidijus,
>>>>
>>>> If you have a Net4j-based CDOSession you can set the timeout on the
>>>> underlying Net4j ISignalProtocol:
>>>>
>>>> session.options().getProtocol().setTimeout(1000L);
>>>>
>>>> This applies to all read access signals. The only write access signal
>>>> is the CommitTransactionRequest which is prepared to handle larger
>>>> amounts of data properly without timeouts. I.e. the timeout counter
>>>> is reset periodically while the server is processing the commit data.
>>>> I'm currently not sure if there is an easy way to configure the
>>>> respective timeout value programmatically at runtime. --> bugzilla ;-)
>>>>
>>>> In either case you should be able to recognize connection loss by
>>>> registering a listener to the IConnector, the IChannel or the
>>>> IProtocol of the CDOSession:
>>>>
>>>> | EventUtil.addListener(session.options().getProtocol(), *new
>>>> *LifecycleEventAdapter()
>>>> {
>>>> @Override
>>>> *protected **void *onDeactivated(ILifecycle lifecycle)
>>>> {
>>>> }
>>>> });|
>>>>
>>>>
>>>> If no fail-over support is configured, connection loss results in
>>>> deactivation of the CDOSession itself. so you can also add this
>>>> listener to the session.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>>
>>>>
>>>>
>>>> Egidijus Vaisnora schrieb:
>>>>> I can provide timeout for opening channel
>>>>> ITCPConnector.setOpenChannelTimeout(), but I am not able to find
>>>>> timeout settings for data commit or reading. Is any available?
>>>>> At current time, if connection is lost and user attempts to
>>>>> commit, UI freezes (waits till commit completes) till connection is
>>>>> restored...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Connection timeout [message #642350 is a reply to message #429333] |
Tue, 30 November 2010 22:27 |
Andy Condon
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Eike,
I've added a listener to the EventUtil to detect both onAboutToDeactivate and onDeactivated, but now I'm wondering what would be the best way to handle such scenarios. I'm also a little curious what is causing the de-activation in first place. The session doesn't seem to be de-activated when I disconnect the network to the client, rather it just seems to happen after a period (how long I haven't nailed down yet) of inactivity. When I disconnect and reconnect the network, the session seems to hang and recover when network is restored, which is what I would want it to do.
My goal is to have the application stay up indefinatly, and if connectivity problems happen the application should handle those as transparently as possible. As I said before, my EventUtil listener is catching the events I am having troubles with, now I just want to make sure the session stays alive in those scenarios if possible. You mentioned failover strategies, is there something built in that could be helping me?
Thanks for the great work with CDO!
Andy
|
|
|
| Re: [CDO] Connection timeout [message #642403 is a reply to message #642350] |
Wed, 01 December 2010 07:58 |
|
Hi Andy,
In the recent past we've added several mechanisms that help with reconnects or fail-over. There's no documentation, yet, but Caspar may want to give some string pointers.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 30.11.2010 23:27, schrieb Andy Condon:
> Eike,
>
> I've added a listener to the EventUtil to detect both onAboutToDeactivate and onDeactivated, but now I'm wondering what would be the best way to handle such scenarios. I'm also a little curious what is causing the de-activation in first place. The session doesn't seem to be de-activated when I disconnect the network to the client, rather it just seems to happen after a period (how long I haven't nailed down yet) of inactivity. When I disconnect and reconnect the network, the session seems to hang and recover when network is restored, which is what I would want it to do.
>
> My goal is to have the application stay up indefinatly, and if connectivity problems happen the application should handle those as transparently as possible. As I said before, my EventUtil listener is catching the events I am having troubles with, now I just want to make sure the session stays alive in those scenarios if possible. You mentioned failover strategies, is there something built in that could be helping me?
>
> Thanks for the great work with CDO!
>
> Andy
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Connection timeout [message #642438 is a reply to message #642403] |
Wed, 01 December 2010 10:52 |
Caspar D.
Messages: 35
Registered: July 2009 |
Member |
|
|
Use a 'ReconnectingCDOSession'.
Call CDONet4JUtil.createReconnectingSessionConfiguration(*) to obtain
a config that will instantiate one.
This kind of session will make a configurable number of attempts to
reconnect, at a configurable interval. See the setters on the config's
interface ReconnectingCDOSessionConfiguration.
While the session is busy trying to reconnect, your app will have to
deal with the user somehow, e.g. disable the UI or whatever is
appropriate. You can listen for CDOSessionRecoveryEvent.Type.STARTED
and FINISHED to trigger such a mechanism.
If anything's not self-explanatory, let me know..
--
Caspar
On 12/01/2010 02:58 PM, Eike Stepper wrote:
> Hi Andy,
>
> In the recent past we've added several mechanisms that help with
> reconnects or fail-over. There's no documentation, yet, but Caspar may
> want to give some string pointers.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 30.11.2010 23:27, schrieb Andy Condon:
>> Eike,
>>
>> I've added a listener to the EventUtil to detect both
>> onAboutToDeactivate and onDeactivated, but now I'm wondering what
>> would be the best way to handle such scenarios. I'm also a little
>> curious what is causing the de-activation in first place. The session
>> doesn't seem to be de-activated when I disconnect the network to the
>> client, rather it just seems to happen after a period (how long I
>> haven't nailed down yet) of inactivity. When I disconnect and
>> reconnect the network, the session seems to hang and recover when
>> network is restored, which is what I would want it to do.
>>
>> My goal is to have the application stay up indefinatly, and if
>> connectivity problems happen the application should handle those as
>> transparently as possible. As I said before, my EventUtil listener is
>> catching the events I am having troubles with, now I just want to make
>> sure the session stays alive in those scenarios if possible. You
>> mentioned failover strategies, is there something built in that could
>> be helping me?
>>
>> Thanks for the great work with CDO!
>>
>> Andy
|
|
|
| Re: [CDO] Connection timeout [message #642488 is a reply to message #642438] |
Wed, 01 December 2010 14:48 |
Andy Condon
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
That looks like exactly what I need and more. Thank you Caspar, that will be very useful.
Unfortunately I forgot to mention I'm on the released version of CDO - 3.0.1 and EMF - 2.6.0. Is there the possibility of things working if I just pull in the latest org.eclipse.emf.cdo.net4j plugin from CVS, or do I need to wait for all of CDO 4.0? I'd like not to have to upgrade the server and I'm wanting to use released versions of software when possible.
Thanks,
Andy
Update
To answer my own question, I pulled in the following plugins from CVS:
org.eclipse.emf.cdo
org.eclipse.emf.cdo.common
org.eclipse.emf.cdo.net4j
org.eclipse.emf.net4j
org.eclipse.emf.net4j.util
Things seem to be working so far, I have yet to try Caspar's new session configurations. I'll update with my results.
[Updated on: Wed, 01 December 2010 16:56] Report message to a moderator |
|
| |
| Re: [CDO] Connection timeout [message #642652 is a reply to message #642557] |
Thu, 02 December 2010 07:36 |
|
Am 01.12.2010 20:00, schrieb Andy Condon:
> No such luck. When I try to access createReconnectingSessionConfiguration I get a NoSuchMethodError.
I'm afraid it would not be easy to port this back to 3.0.
> The way I pulled in the CDO 4.0 stuff was just through the CVS import tool, I didn't go through the steps here: http://wiki.eclipse.org/CDO_Source_Installation I'm sure if I did things according to those directions things might work, but I probably shouldn't be using HEAD for production anyway.
Our release engineer mentioned that our automated weekly integration builds will be available again soon. In te meantime you could use 4.0 milestone builds or N-builds from the continous integration.
> I don't suppose the enhanced session configurations could be merged into a CDO/Net4j 3.0.2 or 3.1.0 release in the near future could they? :roll:
No way. That would break binary compatibility and that's not allowed in maintenance ;-(
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> In the meantime, I'll have to create a workaround.
>
> Here's the error I got but I'm sure it's just because I wasn't following the rules:
> java.lang.NoSuchMethodError: org.eclipse.emf.cdo.net4j.CDONet4jUtil.createReconnectingSes sionConfiguration(Ljava/lang/String;Ljava/lang/String;Lorg/e clipse/net4j/util/container/IManagedContainer;)Lorg/eclipse/ emf/cdo/net4j/ReconnectingCDOSessionConfiguration;
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Connection timeout [message #643872 is a reply to message #642801] |
Wed, 08 December 2010 14:47 |
Andy Condon
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
I apologize ahead of time for the long post, and thanks for your responses to my earlier posts:
On the side, while trying out ReconnectingSessionConfiguration, I'm trying another solution to my problem which doesn't involve using a ReconnectingSessionConfiguration. The RetryFailOverStrategy has been available since 2.0, but I'm not sure yet if it will get me around my problem of the session closing after around an hour.
ReconnectingSessionConfiguration looks more robust (albiet the source is more complicated). I'm curious what scenario prompted its implementation, and how that was different than what RetryFailOverStrategy was intended to resolve. I still haven't figured out exactly what is causing my timeout problem in the first place. As I said in my earlier posts, pulling the network cable doesn't do it, even in the middle of getting data from the resource. Am I being deactivated by the server maybe? How would I check? I'm also wondering what test methods were used to reproduce the scenario for the reason behind ReconnectingSessionConfiguration.
I only encounter my problem with the session deactivating after a long period (around an hour). This was difficult and time consuming to reproduce so I decided to try testing through deactivating the session directly by calling deactivate(). That doesn't work though because deactivating the session closes all the views first. I was running into a problem with the views and transactions being deactivated before the RecoveringCDOSession had a chance to store them for resurrection later.
The code that stores the open views this is here (from RecoveringCDOSessionImpl):
protected List<AfterRecoveryRunnable> recoverSession()
{
try
{
List<AfterRecoveryRunnable> runnables = new ArrayList<AfterRecoveryRunnable>();
for (InternalCDOView view : getViews())
{
runnables.add(new OpenViewRunnable(view));
}
updateConnectorAndRepositoryName();
openSession();
return runnables;
}
catch (RuntimeException ex)
{
deactivate();
throw ex;
}
catch (Error ex)
{
deactivate();
throw ex;
}
}
When getViews() is called to retrieve the open views and transactions, it runs into an InvalidStateException being thrown by the call to checkActive() in CDOSessionImpl.getViews() because the view or transaction is already inactive. Modifying IListener sessionProtocolListener in RecoveringCDOSessionImpl to override onAboutToDeactivate() instead of onDeactivated does not change this behavior, at least the way I was testing.
Do you have suggestions for a better way to test? With the InvalidStateException stopping access to the private Set<InternalCDOView> in CDOSessionImpl, the views and transacations will not recover.
I appreciate any insight,
Andy
|
|
|
| Re: [CDO] Connection timeout [message #643940 is a reply to message #643872] |
Wed, 08 December 2010 18:16 |
|
Am 08.12.2010 15:47, schrieb Andy Condon:
> I apologize ahead of time for the long post, and thanks for your responses to my earlier posts:
>
> On the side, while trying out ReconnectingSessionConfiguration, I'm trying another solution to my problem which doesn't involve using a ReconnectingSessionConfiguration. The RetryFailOverStrategy has been available since 2.0, but I'm not sure yet if it will get me around my problem of the session closing after around an hour.
IIRC our attempts to provide fail-over mechanisms before and including 3.0 were not very successful. You should not rely on them.
>
> ReconnectingSessionConfiguration looks more robust (albiet the source is more complicated).
Yes, that's the new and only working mechanism.
> I'm curious what scenario prompted its implementation, and how that was different than what RetryFailOverStrategy was intended to resolve.
The old IFailOverStrategy mechanism was purely based on the lower client networking layer. It turned out that higher layers and eventually the server needed to be involved.
> I still haven't figured out exactly what is causing my timeout problem in the first place. As I said in my earlier posts, pulling the network cable doesn't do it, even in the middle of getting data from the resource. Am I being deactivated by the server maybe? How would I check?
Basically all components on the server and the client implement ILifecycle, so you can hook your on LifecycleEventAdapter and track what's going on.
> I'm also wondering what test methods were used to reproduce the scenario for the reason behind ReconnectingSessionConfiguration.
Only Caspar could tell that. I remeber him mentioning that his company recently blocked all newsgroup traffic. I CC'ed him nevertheless...
>
> I only encounter my problem with the session deactivating after a long period (around an hour).
Note that you can also use the HeartBeatProtocol on the connector that serves your CDOSession to prevent network initiated idle timeouts proactively.
> This was difficult and time consuming to reproduce so I decided to try testing through deactivating the session directly by calling deactivate().
Deactivating the underlying IChannel or IConnector seems more realistic.
> That doesn't work though because deactivating the session closes all the views first. I was running into a problem with the views and transactions being deactivated before the RecoveringCDOSession had a chance to store them for resurrection later.
If you encounter issues with the mechanisms we are providing please submit a bugzilla with a detailed description on how to reproduce the issue.
>
> The code that stores the open views this is here (from RecoveringCDOSessionImpl):
>
> protected List<AfterRecoveryRunnable> recoverSession()
> {
> try
> {
> List<AfterRecoveryRunnable> runnables = new ArrayList<AfterRecoveryRunnable>();
> for (InternalCDOView view : getViews())
> {
> runnables.add(new OpenViewRunnable(view));
> }
>
> updateConnectorAndRepositoryName();
> openSession();
>
> return runnables;
> }
> catch (RuntimeException ex)
> {
> deactivate();
> throw ex;
> }
> catch (Error ex)
> {
> deactivate();
> throw ex;
> }
> }
>
>
> When getViews() is called to retrieve the open views and transactions, it runs into an InvalidStateException being thrown by the call to checkActive() in CDOSessionImpl.getViews() because the view or transaction is already inactive. Modifying IListener sessionProtocolListener in RecoveringCDOSessionImpl to override onAboutToDeactivate() instead of onDeactivated does not change this behavior, at least the way I was testing.
>
> Do you have suggestions for a better way to test?
Please see above.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> With the InvalidStateException stopping access to the private Set<InternalCDOView> in CDOSessionImpl, the views and transacations will not recover.
>
> I appreciate any insight,
>
> Andy
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Connection timeout [message #644004 is a reply to message #643872] |
Thu, 09 December 2010 02:52 |
Caspar D.
Messages: 35
Registered: July 2009 |
Member |
|
|
> ReconnectingSessionConfiguration looks more robust (albiet the
> source is more complicated). I'm curious what scenario prompted its
> implementation,
"Some" physical failure of the network connection.
> I still haven't figured out exactly what is causing my timeout
> problem in the first place. As I said in my earlier posts, pulling
> the network cable doesn't do it,
What happens when you pull the cable, is platform dependent, and also
depends on where you pull it (i.e. client-end, server-end, or
somewhere along the route). Generally speaking, Windows is more eager
to invalidate sockets than Linux, which means pulling the cable
*might* cause some IOException on Win, while on Linux it almost
certainly won't.
> even in the middle of getting data from the resource.
I don't think you can really be sure you're "in the middle" anyway.
There is buffering at many layers, and the actual physical
transmission is in bursts of short duration. And even if you manage to
physically interrupt an Ethernet transmission, the OS's network stack
will initially try to recover from that itself, without informing the
JVM.
> Am I being deactivated by the server maybe?
Could be.
> How would I check?
Set a breakpoint in doDeactivate(), and wait for it to happen. Then,
inspect the call stack to see what triggers it. It's probably either
an exception or the indicating() phase of a signal.
> I'm also wondering what test methods were used to reproduce the
> scenario for the reason behind ReconnectingSessionConfiguration.
The "test methods" were to run the client and server on separate
machines, pull the network cable from either machine, then (if that
doesn't trigger the recovery mechanism yet, which it might if it's
Windows) trigger it by invoking some activity (e.g. fetching an object
from the server) which will time out, then replug the cable and verify
that the recovery succeeds.
> I only encounter my problem with the session deactivating after a
> long period (around an hour). This was difficult and time consuming
> to reproduce so I decided to try testing through deactivating the
> session directly by calling deactivate().
It seems to me you need to find out *what* causes the deactivation and
dealing with that cause, rather than dealing with the deactivation
(which is too late).
A ReconnectionCDOSession takes exactly this approach: it prevents
deactivation of the session by replacing its Connector and Protocol
when those underlying components get deactivated.
If you really can't reproduce it "naturally", try deactivating the
TCPConnector as Eike suggested.
> That doesn't work though because deactivating the session closes all
> the views first.
Yep.
> Do you have suggestions for a better way to test?
See above. Set a breakpoint in doDeactivate() and wait for it to
happen.
Best regards
--
Caspar
|
|
| |
| Re: [CDO] Connection timeout [message #644179 is a reply to message #644174] |
Thu, 09 December 2010 18:59 |
|
Am 09.12.2010 19:29, schrieb Andy Condon:
> Thanks, you guys are the best! That information has helped me a lot and I'll post with my final conclusions for my testing. :d
>
> Not sure if you'll like this or not but I've been experimenting with writing a backport of ReconnectingCDOSession and RecoveringCDOSession that sits on top of the 3.0 cdo.net4j plugin. If it's not something that you like, that's ok. It's helped me quite a bit to learn how all this stuff works. Otherwise, I can probably send it your way if you think it would be useful.
As your code would certainly break binary 3.0 compatibility we can not include it in the regular code base and build. I could imagine that others might be interested and the Wiki would be a good place to host a zip until everybody can switch to 4.0 ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Connection timeout [message #644253 is a reply to message #644193] |
Fri, 10 December 2010 08:39 |
|
Am 09.12.2010 20:50, schrieb Andy Condon:
> Ok, thanks. That's what I'll do pending I can get everything running smoothly.
>
> So far it's detecting deactivation and recovering the session and views/transactions as it should. You're suggestion for closing the IConnector has sped up testing immensely.
>
> session.getConnector().close();
>
>
> One part I had to do differently was modify how the views from the old session were being saved. I had to do that separately in onAboutToDeactiviate, and then recover the session in onDeactivated.
>
> The last part (knock on wood) I have to get working is re-pointing old references to the new views/transactions. Right now, the views are opened, but references to the old views via stored EObjects abound throughout the client code. I'll keep digging into how this is accomplished in the 4.0 code.
As views can also be referenced directly from an application I doubt that our 4.0 fail-over mechanism closes them and opens new ones. Why is that necessary for you?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
| Re: [CDO] Connection timeout [message #644411 is a reply to message #644395] |
Sat, 11 December 2010 01:19 |
Andy Condon
Messages: 18
Registered: July 2009 |
Junior Member |
|
|
Actually, I've found that my problems stem from changes I had to make to RecoveringCDOSessionImpl in order to work with the 3.0 versions of the session and session configuration implementations. I was working around the fact that those classes had been refactored for 4.0, however the changes done in the refactor are critical to allow session recovery to happen. I concede defeat. At least I can't say I wasn't forewarned.
Thanks for your time. If nothing else, I've learned a bit more about how CDO works, which will benefit how my client code inter-ops with it.
Andy
[Updated on: Sat, 11 December 2010 01:21] Report message to a moderator |
|
|
| Re: [CDO] Connection timeout [message #644431 is a reply to message #644393] |
Sat, 11 December 2010 07:42 |
|
Hi Andy,
Comments below...
Am 10.12.2010 21:48, schrieb Andy Condon:
> Quote:
>> As views can also be referenced directly from an application I doubt that our 4.0 fail-over mechanism closes them and opens new ones. Why is that necessary for you?
>
>
> I guess I might be confused but isn't that what the code posted in message #643872 does? That code is straight from the 4.0 implementation of RecoveringCDOSessionImpl. I'll post it again here, sorry if I'm missing something but that's how I understand it to be working.
>
>
> protected List<AfterRecoveryRunnable> recoverSession()
> {
> try
> {
> List<AfterRecoveryRunnable> runnables = new ArrayList<AfterRecoveryRunnable>();
> for (InternalCDOView view : getViews())
> {
> runnables.add(new OpenViewRunnable(view));
OpenViewRunnable uses the existing client view to create a new matching view in the (potentially new) server. The point of the recovery mechanism is that all client facilities are kept unchanged except for the sessionProtocol to the server.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> }
>
> updateConnectorAndRepositoryName();
> openSession();
>
> return runnables;
> }
> catch (RuntimeException ex)
> {
> deactivate();
> throw ex;
> }
> catch (Error ex)
> {
> deactivate();
> throw ex;
> }
> }
>
>
> I would think somehow the new session would either need to re-spawn new views or point the original views at the new session. I'm running into trouble when re-spawing new views because all the EObjects are still pointed at the de-activated ones. This stack trace shows that happening:
>
>
> !ENTRY org.eclipse.core.databinding.observable 4 2 2010-12-10 13:26:35.651
> !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.databinding.observable".
> !STACK 0
> java.lang.IllegalStateException: Not active: CDOTransaction[488:1]
> at org.eclipse.net4j.util.lifecycle.LifecycleUtil.checkActive(L ifecycleUtil.java:71)
> at org.eclipse.net4j.util.lifecycle.Lifecycle.checkActive(Lifec ycle.java:190)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.getStore(CDOVi ewImpl.java:269)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.cdoStore(CDOObjec tImpl.java:1025)
> at org.eclipse.emf.internal.cdo.CDOObjectImpl.eStore(CDOObjectI mpl.java:580)
> at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreELis t.eStore(EStoreEObjectImpl.java:155)
> at org.eclipse.emf.ecore.impl.EStoreEObjectImpl$BasicEStoreELis t.delegateToArray(EStoreEObjectImpl.java:309)
> at org.eclipse.emf.common.util.DelegatingEList.toArray(Delegati ngEList.java:188)
> at org.eclipse.emf.ecore.util.DelegatingEcoreEList.toArray(Dele gatingEcoreEList.java:331)
> at java.util.Collections$UnmodifiableCollection.toArray(Collect ions.java:1017)
> at java.util.ArrayList.<init>(ArrayList.java:151)
> at org.eclipse.core.internal.databinding.property.list.SimplePr opertyObservableList$3.run(SimplePropertyObservableList.java :93)
> at org.eclipse.core.databinding.observable.Realm$1.run(Realm.ja va:148)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.databinding.observable.Realm.safeRun(Realm. java:152)
> at org.eclipse.core.databinding.observable.Realm.exec(Realm.jav a:170)
> at org.eclipse.core.internal.databinding.property.list.SimplePr opertyObservableList.firstListenerAdded(SimplePropertyObserv ableList.java:91)
> at org.eclipse.core.databinding.observable.list.AbstractObserva bleList$PrivateChangeSupport.firstListenerAdded(AbstractObse rvableList.java:52)
> at org.eclipse.core.databinding.observable.ChangeManager.addLis tener(ChangeManager.java:70)
> at org.eclipse.core.databinding.observable.ChangeSupport.addLis tener(ChangeSupport.java:30)
> at org.eclipse.core.databinding.observable.list.AbstractObserva bleList.addListChangeListener(AbstractObservableList.java:10 3)
> at org.eclipse.core.databinding.observable.list.DecoratingObser vableList.firstListenerAdded(DecoratingObservableList.java:7 5)
> at org.eclipse.core.databinding.observable.ChangeManager.addLis tener(ChangeManager.java:70)
> at org.eclipse.core.databinding.observable.list.DecoratingObser vableList.addListChangeListener(DecoratingObservableList.jav a:48)
> at org.eclipse.jface.databinding.viewers.ObservableListTreeCont entProvider$Impl.addCollectionChangeListener(ObservableListT reeContentProvider.java:170)
> at org.eclipse.jface.internal.databinding.viewers.ObservableCol lectionTreeContentProvider$TreeNode.initChildren(ObservableC ollectionTreeContentProvider.java:474)
> at org.eclipse.jface.internal.databinding.viewers.ObservableCol lectionTreeContentProvider$TreeNode.getChildren(ObservableCo llectionTreeContentProvider.java:485)
> at org.eclipse.jface.internal.databinding.viewers.ObservableCol lectionTreeContentProvider.getChildren(ObservableCollectionT reeContentProvider.java:194)
> at org.eclipse.jface.internal.databinding.viewers.ObservableCol lectionTreeContentProvider.getChildren(ObservableCollectionT reeContentProvider.java:189)
> at org.eclipse.jface.databinding.viewers.ObservableListTreeCont entProvider.getChildren(ObservableListTreeContentProvider.ja va:215)
> at org.eclipse.jface.viewers.AbstractTreeViewer.getRawChildren( AbstractTreeViewer.java:1354)
> at org.eclipse.jface.viewers.TreeViewer.getRawChildren(TreeView er.java:391)
> at org.eclipse.jface.viewers.StructuredViewer.getFilteredChildr en(StructuredViewer.java:896)
> at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildr en(AbstractTreeViewer.java:601)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractT reeViewer.java:801)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:70)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren( AbstractTreeViewer.java:778)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeView er.java:644)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren( AbstractTreeViewer.java:749)
> at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpan d(AbstractTreeViewer.java:1444)
> at org.eclipse.jface.viewers.TreeViewer.handleTreeExpand(TreeVi ewer.java:952)
> at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded( AbstractTreeViewer.java:1455)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:132)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :84)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267)
> at org.eclipse.swt.widgets.Tree.gtk_test_expand_row(Tree.java:2 105)
> at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1775)
> at org.eclipse.swt.widgets.Display.windowProc(Display.java:4366 )
> at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
> at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:81 68)
> at org.eclipse.swt.widgets.Display.eventProc(Display.java:1238)
> at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Na tive Method)
> at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS. java:2229)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3159)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2640)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2604)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:24 38)
> at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:671)
> at org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:332)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:664)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at cse.rssm.gui.application.Application.start(Application.java: 39)
> at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:196)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:110)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:79)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:369)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 619)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Connection timeout [message #644433 is a reply to message #644411] |
Sat, 11 December 2010 07:57 |
|
Am 11.12.2010 02:19, schrieb Andy Condon:
> Actually, I've found that my problems stem from changes I had to make to RecoveringCDOSessionImpl in order to work with the 3.0 versions of the session and session configuration implementations. I was working around the fact that those classes had been refactored for 4.0, however the changes done in the refactor are critical to allow session recovery to happen.
Absolutely. Despite the fact that with this nicer design the sessions are decoupled from their creating configurations these changes have been applied to make recovery possible.
> I concede defeat. At least I can't say I wasn't forewarned.
I think it's not impossible to backport the decoupling of the sessions, as well, but for several reasons it would probably be easier and better to just use what we've done in 4.0. Please note that we've already delivered 4.0 milestones: http://www.eclipse.org/cdo/downloads/updates.php
>
> Thanks for you time, if nothing else, I've learned a bit more about how CDO works, which will benefit how my client code inter-ops with it.
I can imagine. I hope you liked it ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Tue Apr 30 03:28:35 GMT 2024
Powered by FUDForum. Page generated in 0.05306 seconds |
] 
Search
Help
Register
Login
Home
