Hi Ingo, The ASN setting $TIMEOUT will only work with an interactive client application (and not on a server). You could use the UTIMER component instead for your heartbeat functionality. This will work with a UServer. I'm, however, not sure how this would help when the UServer process is forcefully killed or aborts. Hope this helps. Daniel

Hi Daniel I just tried UTIMER: Nope, doesn't work either :-( If there are more then one USERVER started (same UST), only one got the messages. Ingo

Hi Ingo, Sorry, my bad. I should have remembered this (documented) limitation. When using the UTIMER in a Uniface Server then it runs in a separate thread from the main userver process and the communication is done via the Uniface Router. And at the moment it's unfortunately not possible to address a specific shared UServer (or all of them) with UTIMER (or postmessage). So my suggestion would only work if you would limit the number for the specific UST to 1 (which would probably create an undesired bottleneck for the SOAP clients). So instead of storing the mentioned info in a instance you probably have to look for alternative ways (e.g. storing the info in a db table and add an expiration date to the data). But maybe someone else has a better idea how to tackle this. Daniel

Also, due to the stateless nature of the connection and multiple uservers per UST, you might not get back the same userver process you had on the first call, meaning that storing the persistent data in memory on the server is not likely to work in a multi user environment.  Better is probably a 'session id' with the data stored in a database, with a standard proc updating the 'last accessed' time of the stored data, and a timeout feature removing all data not accessed in an hour, or two.  You could have a process fired on the server which 'pinged' the client application using a web-service the other way, and preserved the session info if it got a response.  Iain

Hi Iain We use SOAP to communicate between two applications with allways the same session-information. Only reason for having multiple USERVER running is load balancing. So there is no need for switching between different "environments" on every call. Problem we do have, if (for what ever reason)  USERVER crash, there is still a session record in our database. This records have enough timestamp (logon, logoff, last activity,...) so it is possible to set such a session to "gone" But after wich time I should do so? At day there a calls to the SOAP-interface every few seconds, at night there will be no one for hours. So my idea was to implement a heartbeat which set the "last activity" timestamp every minute And there it is, the problem with SOAP and ASYNC :-) A second idea was to have a monitor programm and send USERVER a message. If there is no answer, then kill the record. But same problem as I could not send a distinct USERVER. a "vicious circle" :-) Ingo