A good Ping would tell you that the network is up and the client is down
No ping - Network down.
Not sure that ping will work to a client because of firewalls and
address remapping.
You may want to take a look at session ids and timeouts to get the same
effect.
Set your session timeout long enough and check for a new session to
decide if the old data is no longer correct for the client.
Ron
On 12/11/2010 3:01 PM, am am wrote:
Hi Ron, ping is a good idea to minimize the bandwidth lost due to callback msgs
or "I am here" msgs, since there will be no xml/http transmission overhead. But
how will the ping help me to figure out if there is outage or client is down? If
there is outage, ping will not reach client, right?
________________________________
From: Ron Wheeler<[email protected]>
To: [email protected]
Sent: Fri, November 12, 2010 1:33:32 AM
Subject: Re: Using CXF asynchronously
On 11/11/2010 4:47 PM, am am wrote:
Thank you Dan, Ron for your suggestions. I will follow them, but I have one
last
question.
Using these approaches how can we discriminate between a client crash and a
network outage (client is running, we just can not connect temporarily)
Either using call backs, or "I am here messages" approach (from client), if
client is up and network fails, client is assumed crashed. Is there a
mechanism
to discriminate between outage and process crash?
You could ping the client and see if it responds.
Depends on pings getting through your firewalls.
Thank you
________________________________
From: Daniel Kulp<[email protected]>
To: [email protected]
Cc: am am<[email protected]>
Sent: Thu, November 11, 2010 11:14:23 PM
Subject: Re: Using CXF asynchronously
On Thursday 11 November 2010 9:10:32 am am am wrote:
This is a good idea. But I was thinking that this way the records will be
kept for a long time. Until the application restarts. If there is no
standard mechanism to detect client failure (and also distinction between
client failure and network failure), I will use your idea
With normal HTTP or even JMS, that really is the only option. If you write
your own TCP transport or something, it might be possible. But then things
would be getting pretty complex.
Dan
________________________________
From: Ron Wheeler<[email protected]>
To: [email protected]
Sent: Thu, November 11, 2010 2:47:03 PM
Subject: Re: Using CXF asynchronously
On client startup can you not send a message to the server?
If the server has outstanding records, it deletes them.
If not, it ignores the message and return an "I am ready" message.
On 11/11/2010 1:59 AM, am am wrote:
Hi,
I have a web service that needs to keep some kind of session with the web
clients.
I.e. a client sends request to the web service, the service makes some
internal
records and can associate the client's requests with the records.
Additionally the web service makes call backs to the client according to
internal events,
and
sends notifications to the client according to the internal records.I.e.
server
acts also as a client.
My problem is, if the client restarts, then these records become stale.
This means that the client and the server are inconsistent and the
client will receive notifications based on the stale records.
Is there a standard approach to solve this? I was thinking of sending
some
kind
of specific request to the client by the server, in the callbacks, and if
I
get
an HTTP 500 I clear the records, but I do not know if this is a good
idea. Can anyone make a suggestion on this please?
Thanks!
