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

Hi Dick

It is the Threading.Timer that I am using. I'm as surprised as you that the
tick gets delayed as long as it does, but it does.

I think I mentioned at the outset that originally the problem was associated
with low memory, because of a memory leak in BackupExec. This doesn't seem
to be the cause now though. It does, however, seem to be connected with high
resource use, such as when BE is running or RDP is transferring a file, but
why the latter would cause such a drain I don't know.

Charles


"DickGrier" <(E-Mail Removed)> wrote in message
news:ujlFMBd#(E-Mail Removed)...
> It is hard for me to imagine a scenario where conventional timer messages
> will be delayed sufficiently long enough to cause trouble with your
> application. 5-10 seconds is a huge window. If you really are seeing
> such a problem, the only thing that I can imagine is something that is
> seriously wrong. This certainly isn't something that I've seen. Have you
> tried System.Threading.Timer instead -- this create a threaded timer? If
> this doesn't work, I think you need to look more closely at your system to
> see where the hog resides.
>
> --
> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
> Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
> Author of Visual Basic Programmer's Guide to Serial Communications, 4th
> Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
> 2006.

Hi Cor

I haven't tried that one before, and I see it says "Timers are not
guaranteed to execute exactly when the time interval occurs, but they are
guaranteed to not execute before the time interval occurs", so perhaps it
could behave the same as the one I've got, but still worth a try.

Cheers

Charles


"Cor Ligthert[MVP]" <(E-Mail Removed)> wrote in message
news:OCYgLfd#(E-Mail Removed)...
> Charles,
>
> My aversion against the threading.timer is probably because of a bad
> experience with that one,
> However, there is another threading one.
>
> I don't know if you can use that in your environment. My experience with
> that one is fine.
> http://msdn.microsoft.com/en-us/libr...chertimer.aspx
>
> Cor
>
> "Charles" <(E-Mail Removed)> wrote in message
> news:u9ny##E#(E-Mail Removed)...
>> Hi Dick
>>
>> As I replied to Mike, 10 +/- 5 seconds would do me. I have to send a
>> keep-alive message to another system approximately every 10 seconds. The
>> other end will time-out after 25 seconds or so, which doesn't seem too
>> tight a window, and yet sometimes the interval between ticks can be 30
>> seconds or mor. I wondered about monitoring elapsed seconds, but it just
>> seemed a bit kludgy. I can't imagine I'm the only person that does this
>> sort of thing in Windows. How do other applications do it, I wonder,
>> where they have to perform tasks at regular intervals, with a reasonable
>> degree of accuracy?
>>
>> Charles
>>
>>
>> "DickGrier" <(E-Mail Removed)> wrote in message
>> news:u4PzjnD#(E-Mail Removed)...
>>> As Mike said, Windows is not a real-time OS. Thus, you cannot guarantee
>>> response.
>>>
>>> That said, you may be able to approach the accuracy that you desire.
>>> One thing to realize is that resolution and accuracy are not the same
>>> thing. And, since you will be writing code that is multi-threaded (and
>>> you have only gross control of the various thread execution), and, in
>>> addition, are executing in a non-deterministic OS, you have to careful
>>> what you ask for -- and understand that you can never be absolutely
>>> certain that you will get the precision that you seek.
>>>
>>> If you use a timer, you depend on multiple things, including the
>>> wm_timer message. You might simply create a thread that monitors
>>> elapsed milliseconds (example: Now.TimeOfDay.TotalMilliseconds). This
>>> will be more accurate than the built-in timer. It will not, however,
>>> provide any real determinism, so at the end of the day, you have to test
>>> it under load and see if it meets your needs. If not... You may not be
>>> able to get there from here.
>>>
>>> Dick
>>> --
>>> Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
>>> Lakewood, CO 80228 303-986-2179 (voice) Homepage:
>>> www.hardandsoftware.net Author of Visual Basic Programmer's Guide to
>>> Serial Communications, 4th Edition ISBN 1-890422-28-2 (391 pages)
>>> published July 2004, Revised July 2006.
>>

Hi Tom

> ThreadPool.QueueUserWorkItem

I'm not sure I follow.

Charles


"Tom Shelton" <(E-Mail Removed)> wrote in message
news:ht96sg$gu3$(E-Mail Removed)...
> Charles explained on 5/22/2010 :
>> 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
>>
>>
> ThreadPool.QueueUserWorkItem
>
> --
> Tom Shelton
>
>

I've just read Willem's reply and I get it now :-)

Charles


"Tom Shelton" <(E-Mail Removed)> wrote in message
news:ht96sg$gu3$(E-Mail Removed)...
> Charles explained on 5/22/2010 :
>> 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
>>
>>
> ThreadPool.QueueUserWorkItem
>
> --
> Tom Shelton
>
>

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@skoutsoftdotcom> wrote in message
news:#V4bDQf#(E-Mail Removed)...
> 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

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

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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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

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" <(E-Mail Removed)> wrote in message
news:OImxw###(E-Mail Removed)...
> 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