Hello,
I am building a long running subscription based standalone application and have a couple questions around Select.Client.ConnectionState Property and Event. The app is hooked into file folders and an Office 365 / Exchange mailbox, stuffing attachments.
For testing is there a way to simulate a ConnectionState.Fatal condition so that the event fires allowing it to be tested? I've managed it one time, not repeatable. Stopping the mid-tier works for Open and Closed. Do I need to care about ConnectionState.Connecting or Broken? My guess is no, thinking they are for slow connections and I'm on a wire.
Secondly, I notice a large enough delay from the time the mid-tier goes down until the event fires. During that second or three, the connection appears cool, but isn't. So my question is, does checking the Select.Client.ConnectionState Property actually check the state at that moment? Or is there another way to determine I'm about to fail because there isn't anything to talk to.
Thanks in advance,
-Dan
Select.Client.ConnectionState Property and Event information
Moderator: Phil Barton
Select.Client.ConnectionState Property and Event information
I blog at http://DanVanFleet.com on SoftPro and other things
-
- Posts: 411
- Joined: Thu Sep 11, 2008 11:35 am
- Location: Raleigh, NC, USA
- Contact:
Re: Select.Client.ConnectionState Property and Event informa
The select client API "pings" the server every ~10 seconds. If a ping fails, the connection state value will report a broken connection.
If the next pings succeed, but the server has cleaned up the client session records (usually about 10-15 mins later), then the client is "fatally severed" and must be restarted.
If the connection resumes within a few minutes (< 10 mins), then the connection will just return to a connected state.
Asking for the connection state is just looking at the last known value. It doesn't actively check the connection. So basically, it is accurate to about 10 seconds.
You can test a fatal break by deleting to matching core.Session record in the SelectDb.
To simulate a broken connection, just stop the mid tier service for a few mins while leaving the client app (API) running.
Hope that helps!
If the next pings succeed, but the server has cleaned up the client session records (usually about 10-15 mins later), then the client is "fatally severed" and must be restarted.
If the connection resumes within a few minutes (< 10 mins), then the connection will just return to a connected state.
Asking for the connection state is just looking at the last known value. It doesn't actively check the connection. So basically, it is accurate to about 10 seconds.
You can test a fatal break by deleting to matching core.Session record in the SelectDb.
To simulate a broken connection, just stop the mid tier service for a few mins while leaving the client app (API) running.
Hope that helps!
John Morris
Sr. Software Architect
SoftPro
Sr. Software Architect
SoftPro