Torq Gateway/LB functionality doesn't work asyncronously with Pulse. Therefore when a long running request hits the gateway it blocks the GW and causes delays in other processes.
Query 1 – Intentionally mimicking a 10 second delay before returning a result:
.gw.syncexec["{system "sleep 10";:([] time:enlist .z.p)}[]";`rdb]
Query 2 – Executes every second inside Pulse along side query 1
.gw.syncexec["([] time:enlist .z.p)";`hdb]
What we observe is that whenever query 1 executes for 10 seconds, query 2 cannot. If I run the same test from a KDB connection doing the two queries simultaneously then it works as expected with no contention. Code below to show:
@[gw; (.gw.syncexec; "([] time:enlist .z.p)"; hdb)]
@[gw; (.gw.syncexec; "{system \"sleep 20\";:([] time:enlist .z.p)}[]"; rdb)]
Torq Gateway/LB functionality doesn't work asyncronously with Pulse. Therefore when a long running request hits the gateway it blocks the GW and causes delays in other processes.
Query 1 – Intentionally mimicking a 10 second delay before returning a result:
.gw.syncexec["{system "sleep 10";:([] time:enlist .z.p)}[]";`rdb]
Query 2 – Executes every second inside Pulse along side query 1
.gw.syncexec["([] time:enlist .z.p)";`hdb]
What we observe is that whenever query 1 executes for 10 seconds, query 2 cannot. If I run the same test from a KDB connection doing the two queries simultaneously then it works as expected with no contention. Code below to show:
@[gw; (
.gw.syncexec; "([] time:enlist .z.p)";hdb)]@[gw; (
.gw.syncexec; "{system \"sleep 20\";:([] time:enlist .z.p)}[]";rdb)]