Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [CDO][0.8.0] Exception Handling
[CDO][0.8.0] Exception Handling [message #104869] Tue, 18 December 2007 03:16 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I would like that any CDOClientRequest do not freeze if the indication have
an exception.
If an error occured in the back-end.. the application freeze because of
that.

It should react as CommitTransactionRequest and CommitTransactionIndication

Should be bullet proof.

What do you think ?
Re: [CDO][0.8.0] Exception Handling [message #104875 is a reply to message #104869] Tue, 18 December 2007 11:23 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon McDuff schrieb:
> I would like that any CDOClientRequest do not freeze if the indication have
> an exception.
> If an error occured in the back-end.. the application freeze because of
> that.
>
> It should react as CommitTransactionRequest and CommitTransactionIndication
>
> Should be bullet proof.
>
> What do you think ?
>
100% agreed.

Only in the recent days I thought about making requests more reliable in
both cases: success and failure. Currently there are potentially two issues:

- In case of a (server processing) failure it's left to the application
protocol to handle this case (what you complained about). In fact this
case is currently only handled by using a proper timeout value with
Request.send(channel, timeout).

- The aforementioned timeout can lead to TimeoutExceptions being thrown
although there was no failure in server processing, it just takes a bit
longer. CommitTransactionRequest is the best example (and it happened to
me when committing large transactions). More exactly the timeout value
controls, starting from the time the requesting() method has
finished/returned, if the response input stream is idle for timeout millis.

I believe there's an interesting solution for both issues: We could use
the control channel (through new API of Connector) to inform the client
about the state of the server processing, including the indicating()
method progress for the case that the real server processing happens in
the responding() method.

We should start by specifying what exactly we want to protect against!
1) Bugs in an indicating() method. There are two different kinds of bugs:
1a) Protocol bugs. The implementor of the indicating() method
incorrectly calls (or doesn't call) readXYZ() methods.
1b) Server processing failures. The implementor of the indicating()
method calls a server method that throws an uncaught exception.

2) Bugs in a responding() method. These can only be server processing
failures. The implementor of the responding() method calls a server
method that throws an uncaught exception.

3) Bugs in a confirming() method. There are two different kinds of bugs:
3a) Protocol bugs. The implementor of the confirming() method
incorrectly calls (or doesn't call) readXYZ() methods.
3b) Client processing failures. The implementor of the confirming()
method calls a client method that throws an uncaught exception.

4) Network failures. One of the readXYZ() calls throws a
TimeoutException or EOFException.

5) A bit pathological are client processing failures in the middle of a
requesting() execution. The client can easily be protected since
requesting is always executed in the context of the calling/sending
thread. But the data sent so far can also lead to network failures 4) in
the server!

6) Inappropriate (too early) interpretation of server processing
failures 1b) in cases where the processing simply takes longer than
expected.

