CONNECTED on AppServer and Keep Alive - Forum - OpenEdge Development - Progress Community

CONNECTED on AppServer and Keep Alive

 Forum

CONNECTED on AppServer and Keep Alive

This question is answered

Hi,

OE 102B08 and 11.7.1  ... windows WebClient to Linux 64bit classic appservers (Stateless)

We connect to appservers via a standard

1) at start of session, connect to appserver hServer:connect('-URL AppServerDCS://server:port')

2) when running a remote procedure, check if hServer:CONNECTED() first, and reconnect if the server has become disconnected

3) run remote .p ON hServer if this has passed OK

Because of the myriad of customer networks failing and customers habits of going off to long lunches, the TCP connect is occasionally dropped somewhere in the middle of the connection (because of timeout or actual connection issues), and the hServer:CONNECTED returns TRUE, but then running a remote .p, we get a run-time error (9407 normally) ... Connection Failure ... when trying to run the remote procedure on the handle

The user clicks through the error, the hServer:connected then returns to FALSE, and on next try, we CONNECT ok and continue to process.

We have tried Keep Alive on the connection to see if this will keep the TCP connection active during long pauses, but still have the error occurring.  

Do any of you know of a way to

a) check programmatically if keep alive is active on the AppServer TCP connection we have established ... its not clear after config if is is actually working, or whether we have stuffed up the config?  we are using it for customers 

b) Another way of checking if the appserver handle is still connected before issuing the RUN statement?

Option A was keep alive, but we are not convinced that it is working ... would like an easier way if possible to verify that it is working (as opposed to log level 4 and wireshark :).

Option B is ... switching off "stay connected" as we call it, and connecting each time we want to hit the appserver, but with SSL enabled especially, the time taken to reestablish the connection each time causes a noticeable slowing of the UI

Option C that we don't really want to resort to yet is to change the include file we use to call the appserver, and include an option to retry the call again if we can an error like this. (3 strikes before reporting the connection failure to the user)

Thanks

Mark

Verified Answer
  • We have appserver handle check, which customer already using it (hServer:CONNECTED()) .

    I think, there is a  similar TCP handle feature planned to be added in future releases. Not sure about the specific details.

    So for now, whatever is being used already, is the good option.

    Thanks

    Jagan

All Replies
  • Hi Robert,

    can we get the keepAlive config that is being used. Below is an example of clientAsk,

    ubroker.properties, under broker instance:

    appServerKeepaliveCapabilities=allowClientASK,denyServerASK

    and from client connection url:

    "-h host -S port-AppService as -DirectConnect -AppServerKeepalive allowClientASK -clientASKActivityTimeout 30 -clientASKResponseTimeout 30"        //30 is in seconds

    I've been testing this and it worked for me. Let us look at the client configuration and  see what can be done.

    Thanks

    Jagan

  • Thanks Jagan

    On the server we had

       appServerKeepaliveCapabilities=allowClientASK,allowServerASK

       serverASKActivityTimeout=30

       serverASKResponseTimeout=30

    On the client we only had

    -AppServerKeepalive allowServerASK

    Looks like there is more there that we need to add,  I will give them a try and see how they go.

    Looks like we only got it half way ...

    Mark

  • Further reading today ... we use AppServerrDCS ... SSL ... which according the the docs does not support the keepAlive protocol ... is this your experience?

    Mark

  • yes, ASK doesn't support SSL communications, so option A is ruled out. We will look at option B and let you know.

    Thanks

    Jagan

  • We have appserver handle check, which customer already using it (hServer:CONNECTED()) .

    I think, there is a  similar TCP handle feature planned to be added in future releases. Not sure about the specific details.

    So for now, whatever is being used already, is the good option.

    Thanks

    Jagan

  • Hi Mark.

    I marked this as answered, let me know if more info is needed.

    Jagan