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

Groups > comp.lang.java.programmer > #21956 > unrolled thread

"heartbeat" approach

Back to article view | Back to comp.lang.java.programmer

Contents

  "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

#21956 — "heartbeat" approach

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.

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?

Thanks.

[toc] | [next] | [standalone]

#21958

On 2/1/2013 8: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.
>
> 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?
>
> Thanks.
>

Just synchronize on the Socket or the OutputStream.  The cost of
synchronizing in that case would be very low.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#21982

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.
>
> 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.

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 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.

Arne

[toc] | [prev] | [next] | [standalone]

#21986

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#21988

On 2/1/2013 6: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

That could be a very convenient API to get the thread running.

Arne

[toc] | [prev] | [next] | [standalone]

#22040

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

[toc] | [prev] | [next] | [standalone]

#21987

On Fri, 1 Feb 2013 08:11:14 -0800 (PST), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>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?

I wrote some proprietary  code for a large scale security camera
monitoring system perhaps 5 years ago that did just that.  IIRC
sockets are happy to have multiple writers. The alternative would be
to use a queue fed by multiple writers with a single reader.  I don't
recall writing any queue stuff until a year or so ago.

TCP/IP is completely silent unless you are actively transmitting data,
unlike many other protocols.  So if you can to detect a broken link,
you need some artificial traffic. That is why he needs a "heartbeat".
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web