Agreed so far? Any additions?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: [CDO][0.8.0] Exception Handling [message #104947 is a reply to message #104875] Tue, 18 December 2007 21:10 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369


"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8air$oem$2@build.eclipse.org...
> Simon McDuff schrieb:
>> I would like that any CDOClientRequest do not freeze if the indication
>> have an exception.
>> If an error occured in the back-end.. the application freeze because of
>> that.
>>
>> It should react as CommitTransactionRequest and
>> CommitTransactionIndication
>>
>> Should be bullet proof.
>>
>> What do you think ?
> 100% agreed.
>
> Only in the recent days I thought about making requests more reliable in
> both cases: success and failure. Currently there are potentially two
> issues:
>
> - In case of a (server processing) failure it's left to the application
> protocol to handle this case (what you complained about). In fact this
> case is currently only handled by using a proper timeout value with
> Request.send(channel, timeout).
>
> - The aforementioned timeout can lead to TimeoutExceptions being thrown
> although there was no failure in server processing, it just takes a bit
> longer. CommitTransactionRequest is the best example (and it happened to
> me when committing large transactions). More exactly the timeout value
> controls, starting from the time the requesting() method has
> finished/returned, if the response input stream is idle for timeout
> millis.
>
> I believe there's an interesting solution for both issues: We could use
> the control channel (through new API of Connector) to inform the client
> about the state of the server processing, including the indicating()
> method progress for the case that the real server processing happens in
> the responding() method.
>
> We should start by specifying what exactly we want to protect against!
> 1) Bugs in an indicating() method. There are two different kinds of bugs:
> 1a) Protocol bugs. The implementor of the indicating() method incorrectly
> calls (or doesn't call) readXYZ() methods.
> 1b) Server processing failures. The implementor of the indicating() method
> calls a server method that throws an uncaught exception.
>
> 2) Bugs in a responding() method. These can only be server processing
> failures. The implementor of the responding() method calls a server method
> that throws an uncaught exception.
>
> 3) Bugs in a confirming() method. There are two different kinds of bugs:
> 3a) Protocol bugs. The implementor of the confirming() method incorrectly
> calls (or doesn't call) readXYZ() methods.
> 3b) Client processing failures. The implementor of the confirming() method
> calls a client method that throws an uncaught exception.
>
> 4) Network failures. One of the readXYZ() calls throws a TimeoutException
> or EOFException.
>
> 5) A bit pathological are client processing failures in the middle of a
> requesting() execution. The client can easily be protected since
> requesting is always executed in the context of the calling/sending
> thread. But the data sent so far can also lead to network failures 4) in
> the server!
>
> 6) Inappropriate (too early) interpretation of server processing failures
> 1b) in cases where the processing simply takes longer than expected.
>
> Agreed so far? Any additions?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
Re: [CDO][0.8.0] Exception Handling [message #104967 is a reply to message #104947] Wed, 19 December 2007 05:44 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------020705000203060802020509
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon,

I turned it into an enhancement request and marked it P1.
Are you planning to comment on the points I wrote?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369
>
>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8air$oem$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> I would like that any CDOClientRequest do not freeze if the indication
>>> have an exception.
>>> If an error occured in the back-end.. the application freeze because of
>>> that.
>>>
>>> It should react as CommitTransactionRequest and
>>> CommitTransactionIndication
>>>
>>> Should be bullet proof.
>>>
>>> What do you think ?
>>>
>> 100% agreed.
>>
>> Only in the recent days I thought about making requests more reliable in
>> both cases: success and failure. Currently there are potentially two
>> issues:
>>
>> - In case of a (server processing) failure it's left to the application
>> protocol to handle this case (what you complained about). In fact this
>> case is currently only handled by using a proper timeout value with
>> Request.send(channel, timeout).
>>
>> - The aforementioned timeout can lead to TimeoutExceptions being thrown
>> although there was no failure in server processing, it just takes a bit
>> longer. CommitTransactionRequest is the best example (and it happened to
>> me when committing large transactions). More exactly the timeout value
>> controls, starting from the time the requesting() method has
>> finished/returned, if the response input stream is idle for timeout
>> millis.
>>
>> I believe there's an interesting solution for both issues: We could use
>> the control channel (through new API of Connector) to inform the client
>> about the state of the server processing, including the indicating()
>> method progress for the case that the real server processing happens in
>> the responding() method.
>>
>> We should start by specifying what exactly we want to protect against!
>> 1) Bugs in an indicating() method. There are two different kinds of bugs:
>> 1a) Protocol bugs. The implementor of the indicating() method incorrectly
>> calls (or doesn't call) readXYZ() methods.
>> 1b) Server processing failures. The implementor of the indicating() method
>> calls a server method that throws an uncaught exception.
>>
>> 2) Bugs in a responding() method. These can only be server processing
>> failures. The implementor of the responding() method calls a server method
>> that throws an uncaught exception.
>>
>> 3) Bugs in a confirming() method. There are two different kinds of bugs:
>> 3a) Protocol bugs. The implementor of the confirming() method incorrectly
>> calls (or doesn't call) readXYZ() methods.
>> 3b) Client processing failures. The implementor of the confirming() method
>> calls a client method that throws an uncaught exception.
>>
>> 4) Network failures. One of the readXYZ() calls throws a TimeoutException
>> or EOFException.
>>
>> 5) A bit pathological are client processing failures in the middle of a
>> requesting() execution. The client can easily be protected since
>> requesting is always executed in the context of the calling/sending
>> thread. But the data sent so far can also lead to network failures 4) in
>> the server!
>>
>> 6) Inappropriate (too early) interpretation of server processing failures
>> 1b) in cases where the processing simply takes longer than expected.
>>
>> Agreed so far? Any additions?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>
>
>

--------------020705000203060802020509
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon,<br>
<br>
I turned it into an enhancement request and marked it P1.<br>
Are you planning to comment on the points I wrote?<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fk9d15$70s$1@build.eclipse.org" type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369">https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369</a>


"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8air$oem$2@build.eclipse.org">news:fk8air$oem$2@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">I would like that any CDOClientRequest do not freeze if the indication
have an exception.
If an error occured in the back-end.. the application freeze because of
that.

