Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #22040

Re: "heartbeat" approach

From Arved Sandstrom <asandstrom2@eastlink.ca>
Newsgroups comp.lang.java.programmer
Subject Re: "heartbeat" approach
References <0e900395-a38a-44a1-a5bf-01cc781c8728@googlegroups.com> <510c45ba$0$293$14726298@news.sunsite.dk> <an30g1Fe3dU1@mid.individual.net>
Message-ID <jjrPs.131787$2v.28087@newsfe05.iad> (permalink)
Organization Public Usenet Newsgroup Access
Date 2013-02-03 06:51 -0400

Show all headers | View raw


On 02/01/2013 07:13 PM, Robert Klemme wrote:
> On 01.02.2013 23:46, Arne Vajhøj wrote:
>> On 2/1/2013 11:11 AM, bob smith wrote:
>>> What is the best way to handle a situation where you want a socket to
>>> send a "heartbeat" every ten minutes?  I was thinking it would be
>>> simple to have a single thread do all the "heartbeat" sending.
>
> http://docs.oracle.com/javase/6/docs/api/java/util/Timer.html
>
>>> However, that means there could be multiple threads writing to one
>>> socket.  Do I need to do anything special to have multiple threads
>>> writing to one socket?  Is there a better way?
>>
>> You can certainly let the two writing thread synchronize on
>> Socket or OutputStream objects to make it thread safe.
>
> Yes, _some_ form of synchronization is needed.
>
>> You could also funnel all writes through the same
>> thread (a writer thread) via some in memory data structure
>> (which you would then need to synchronize on).
>
> The details of course depend on the nature of the heartbeat (e.g. can it
> be omitted if there was regular traffic in the meantime?  How much delay
> for the heartbeat is allowed etc.).
>
>> The last option would end up as much more complex
>> code from start, but I believe that the design may
>> end up being preferable as the solution itself evolves.
>> Consider how many places you nee to change if you want to
>> switch from TCP to UDP.
>
> We could certainly come up with better solutions if we had more
> information about the scenario.
>
> Kind regards
>
>      robert
>
Agree with the last. It may be that dealing at the level of sockets is 
not the best way at all. It may also be that there is some discussion 
required about *what* we are calling a heartbeat, whether it is actually 
a "heartbeat" that we are wanting here, or whether external status 
polling is better.

I myself think of a heartbeat as being a periodic signal initiated by 
the server or application that is being monitored, and generally a push 
to a central monitor.

I consider that for servers ("server" being loosely defined here as 
*any* standalone app that is taking requests) that the best type of 
status checking in many circumstances is pull by a client. And the best 
type of status check is a request that looks more or less like any other 
kind of request that the server accepts. So, if I was testing a web 
server, I'd send an HTTP request; if email, an SMTP; if messaging I'd 
try to put or get a JMS message.

AHS

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

"heartbeat" approach bob smith <bob@coolfone.comze.com> - 2013-02-01 08:11 -0800
  Re: "heartbeat" approach Knute Johnson <nospam@knutejohnson.com> - 2013-02-01 08:40 -0800
  Re: "heartbeat" approach Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 17:46 -0500
    Re: "heartbeat" approach Robert Klemme <shortcutter@googlemail.com> - 2013-02-02 00:13 +0100
      Re: "heartbeat" approach Arne Vajhøj <arne@vajhoej.dk> - 2013-02-01 18:21 -0500
      Re: "heartbeat" approach Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-03 06:51 -0400
  Re: "heartbeat" approach Roedy Green <see_website@mindprod.com.invalid> - 2013-02-01 15:20 -0800

csiph-web