Prev: Porting ASP.NET/SQL Server to JAVA/Oracle
Next: Get DTS datapump source columns
From: Charles on 23 May 2010 10:28
The signalling system should not be re-entrant. If the process that runs at
each tick doesn't complete in time then there's no point in trying to start
another one. If and when, however, the process times out, then a new process
should be started 10 seconds from when the last one started, or as near as.

I keep referring to this as a process, but it's really just a heartbeat. A
message is sent to a remote system every 10 seconds, and a reply is
returned. If the remote system doesn't hear a heartbeat for 20 seconds it
shuts down. If this happens it has to be restarted manually, so I don't want
it to keep shutting down.

So that is why I say that +/- 5 seconds is acceptable. I have a timeout on
receiving a reply of 8 seconds. That way, if I don't get a timely reply
there is a wait of 2 seconds before I send the next heartbeat.

Charles


"Willem van Rumpt" <wdotvandotrumpt(a)skoutsoftdotcom> wrote in message
news:#V4bDQf#KHA.3880(a)TK2MSFTNGP04.phx.gbl...
> On 22-5-2010 9:51, Charles wrote:
>> Thinking about it further, the downside of this approach is that the
>> interval between 'ticks' is not 10 seconds anymore. It is 10 seconds +
>> length of time task takes. Perhaps that's not the end of the world, but
>> I might have to factor that in somehow.
>>
>> Charles
>>
>
> But this will always be a factor to consider, whatever scenario you
> choose. You should ask yourself whether you want the signalling system to
> have some form of reentrancy. In other words: Is it allowed to be
> signalled while a previous signal is still being processed?
>
> If yes, then the question should be: Is the order of processing the
> signals relevant or not? If it's not, you can just start the task on a
> separate thread, or queue it on the threadpool. If it is, you'll have to
> setup some sort of queue, that processes the signals asynchroniously, but
> in queued order.
>
> If no, then there's little you can do about it. Either you make sure the
> tasks finishes within the signalling time window (which may or may not be
> possible, but will always be very tough to guarantee), or you give up on
> reentrancy of the signal.
>
> --
> Willem van Rumpt

From: Andrew Morton on 24 May 2010 07:06
Charles wrote:
> I keep referring to this as a process, but it's really just a
> heartbeat. A message is sent to a remote system every 10 seconds, and
> a reply is returned. If the remote system doesn't hear a heartbeat
> for 20 seconds it shuts down. If this happens it has to be restarted
> manually, so I don't want it to keep shutting down.
>
> So that is why I say that +/- 5 seconds is acceptable. I have a
> timeout on receiving a reply of 8 seconds. That way, if I don't get a
> timely reply there is a wait of 2 seconds before I send the next
> heartbeat.

Can't you set the monitor to accept the heartbeat signal at longer
intervals? You already know the monitored system is sometimes too busy to
process it at the currently required frequency, so perhaps the requirement
is wrong.

--
Andrew


From: Charles on 24 May 2010 07:32
Hi Andrew

Unfortunately, I have no control over the external system. I am just
presented with an interface that I must adhere to. It is a third-party
system, and there is no question that they will change the interface just
for us.

Charles


"Andrew Morton" <akm(a)in-press.co.uk.invalid> wrote in message
news:85v4tnFij4U1(a)mid.individual.net...
> Charles wrote:
>> I keep referring to this as a process, but it's really just a
>> heartbeat. A message is sent to a remote system every 10 seconds, and
>> a reply is returned. If the remote system doesn't hear a heartbeat
>> for 20 seconds it shuts down. If this happens it has to be restarted
>> manually, so I don't want it to keep shutting down.
>>
>> So that is why I say that +/- 5 seconds is acceptable. I have a
>> timeout on receiving a reply of 8 seconds. That way, if I don't get a
>> timely reply there is a wait of 2 seconds before I send the next
>> heartbeat.
>
> Can't you set the monitor to accept the heartbeat signal at longer
> intervals? You already know the monitored system is sometimes too busy to
> process it at the currently required frequency, so perhaps the requirement
> is wrong.
>
> --
> Andrew
>
From: Willem van Rumpt on 25 May 2010 05:50
Charles wrote:

> I keep referring to this as a process, but it's really just a heartbeat.
> A message is sent to a remote system every 10 seconds, and a reply is
> returned. If the remote system doesn't hear a heartbeat for 20 seconds
> it shuts down. If this happens it has to be restarted manually, so I
> don't want it to keep shutting down.
>
> So that is why I say that +/- 5 seconds is acceptable. I have a timeout
> on receiving a reply of 8 seconds. That way, if I don't get a timely
> reply there is a wait of 2 seconds before I send the next heartbeat.
>
> Charles
>

A few questions come to mind:

1. What exactly does the message system look like (sockets, msmq, named
pipe etc. etc.)? Is sending it a blocking operation?

2. Is the reply relevant, and is receival of it a blocking operation?

From what I've gathered, you're sending messages to a remote system, so
the remote system being very busy can't account for the process on your
system timing out, or not raising a timer event on time, unless you're
sending and receiving synchronously and waiting for the remote system to
respond.

--
Willem van Rumpt
From: Charles on 25 May 2010 13:56
The messages are well-formed XML over TCP. The send is not a blocking
operation, and indeed messages are exchanged asynchronously, so the reply to
a heartbeat might not be the very next thing the remote system sends; it
might send some unrelated data and send the reply to the heartbeat some
seconds later. The reply is relevant, but only from the point of view of
maintaining integrity. There is no intrinsic value in it. Receiving the
reply does not block either, and if no reply appears after 8 seconds then my
app gives up.

What can happen is that the reply is delayed and appears after the next
heartbeat has been sent. In this situation, my app discards 'out of date'
replies and keeps waiting (up to 8 seconds) for the genuine reply.

Charles


"Willem van Rumpt" <nothing(a)nowhere.com> wrote in message
news:OImxw###KHA.348(a)TK2MSFTNGP06.phx.gbl...
> Charles wrote:
>
>> I keep referring to this as a process, but it's really just a heartbeat.
>> A message is sent to a remote system every 10 seconds, and a reply is
>> returned. If the remote system doesn't hear a heartbeat for 20 seconds it
>> shuts down. If this happens it has to be restarted manually, so I don't
>> want it to keep shutting down.
>>
>> So that is why I say that +/- 5 seconds is acceptable. I have a timeout
>> on receiving a reply of 8 seconds. That way, if I don't get a timely
>> reply there is a wait of 2 seconds before I send the next heartbeat.
>>
>> Charles
>>
>
> A few questions come to mind:
>
> 1. What exactly does the message system look like (sockets, msmq, named
> pipe etc. etc.)? Is sending it a blocking operation?
>
> 2. Is the reply relevant, and is receival of it a blocking operation?
>
> From what I've gathered, you're sending messages to a remote system, so
> the remote system being very busy can't account for the process on your
> system timing out, or not raising a timer event on time, unless you're
> sending and receiving synchronously and waiting for the remote system to
> respond.
>
> --
> Willem van Rumpt

First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: Porting ASP.NET/SQL Server to JAVA/Oracle
Next: Get DTS datapump source columns