It should react as CommitTransactionRequest and
CommitTransactionIndication

Should be bullet proof.

What do you think ?
</pre>
</blockquote>
<pre wrap="">100% agreed.

Only in the recent days I thought about making requests more reliable in
both cases: success and failure. Currently there are potentially two
issues:

- In case of a (server processing) failure it's left to the application
protocol to handle this case (what you complained about). In fact this
case is currently only handled by using a proper timeout value with
Request.send(channel, timeout).

- The aforementioned timeout can lead to TimeoutExceptions being thrown
although there was no failure in server processing, it just takes a bit
longer. CommitTransactionRequest is the best example (and it happened to
me when committing large transactions). More exactly the timeout value
controls, starting from the time the requesting() method has
finished/returned, if the response input stream is idle for timeout
millis.

I believe there's an interesting solution for both issues: We could use
the control channel (through new API of Connector) to inform the client
about the state of the server processing, including the indicating()
method progress for the case that the real server processing happens in
the responding() method.

We should start by specifying what exactly we want to protect against!
1) Bugs in an indicating() method. There are two different kinds of bugs:
1a) Protocol bugs. The implementor of the indicating() method incorrectly
calls (or doesn't call) readXYZ() methods.
1b) Server processing failures. The implementor of the indicating() method
calls a server method that throws an uncaught exception.

2) Bugs in a responding() method. These can only be server processing
failures. The implementor of the responding() method calls a server method
that throws an uncaught exception.

3) Bugs in a confirming() method. There are two different kinds of bugs:
3a) Protocol bugs. The implementor of the confirming() method incorrectly
calls (or doesn't call) readXYZ() methods.
3b) Client processing failures. The implementor of the confirming() method
calls a client method that throws an uncaught exception.

4) Network failures. One of the readXYZ() calls throws a TimeoutException
or EOFException.

5) A bit pathological are client processing failures in the middle of a
requesting() execution. The client can easily be protected since
requesting is always executed in the context of the calling/sending
thread. But the data sent so far can also lead to network failures 4) in
the server!

6) Inappropriate (too early) interpretation of server processing failures
1b) in cases where the processing simply takes longer than expected.

Agreed so far? Any additions?

Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>


</pre>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------020705000203060802020509--
Re: [CDO][0.8.0] Exception Handling [message #612866 is a reply to message #104869] Tue, 18 December 2007 11:23 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> I would like that any CDOClientRequest do not freeze if the indication have
> an exception.
> If an error occured in the back-end.. the application freeze because of
> that.
>
> It should react as CommitTransactionRequest and CommitTransactionIndication
>
> Should be bullet proof.
>
> What do you think ?
>
100% agreed.

Only in the recent days I thought about making requests more reliable in
both cases: success and failure. Currently there are potentially two issues:

- In case of a (server processing) failure it's left to the application
protocol to handle this case (what you complained about). In fact this
case is currently only handled by using a proper timeout value with
Request.send(channel, timeout).

- The aforementioned timeout can lead to TimeoutExceptions being thrown
although there was no failure in server processing, it just takes a bit
longer. CommitTransactionRequest is the best example (and it happened to
me when committing large transactions). More exactly the timeout value
controls, starting from the time the requesting() method has
finished/returned, if the response input stream is idle for timeout millis.

I believe there's an interesting solution for both issues: We could use
the control channel (through new API of Connector) to inform the client
about the state of the server processing, including the indicating()
method progress for the case that the real server processing happens in
the responding() method.

We should start by specifying what exactly we want to protect against!
1) Bugs in an indicating() method. There are two different kinds of bugs:
1a) Protocol bugs. The implementor of the indicating() method
incorrectly calls (or doesn't call) readXYZ() methods.
1b) Server processing failures. The implementor of the indicating()
method calls a server method that throws an uncaught exception.

2) Bugs in a responding() method. These can only be server processing
failures. The implementor of the responding() method calls a server
method that throws an uncaught exception.

3) Bugs in a confirming() method. There are two different kinds of bugs:
3a) Protocol bugs. The implementor of the confirming() method
incorrectly calls (or doesn't call) readXYZ() methods.
3b) Client processing failures. The implementor of the confirming()
method calls a client method that throws an uncaught exception.

4) Network failures. One of the readXYZ() calls throws a
TimeoutException or EOFException.

5) A bit pathological are client processing failures in the middle of a
requesting() execution. The client can easily be protected since
requesting is always executed in the context of the calling/sending
thread. But the data sent so far can also lead to network failures 4) in
the server!

