Oneway/async call guarantee

[Qing Yan <qi...@gmail.com>]

Hello!

  I have a few question while reading the thrift paper "Additionally,
an async modifier
keyword may be added to a void function, which will generate
code that does not wait for a response from the server. Note that a
pure void function will return a response to the client which guarantees
that the operation has completed on the server side. With
async method calls the client will only be guaranteed that the request
succeeded at the transport layer. (In many transport scenarios
this is inherently unreliable due to the Byzantine Generals’ Problem.
Therefore, application developers should take care only to use
the async optimization in cases where dropped method calls are
acceptable or the transport is known to be reliable.)"


1) Is TCP/Socket transport layer considered to be reliable?

2) In the TCP/Socket case, does it guarantee the request has
successfully reached the other side? or merely means the request has
been successfully wirtten into the local
socket buffer?


Thank you in advance..

Re: Oneway/async call guarantee

[Jeffrey DeCew <Je...@DeCew.org>]

Jms uses a socket, but it sends an ack to the client that the message was
sent, and that's that's guaruntees that if delivery fails, an exception is
thrown.
Requesting and waiting for a response message is a lot trickier, but there
are a few different patterns for using JMS in RPC situations.  I use a
heartbeat pattern which allows a client to timeout if there's no service
handling messages.

Now that there's a fully async client in Java, I may figure out how to take
advantage of that.

--
Jeff DeCew

On Jul 25, 2010 7:05 PM, "Qing Yan" <qi...@gmail.com> wrote:

hum..doesn't the jms transport need a thrift like reliable comm
mechanism beneath it?




On 7/25/10, Jeffrey DeCew <Je...@decew.org> wrote:
> JMS can provide delivery guaruntees. I wr...

Re: Oneway/async call guarantee

[Qing Yan <qi...@gmail.com>]

hum..doesn't the jms transport need a thrift like reliable comm
mechanism beneath it?



On 7/25/10, Jeffrey DeCew <Je...@decew.org> wrote:
> JMS can provide delivery guaruntees.  I wrote a JMS transport for personal
> use in Java.  It fits well within the oneway model, but writing a versatile
> oneway AND twoway transport with jms is tricky, so mine is either or at the
> moment.
> --
> Jeff DeCew
>
> On Jul 23, 2010 3:20 PM, "Qing Yan" <qi...@gmail.com> wrote:
>
> On 7/23/10, Bryan Duxbury <br...@rapleaf.com> wrote:
>> 1) No.
> Ok..what is the reliable transport the paper is referring to then, does it
> exist in practice?
>
>>
>> 2) Probably just to the local socket buffer. If you are writing and the
>> connection happens to ...
> Just to confirm subsequent calls not the current call will get the
> exception,
> correct?
>
>>
>> On Thu, Jul 22, 2010 at 8:43 PM, Qing Yan <qi...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> I have a...
>

Re: Oneway/async call guarantee

[Jeffrey DeCew <Je...@DeCew.org>]

JMS can provide delivery guaruntees.  I wrote a JMS transport for personal
use in Java.  It fits well within the oneway model, but writing a versatile
oneway AND twoway transport with jms is tricky, so mine is either or at the
moment.
--
Jeff DeCew

On Jul 23, 2010 3:20 PM, "Qing Yan" <qi...@gmail.com> wrote:

On 7/23/10, Bryan Duxbury <br...@rapleaf.com> wrote:
> 1) No.
Ok..what is the reliable transport the paper is referring to then, does it
exist in practice?

>
> 2) Probably just to the local socket buffer. If you are writing and the
> connection happens to ...
Just to confirm subsequent calls not the current call will get the
exception,
correct?

>
> On Thu, Jul 22, 2010 at 8:43 PM, Qing Yan <qi...@gmail.com> wrote:
>
>> Hello!
>>
>> I have a...

Re: Oneway/async call guarantee

[Qing Yan <qi...@gmail.com>]

On 7/23/10, Bryan Duxbury <br...@rapleaf.com> wrote:
> 1) No.
Ok..what is the reliable transport the paper is referring to then, does it
exist in practice?
>
> 2) Probably just to the local socket buffer. If you are writing and the
> connection happens to close or something like that, you'll see those
> exceptions in the client.
Just to confirm subsequent calls not the current call will get the exception,
correct?
>
> On Thu, Jul 22, 2010 at 8:43 PM, Qing Yan <qi...@gmail.com> wrote:
>
>> Hello!
>>
>>  I have a few question while reading the thrift paper "Additionally,
>> an async modifier
>> keyword may be added to a void function, which will generate
>> code that does not wait for a response from the server. Note that a
>> pure void function will return a response to the client which guarantees
>> that the operation has completed on the server side. With
>> async method calls the client will only be guaranteed that the request
>> succeeded at the transport layer. (In many transport scenarios
>> this is inherently unreliable due to the Byzantine Generals’ Problem.
>> Therefore, application developers should take care only to use
>> the async optimization in cases where dropped method calls are
>> acceptable or the transport is known to be reliable.)"
>>
>>
>> 1) Is TCP/Socket transport layer considered to be reliable?
>>
>> 2) In the TCP/Socket case, does it guarantee the request has
>> successfully reached the other side? or merely means the request has
>> been successfully wirtten into the local
>> socket buffer?
>>
>>
>> Thank you in advance..
>>
>

Re: Oneway/async call guarantee

[Bryan Duxbury <br...@rapleaf.com>]

1) No.

2) Probably just to the local socket buffer. If you are writing and the
connection happens to close or something like that, you'll see those
exceptions in the client.

On Thu, Jul 22, 2010 at 8:43 PM, Qing Yan <qi...@gmail.com> wrote:

> Hello!
>
>  I have a few question while reading the thrift paper "Additionally,
> an async modifier
> keyword may be added to a void function, which will generate
> code that does not wait for a response from the server. Note that a
> pure void function will return a response to the client which guarantees
> that the operation has completed on the server side. With
> async method calls the client will only be guaranteed that the request
> succeeded at the transport layer. (In many transport scenarios
> this is inherently unreliable due to the Byzantine Generals’ Problem.
> Therefore, application developers should take care only to use
> the async optimization in cases where dropped method calls are
> acceptable or the transport is known to be reliable.)"
>
>
> 1) Is TCP/Socket transport layer considered to be reliable?
>
> 2) In the TCP/Socket case, does it guarantee the request has
> successfully reached the other side? or merely means the request has
> been successfully wirtten into the local
> socket buffer?
>
>
> Thank you in advance..
>