M
mroberts@rev.com.au
Guest
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
ort') 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
Continue reading...
ort') 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 MarkContinue reading...