Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #22040
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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