6) Inappropriate (too early) interpretation of server processing
failures 1b) in cases where the processing simply takes longer than
expected.

Agreed so far? Any additions?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Re: [CDO][0.8.0] Exception Handling [message #612894 is a reply to message #104875] Tue, 18 December 2007 21:10 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369


"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8air$oem$2@build.eclipse.org...
> Simon McDuff schrieb:
>> I would like that any CDOClientRequest do not freeze if the indication
>> have an exception.
>> If an error occured in the back-end.. the application freeze because of
>> that.
>>
>> It should react as CommitTransactionRequest and
>> CommitTransactionIndication
>>
>> Should be bullet proof.
>>
>> What do you think ?
> 100% agreed.
>
> Only in the recent days I thought about making requests more reliable in
> both cases: success and failure. Currently there are potentially two
> issues:
>
> - In case of a (server processing) failure it's left to the application
> protocol to handle this case (what you complained about). In fact this
> case is currently only handled by using a proper timeout value with
> Request.send(channel, timeout).
>
> - The aforementioned timeout can lead to TimeoutExceptions being thrown
> although there was no failure in server processing, it just takes a bit
> longer. CommitTransactionRequest is the best example (and it happened to
> me when committing large transactions). More exactly the timeout value
> controls, starting from the time the requesting() method has
> finished/returned, if the response input stream is idle for timeout
> millis.
>
> I believe there's an interesting solution for both issues: We could use
> the control channel (through new API of Connector) to inform the client
> about the state of the server processing, including the indicating()
> method progress for the case that the real server processing happens in
> the responding() method.
>
> We should start by specifying what exactly we want to protect against!
> 1) Bugs in an indicating() method. There are two different kinds of bugs:
> 1a) Protocol bugs. The implementor of the indicating() method incorrectly
> calls (or doesn't call) readXYZ() methods.
> 1b) Server processing failures. The implementor of the indicating() method
> calls a server method that throws an uncaught exception.
>
> 2) Bugs in a responding() method. These can only be server processing
> failures. The implementor of the responding() method calls a server method
> that throws an uncaught exception.
>
> 3) Bugs in a confirming() method. There are two different kinds of bugs:
> 3a) Protocol bugs. The implementor of the confirming() method incorrectly
> calls (or doesn't call) readXYZ() methods.
> 3b) Client processing failures. The implementor of the confirming() method
> calls a client method that throws an uncaught exception.
>
> 4) Network failures. One of the readXYZ() calls throws a TimeoutException
> or EOFException.
>
> 5) A bit pathological are client processing failures in the middle of a
> requesting() execution. The client can easily be protected since
> requesting is always executed in the context of the calling/sending
> thread. But the data sent so far can also lead to network failures 4) in
> the server!
>
> 6) Inappropriate (too early) interpretation of server processing failures
> 1b) in cases where the processing simply takes longer than expected.
>
> Agreed so far? Any additions?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
Re: [CDO][0.8.0] Exception Handling [message #612898 is a reply to message #104947] Wed, 19 December 2007 05:44 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------020705000203060802020509
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon,

I turned it into an enhancement request and marked it P1.
Are you planning to comment on the points I wrote?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369
>
>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8air$oem$2@build.eclipse.org...
>
>> Simon McDuff schrieb:
>>
>>> I would like that any CDOClientRequest do not freeze if the indication
>>> have an exception.
>>> If an error occured in the back-end.. the application freeze because of
>>> that.
>>>
>>> It should react as CommitTransactionRequest and
>>> CommitTransactionIndication
>>>
>>> Should be bullet proof.
>>>
>>> What do you think ?
>>>
>> 100% agreed.
>>
>> Only in the recent days I thought about making requests more reliable in
>> both cases: success and failure. Currently there are potentially two
>> issues:
>>
>> - In case of a (server processing) failure it's left to the application
>> protocol to handle this case (what you complained about). In fact this
>> case is currently only handled by using a proper timeout value with
>> Request.send(channel, timeout).
>>
>> - The aforementioned timeout can lead to TimeoutExceptions being thrown
>> although there was no failure in server processing, it just takes a bit
>> longer. CommitTransactionRequest is the best example (and it happened to
>> me when committing large transactions). More exactly the timeout value
>> controls, starting from the time the requesting() method has
>> finished/returned, if the response input stream is idle for timeout
>> millis.
>>
>> I believe there's an interesting solution for both issues: We could use
>> the control channel (through new API of Connector) to inform the client
>> about the state of the server processing, including the indicating()
>> method progress for the case that the real server processing happens in
>> the responding() method.
>>
>> We should start by specifying what exactly we want to protect against!
>> 1) Bugs in an indicating() method. There are two different kinds of bugs:
>> 1a) Protocol bugs. The implementor of the indicating() method incorrectly
>> calls (or doesn't call) readXYZ() methods.
>> 1b) Server processing failures. The implementor of the indicating() method
>> calls a server method that throws an uncaught exception.
>>
>> 2) Bugs in a responding() method. These can only be server processing
>> failures. The implementor of the responding() method calls a server method
>> that throws an uncaught exception.
>>
>> 3) Bugs in a confirming() method. There are two different kinds of bugs:
>> 3a) Protocol bugs. The implementor of the confirming() method incorrectly
>> calls (or doesn't call) readXYZ() methods.
>> 3b) Client processing failures. The implementor of the confirming() method
>> calls a client method that throws an uncaught exception.
>>
>> 4) Network failures. One of the readXYZ() calls throws a TimeoutException
>> or EOFException.
>>
>> 5) A bit pathological are client processing failures in the middle of a
>> requesting() execution. The client can easily be protected since
>> requesting is always executed in the context of the calling/sending
>> thread. But the data sent so far can also lead to network failures 4) in
>> the server!
>>
>> 6) Inappropriate (too early) interpretation of server processing failures
>> 1b) in cases where the processing simply takes longer than expected.
>>
>> Agreed so far? Any additions?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>
>
>

