Connection state

Feb 26, 2010 at 9:20 PM


how I can ascertain whether the client is still connected with service.
Is it already implemented in AppSpace?
How can I solve it.
For every tip I thank.


Feb 27, 2010 at 1:20 PM

Hi sanja!

The XcoAppSpace is purely message-oriented. Therefore it doesn't really have a "connection state". If you want to implement something like a monitor that alerts you as soon as a worker/space has gone offline, you could do this by e.g. by regularly checking if the worker is alive by sending a simple "are you alive" message (define an own worker port for that, or run an own worker for checking the alive-ness of the whole space) which the worker answers with a simple response.

Best Regards

Feb 27, 2010 at 3:09 PM


Of course, checking a connection is not always possible. For example there is no such thing as a MSMQ connection between sender and receiver.

But unless there is a true buffer like a MSMQ queue between sender and receiver it is a common concern, if a receiver is online. If this can only safely be determined by pinging a receiver maybe we should add some help to do it. Why not provide an off the shelf PingWorker and a PingClient? The PingClient could be initialized with a PingWorker and a ping period (e.g. 10 seconds). If necessary an application can instanciate a PingClient and register an event to be notified in case the received goes offline.


Mar 1, 2010 at 6:37 AM

Hi Ralf,

Good idea, that came to my mind as well. A ping-worker/client would surely be something that is needed regularly.


Aug 6, 2010 at 1:32 PM
Hi, sorry to touch on this message. I was reading trough the entire forum actually. I was wondering if the following approach could aso not be a valid one: In case of a non-buffered connection, buffer the message locally (in the framework) and notify the component that a Port has issues. The component can then do something (like send a syslog or an snmp trap), and wait until someone (IT guy) fixes something. You do want some kind of retry scheme for your framework, where if the connection is restored, things start working again. Is this something you think would be nice in the framework, or should people build this on top of it? For me, error handling and recovery, does sound like something the framework should gracefully handle
Aug 6, 2010 at 8:02 PM

@reinervanvliet: The question always is: Should the AppSpace provide some functionality or the underlying transport or your application.

In this case it sounds like a matter of the transport. Use MSMQ or Jabber for a store and forward communication mode, I suggest.

Aug 7, 2010 at 1:32 PM
MSMQ doesn't solve this problem because of it's current implementation. I'll create a separate thread about this issue, to not 'threadjack' this topic