LONG delay at first URscript xmlrpc call - rest are fast

URCap Development
1

Hi all,

I am working on a urcap with an xmlrpc server daemon. We are implementing both the java client as well as the urscript client.

After implementing the java client, we are experiencing a LONG delay (consistently 10±0.2s) at the first execution of a urscript xmlrpc call of our program. I have placed textmsg() lines in my script writer at nearly every step of the start - the program itself starts instantly. My textmsg() lines how up in the log instantly, but hang for 10±0.2s at the line for the FIRST xmlrpc call.

image

All xmlrpc executions after that are speedy and quick.

If we comment out the java client, the urscript runs fast without delay.

Its not my xmlrpc server. In fact; I can spin up the ursim, start the daemon. Without starting the program, I can access and connect to the daemon xmlrpc server from another device. Connection and execution is fast without delay. So the problem is within polyscope.

something within polyscope - between the java client and the urscript client - is causing a delay of 10s at the first urscipt xmlrpc call.

Anyone else experienced this?
Does anyone know if the java xmlrpc client and the urscript xmlrpc client share resources, causing the urscript to block until some timeout?

2

here is a snip from the polyscope gnerated urscript:

image

there is a 10s delay between “xmlrpc built” and “connected to drive”

but this delay does not occur when:

  • the java client is commented out
  • connecting an external python client to the server running in polyscope

…how can i force the deconstruction of the java client? maybe on closeView()? would that even work?

3

Well…

it appears that the java xmlrpc client and the urscript client share some resources.

its a python server. we hadnt set any custom timeout, but after adding this line:

socket.setConnectionTimeout(0.1)

everything runs snappy with no delay. afaik - you could set it to whatever you want. We think this is an OK solution; doesnt quite feel like a hack, but also cant help but think this is really a client-side mis-behavior.

The only way reducing the connection timeout to near-zero on the server side could “fix” it is if the both the java client and urscript client share the same socket. Otherwise (ie - outside of polyscope) the server has no problem handling multiple clients and the effect of server-side connection timeout is not felt.