--------------020705000203060802020509
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Simon,<br>
<br>
I turned it into an enhancement request and marked it P1.<br>
Are you planning to comment on the points I wrote?<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fk9d15$70s$1@build.eclipse.org" type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369">https://bugs.eclipse.org/bugs/show_bug.cgi?id=213369</a>


"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8air$oem$2@build.eclipse.org">news:fk8air$oem$2@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">I would like that any CDOClientRequest do not freeze if the indication
have an exception.
If an error occured in the back-end.. the application freeze because of
that.

It should react as CommitTransactionRequest and
CommitTransactionIndication

Should be bullet proof.

What do you think ?
</pre>
</blockquote>
<pre wrap="">100% agreed.

Only in the recent days I thought about making requests more reliable in
both cases: success and failure. Currently there are potentially two
issues:

- In case of a (server processing) failure it's left to the application
protocol to handle this case (what you complained about). In fact this
case is currently only handled by using a proper timeout value with
Request.send(channel, timeout).

- The aforementioned timeout can lead to TimeoutExceptions being thrown
although there was no failure in server processing, it just takes a bit
longer. CommitTransactionRequest is the best example (and it happened to
me when committing large transactions). More exactly the timeout value
controls, starting from the time the requesting() method has
finished/returned, if the response input stream is idle for timeout
millis.

I believe there's an interesting solution for both issues: We could use
the control channel (through new API of Connector) to inform the client
about the state of the server processing, including the indicating()
method progress for the case that the real server processing happens in
the responding() method.

We should start by specifying what exactly we want to protect against!
1) Bugs in an indicating() method. There are two different kinds of bugs:
1a) Protocol bugs. The implementor of the indicating() method incorrectly
calls (or doesn't call) readXYZ() methods.
1b) Server processing failures. The implementor of the indicating() method
calls a server method that throws an uncaught exception.

2) Bugs in a responding() method. These can only be server processing
failures. The implementor of the responding() method calls a server method
that throws an uncaught exception.

3) Bugs in a confirming() method. There are two different kinds of bugs:
3a) Protocol bugs. The implementor of the confirming() method incorrectly
calls (or doesn't call) readXYZ() methods.
3b) Client processing failures. The implementor of the confirming() method
calls a client method that throws an uncaught exception.

4) Network failures. One of the readXYZ() calls throws a TimeoutException
or EOFException.

5) A bit pathological are client processing failures in the middle of a
requesting() execution. The client can easily be protected since
requesting is always executed in the context of the calling/sending
thread. But the data sent so far can also lead to network failures 4) in
the server!

6) Inappropriate (too early) interpretation of server processing failures
1b) in cases where the processing simply takes longer than expected.

Agreed so far? Any additions?

Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>


</pre>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------020705000203060802020509--


Previous Topic:[cdo][0.8.0]
Next Topic:[CDO] Performance problem
Goto Forum:
  


Current Time: Fri Mar 29 10:56:13 GMT 2024

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

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

Back to the top