cancel
Showing results for 
Search instead for 
Did you mean: 

q console error causes other client connections to hang

RV
New Contributor II

Hello experts,

Use below steps to replicate this issue.

  • Start new kdb+ process.
C:\q\w32\q.exe
  • Make the process listen to port 10000.
\p 10000
  • Create a variable and assign some value.
a:10

 

  • Start a new kdb+ process which listens on port 10001
C:\q\w32\q.exe -p 10001
  • Open a connection to the first kdb+ process.
h:hopen `::10000
  • Make sure we can execute requests on the first kdb+ process.
h"a"
10 // Successfully able to access the variable a in the first kdb+ process.

 

  • Force an error in the first kdb+ process  with below commands.
counter:{k+1}
counter[]
// This causes below error
'k
  [1]  counter:{k+1}
  • In the first kdb+ process, the q CLI shows two brackets like below.
q))
  • Now send a command from 2nd kdb+ process to the first.
h"a"

This command hangs and I have to restart the first kdb+ process. 

Is this expected behavior?

 

System Details:

Windows - KDB+ 3.6 2019.04.02 (kdb+ 32bit edition)

1 ACCEPTED SOLUTION

Jason_Fealy
New Contributor III

Yes it's expected as the first process is in debug mode - https://code.kx.com/q/basics/debug/#debugger

However, you don't need to restart the first process, you can resume or abort execution from the debugger depending on your use case. The sync message from the 2nd process should then be processed.
https://code.kx.com/q/basics/debug/#resume

https://code.kx.com/q/basics/debug/#abort

 

View solution in original post

1 REPLY 1

Jason_Fealy
New Contributor III

Yes it's expected as the first process is in debug mode - https://code.kx.com/q/basics/debug/#debugger

However, you don't need to restart the first process, you can resume or abort execution from the debugger depending on your use case. The sync message from the 2nd process should then be processed.
https://code.kx.com/q/basics/debug/#resume

https://code.kx.com/q/basics/debug/#abort