Fault Tolerance and Error Messaging in IPC

This issue was raised by theosjp in the Kona-Users forum on Google Groups:

I've actually stumbled over something else

/ case 1 when an expression that is having an error is executed with a sync remote get the client and server thread block. i am unable to recover client session even if \e 0 is re-issued on the server.

/ case 2 when the client used the async method, the result from the remote set/get of a variable returns the previous value (indicating that the last valid expression never executed - possibly due to blocking of the thread on server till \e 0 has been issued)

/ illustration below / new server and client session, on server set \e 0 in each case

/ case 1
  h: 3: (`"192.168.1.12";10000) 
3 
  h 4: "2+2"  / ok 
4 
  h 4: "2+\"a\"" 
/ session hangs unable to recover 
/ \e 0 on server give "type error" but blocking on client does not clear 
/ case 2
 h: 3: (`"192.168.1.12";10000) 
3ps. 
  h 3: "r:1+3"; h 4: "r" 
4 / ok 
  h 3: "r:1+\"a\""; h 4: "r" 
4 / error - previous result returned as r is not updated 
  h 3: "r:1+42"; h 4: "r" 
4 / still previous result - expr never executed 
/ reseting \e 0 on server 
  h 3: "r:1+42"; h 4: "r" 
43 / now ok 

bakul commented on what he thought should be done about this in issue #102:

IMHO only syntactically valid message should be sent. Runtime errors have to be caught during runtime so there's nothing you can do about that on the sending side. But it does mean you should be able to report them back to the sending side. To regain control in case you sent an infinite loop you need an ability to send ^C too.

There is a warning on page 318 of the 2008 printing of "q For Mortals" by Jeffrey Borror:

"Exercise caution when sending entities to a remote server. A trivial mistake could place the server into a non-responding state."

Based on this comment, I consider this issue to be an "enhancement" rather than a "feature" that is in the scope of Version 1 of Kona.

i've noticed a similar ipc issue which can cause kona to crash when a what i believe (*) is a valid expression is send via ipc, if it is not wrapped into error trap. when wrapped into error trap the client hangs.

K Console - Enter \ for help

h: 3: (`"127.0.0.1";10000); ,'$!3 / check - ok (,[,"0";];,[,"1";];,[,"2";]) . ",'$!3" / evaluate as value (,[,"0";];,[,"1";];,[,"2";]) h 4: ",'$!3" / eval in remote zsh: segmentation fault rlwrap -n ./k

notes: 1/ the server was started with \e 0. hitting enter at the console after clients' segfault displays: \e 0 syntax error

2/ when the expression in the client is wrapped with error trap the client does not crash but hangs instead: h 4: .[{. x};",'$!3";:] / unable to recover, server console appears to be ok

3/ (*) - when evaluating the same expression in k2.8 results in a valence error. however, in kdb3.2 output agrees with kona:

,'$!3 valence error ,'$!3 ^ KDB+ 3.2 2014.11.01 Copyright (C) 1993-2014 Kx Systems l32/ 2()core 3961MB theo debian-7v1 127.0.1.1 NONEXPIRE
q)\ ,'$!3 ,'[(,"0";,"1";,"2")]

kevinlawler / kona

Fault Tolerance and Error Messaging in IPC #333