Heartbeat thread

Hi,

Please help me understand the heartbeat functionality.

I try with the simplest app to simulate a unplanned hard disconnects.

If I understand good that heartbeat thread sending a message to server
and checking the response, meanwhile the server is counting the
heartbeats and if 3 is missing then it disconnects the client.

The server side is working as it advertised...

I have a problem with the clientside...
I check the sourcecode to see the heartbeat thread innerexecute method.
In that method the thread is in waiting state after the timeout is
reached it sends the message to the server, when the send method throws
and exception (I think when the server is offline then it must thrown an
exception) the thread count the exception and if the count is reached 10
the thread exist.

So basically when the thread cannot send 10 keepalive messages it
terminates itself.

But the client does not. I run the simpleremote demo, after i disable in
the server the winsocktransport.

The client still sitting silently... when I try to edit a record it is
throws the lost comm exception, i check the exceptionlog with eurekalog
to see that the heartbeat thread still sitting in the innerexecute
method and does not seems to be want to exit at all.

For record i wait over 1 minutes after the transport was disabled and
before i try to edit a record. The heartbeat interval was set for 1000
or 1 second.


So what is the purpose of the keepalive thread on the client side?

I hope that I could get some exception after the keepalive thread
failing to send the message to server and then I can try to reconnect
the server.

But it seems to me more difficult now.

Thanks

Sandor Dobi

Sandor Dobi wrote:

> So what is the purpose of the keepalive thread on the client side?
Sending messages in regular intervals to the server which are used by
the server to determine if a client connection has timed out.

> I hope that I could get some exception after the keepalive thread
> failing to send the message to server and then I can try to reconnect
> the server.

The heartbeat thread is not designed for that. The correct way is for
you to write code to handle the lost comm exception if it occurs. No
matter what you are doing with the heartbeat thread or any other system
you might try to put in place to determine if the connection is still
valid, you will never be able to guarantee that the connection doesn't
get lost between the checks and a normal call to the transport takes
place after the connection has been lost but before the next check
takes place. And it only starts to get orders of magnitude more complex
if your client application should happen to use multiple threads.

> But it seems to me more difficult now.

The only way to go is proper exception handling.

Cheers,
Thorsten


--

Thorsten Engler Ã*rta:
> Sandor Dobi wrote:
>
>> So what is the purpose of the keepalive thread on the client side?
> Sending messages in regular intervals to the server which are used by
> the server to determine if a client connection has timed out.

So it is only good for the server housekeeping.

>
>> I hope that I could get some exception after the keepalive thread
>> failing to send the message to server and then I can try to reconnect
>> the server.
>
> The heartbeat thread is not designed for that. The correct way is for
> you to write code to handle the lost comm exception if it occurs. No
> matter what you are doing with the heartbeat thread or any other system
> you might try to put in place to determine if the connection is still
> valid, you will never be able to guarantee that the connection doesn't
> get lost between the checks and a normal call to the transport takes
> place after the connection has been lost but before the next check
> takes place. And it only starts to get orders of magnitude more complex
> if your client application should happen to use multiple threads.
>
>> But it seems to me more difficult now.
>
> The only way to go is proper exception handling.

Ok thanks i'll try catch the exception and try reconnect. Any clue about
how to resynchronize many open windows with grids and datasources if it
happens? Or simple close all and say to the user "sorry sh*t happens try
again" ?


Another question...

I have read in other thread that You advise to check the connection in a
timer and that heartbeat thread can help to decide if in timer event
need to check the connection or not.

That solution has a suggestion to me that still can have some info about
that the heartbeat is failing.

Is this correct or i misunderstood something? If correct then how I can
check that the heartbeat start failing?

Thanks for Your time.

Regards

Sandor Dobi

Sandor Dobi wrote:

> Ok thanks i'll try catch the exception and try reconnect. Any clue
> about how to resynchronize many open windows with grids and
> datasources if it happens? Or simple close all and say to the user
> "sorry sh*t happens try again" ?

If the server connection has been lost then the server has freed all
the handles (sessions, databases, cursors, statement, ..) that belonged
to this connection. The client side objects do not contain sufficient
information to exactly recreate the state of these server side objects.
And that's not even taking into account that there might have been an
active transaction containing any number of modifications which has
been lost.

So no, there is no there is no way to magically reconnect everything
after the connection and with that the server state has been lost.

> I have read in other thread that You advise to check the connection
> in a timer and that heartbeat thread can help to decide if in timer
> event need to check the connection or not.
>
> That solution has a suggestion to me that still can have some info
> about that the heartbeat is failing.
>
> Is this correct or i misunderstood something? If correct then how I
> can check that the heartbeat start failing?
Not without making changes to the existing code.

And no matter what you do, you must write code to properly handle the
comm lost exception as you can't guarantee that whatever checking code
you put in place will be the first to use the transport after the
connection has been lost. If you have that then I don't really see much
point in having timers or anything else constantly check the connecton.

Cheers,
Thorsten




--

"Thorsten Engler" <thorsten.engler@gmx.net> wrote in message
news:xn0f40gqs4swfbc000@news.nexusdb.com...
> Sandor Dobi wrote:
>
> If the server connection has been lost then the server has freed all
> the handles (sessions, databases, cursors, statement, ..) that belonged
> to this connection. The client side objects do not contain sufficient
> information to exactly recreate the state of these server side objects.
> And that's not even taking into account that there might have been an
> active transaction containing any number of modifications which has
> been lost.
>

Because of this, the server should allow the client to reconnect using the
same session id. This should be handled automatically by the heartbeat
thread.

PK

> Because of this, the server should allow the client to reconnect using the
> same session id. This should be handled automatically by the heartbeat
> thread.

It's not that simple as it looks on first sight. The problem is in no way on
the server side, but on client side. The VCL dataset environment is a stateful
set of components. Loosing connection to the server means that server and
client are potentially out of sync with no way to tell which exact differences
there are (messages/ansers might have got lost). While reconnecting the
transport isn't an issue, *safely* resynching the client/server connection is
(almost) impossible.

--

Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm

> Because of this, the server should allow the client to reconnect
> using the same session id. This should be handled automatically by
> the heartbeat thread.

Consider what you are asking. The client who lost connection might have been
in the middle of a transaction. Would you want the server to keep the
client's resources alive indefinitely, and potentially block other active
clients from doing work?

--

Eivind Bakkestuen
Nexus Database Systems Pty Ltd

"Hannes Danzl[NDD]" <hannes@nexusdb.dbnexus.com> wrote in message
news:xn0f41pu423628x000@217.20.118.10...
> It's not that simple as it looks on first sight. The problem is in no way
> on
> the server side, but on client side. The VCL dataset environment is a
> stateful
> set of components. Loosing connection to the server means that server and
> client are potentially out of sync with no way to tell which exact
> differences
> there are (messages/ansers might have got lost). While reconnecting the
> transport isn't an issue, *safely* resynching the client/server connection
> is
> (almost) impossible.
>

Yes, your're right. I forget that it is stateful rather than stateless like
HTTP.

PK