Thrift server status notification at client side

[Avoy Nanda <av...@gmail.com>]

Hello,

I am implementing in golang and need to detect on client side if server is
still there or not. One way to detect that is by writing onto transport and
process error.

However, my requirement is to detect the connection status upfront. Is
there any way to achieve that?

Thanks,
Avoy

Re: Thrift server status notification at client side

[Avoy Nanda <av...@gmail.com>]

Hi JensG,

Thanks for your response and I agree that it can never be 100% sure that
server is available.

My use case is:
I am providing capability for user to configure multiple servers through a
gateway. The gateway will receive user configuration and depending on which
server should serve this config, it will be dispatched to that server.

If any of the servers is not available, gateway will not accept any
configuration from user until all the servers are back up.

That's why gateway needs to know when a server is down.

Thanks,
Avoy

On Mon, Jan 11, 2016 at 2:18 PM, Jens Geyer <je...@hotmail.com> wrote:

> Hi Avoy,
>
> good question.
>
>
> At first, in a typical distributed system there is no chance to get that
> information in a reliable manner. In other words, it depends on what rate
> of "false positives" you can live with.
>
> - If the requirement is to be 100% sure, there is one way and one way
> only: Do the call you want to do and check if it fails or succeeds. There
> is no way around actually doing the call if 100% correctness is expected,
> because the server in question could go out of business at ANY time, even
> if it told you its availability just a microsecond before.
>
> - If the requirement is to be sure most of the time, but allow for small
> percentages of errors, send a ping before the real request(s) follow. There
> is still a small chance of a server going down after responding to the
> ping, but the probability is typically very low.
>
> - If it is ok to only approximately know it and there is some fallback
> mechanism in place, one could think of a information store that holds all
> info about where the servers live and what services they offer. That
> directory could be a centralized one, or a distributed one, a typical
> example would be Apache Zookeeper. Of course, by adding more components to
> the system, one also gets more potential sources of problems.
>
>
> Second, the call may fail even if the call itself back and forth succeeds.
> For example, the clients asks for some information, but the server needs
> some information to be retrieved from a backend database to fully process
> the call. That database may actually be unavailable, leading the call to
> fail although it "technically" succeeded. The point here is, regardless why
> it fails, it makes not much of a difference to the client.
>
>
> To be able to tell more and/or to give more specific advice, we will need
> to know more about what you are actually planning to do.
>
> Have fun,
> JensG
>
>

Re: Thrift server status notification at client side

[Jens Geyer <je...@hotmail.com>]

Hi Avoy,

good question.


At first, in a typical distributed system there is no chance to get that 
information in a reliable manner. In other words, it depends on what rate of 
"false positives" you can live with.

- If the requirement is to be 100% sure, there is one way and one way only: 
Do the call you want to do and check if it fails or succeeds. There is no 
way around actually doing the call if 100% correctness is expected, because 
the server in question could go out of business at ANY time, even if it told 
you its availability just a microsecond before.

- If the requirement is to be sure most of the time, but allow for small 
percentages of errors, send a ping before the real request(s) follow. There 
is still a small chance of a server going down after responding to the ping, 
but the probability is typically very low.

- If it is ok to only approximately know it and there is some fallback 
mechanism in place, one could think of a information store that holds all 
info about where the servers live and what services they offer. That 
directory could be a centralized one, or a distributed one, a typical 
example would be Apache Zookeeper. Of course, by adding more components to 
the system, one also gets more potential sources of problems.


Second, the call may fail even if the call itself back and forth succeeds. 
For example, the clients asks for some information, but the server needs 
some information to be retrieved from a backend database to fully process 
the call. That database may actually be unavailable, leading the call to 
fail although it "technically" succeeded. The point here is, regardless why 
it fails, it makes not much of a difference to the client.


To be able to tell more and/or to give more specific advice, we will need to 
know more about what you are actually planning to do.

Have fun,
JensG