Select.Client.ConnectionState Property and Event information

Discussions concerning general integration topics.

Moderator: Phil Barton

Post Reply
danvanf
Posts: 54
Joined: Fri Nov 07, 2008 10:45 am
Location: Dayton, Ohio
Contact:

Select.Client.ConnectionState Property and Event information

Post by danvanf »

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
I blog at http://DanVanFleet.com on SoftPro and other things
John Morris
Posts: 411
Joined: Thu Sep 11, 2008 11:35 am
Location: Raleigh, NC, USA
Contact:

Re: Select.Client.ConnectionState Property and Event informa

Post by John Morris »

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!
John Morris
Sr. Software Architect
SoftPro
Post Reply