Timeout issues using Xco AppSpace

Feb 13, 2012 at 9:27 PM
Edited Feb 13, 2012 at 9:36 PM

Hi there!

I'm evaluating your AppSpace to control some long running server-processes and report some stats from time to time. All is working well if I "use" the 'response' and 'progress'-Port in short timespans. But sometimes there are time-consuming processes which do not report any status for lets say 5 minutes or longer.

If this happens the messages are not received by the client and I assume the network connection was reset due to an internal timeout?! Sometimes I could verify this by using the netstat command in a dosbox.

Do you know of any timeouts using this type of communication. Or does Windows reset the network-connection after some idle time? If so, how can I prevent this?

Many thanks and regards

Jan

Edit: I could try to implement some sort of a 'Keep-Alive-Signal' on the ports, just to keep the communication established...will try this tomorrow...

Coordinator
Feb 14, 2012 at 1:53 PM

Hi Jan,

Can your server actively reach the clients, or does the client need to open the connection (e.g. because the client is protected by a firewall)?

In case the server cannot connect to the clients, you are right that it is best to use keep-alive messages to keep the connection open. The internal timeout for a connection in the appspace is 60 seconds, so you can keep the connection open if you send alive messages with an interval smaller than that.

If that is not the case, a problem can be when you don't keep references to your progress/response ports on the client side. The appspace keeps ports for 60 seconds from being garbage collected - if you don't keep your own reference and no messages are received for longer than 60 seconds, it could be that the port isn't there any more and therefore no action will be triggered.

Hope I could help you!

Best Regards
Thomas

Feb 14, 2012 at 2:11 PM

Hey Thomas,

thanks for your reply.

The client opens the connection since the servers hosted in a DMZ and cannot open a connection by itself. So I will start implementing some heartbeat-logic to 'ping' all ports at 30secs.

Got another question, maybe u could answer quickly: Let's say, the client looses connection to a worker. How can I reconnect to the worker without posting or sending a new instance of my worker-object (defined in my contract).

Just see the TestSync-Function, may it be useful for this?

And a last one :) How to detect if another client has already connect to a worker?

Thanks and regards

Jan

Coordinator
Feb 15, 2012 at 9:58 AM

Hi Jan,

If you want to monitor the status of the server, it's probably best to use the Publish/Subscribe functionality. If a client is no more available, the server will automatically recognize this the next time a message and dispose of the port. When the client restarts, it can just re-subscribe to the server.

The TestSync method doesn't check a connection - it is simply for synchronously waiting until an item arrives at a port. It is useful e.g. for unit testing, but should rather not be used in real world scenarios since it somewhat contradicts the asynchronous nature of the appspace/ccr.

Concerning if another client has connected to a worker: This cannot be detected from outside - you would need to write your own functionality for that. But if you want get events from the work with multiple clients, it is not necessary to detect that, you can just use the Publish/Subscribe function which easily supports multiple connected clients.

Best Regards
Thomas