How to Generate an Accurate Timer Tick
in [Dot Net]
|
Prev: problem sending email from non-administrator account
Next: BUY SPANISH FAKE PASSPORT/FAKE SPANISH ID CARD SALE ONLINE/SWISS FALSE PASSPORT BUY/UK FAKE ID CARD
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 |