0
$\begingroup$

Rosanswers logo

I'm running a simulator backend that allows clients to connect to it using the rosservice calls. Everything works fine with a few clients connected (<20 or so) but if I try a large-scale test with 64 clients, it will fail to connect on occasion. I'm not sure exactly what the issue is. I worked around it by implementing retries and only after trying a bunch of times failing.

Is the problem with the callback queue getting overloaded? Is there a buffer of service requests that is hidden away somewhere? (I had trouble with small buffers on my data topics already, but that was a simple fix!) Maybe it's a threading thing, although the backend is currently single-threaded, and the clients are multi-threaded but just to run a spinner on a completely disjoint messaging queue for client-client communications. If the global callback queue is involved then it is only getting touched by one thread ever per process.

Thanks for any help/pointers!


Originally posted by Devin Grady on ROS Answers with karma: 1 on 2011-08-11

Post score: 0


Original comments

Comment by Devin Grady on 2011-08-12:
Yeah this was my first thought but they design someone else chose made that hard. If they are persistent, they actually keep the TCP connection live? That would probably make the "collision" on reconnect go away though. I just had hoped not to rewrite that much code of other people.

Comment by dornhege on 2011-08-11:
Are the client - service connections persistent? That might help. I think they are non-persistent by default.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Any specific service callback will only be called one at a time, even if there are several requests, they will be queued up and possibly overflow if you're calling it quickly.

If you do require each request to be sequential @dornhege 's suggestion of persistent connections will help.

However this sounds like you might want to consider a different interface design than a single service call. I suggest that you look into actionlib You could setup your simulator to be an action server which queues all the incoming requests and does whatever locking is necessary for thread saftey to interact with the simulator. With this technique you can allow it to interact with multiple clients at once and with concurrent requests in flight you can get better throughput in each cycle.


Originally posted by tfoote with karma: 58457 on 2011-08-11

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by Devin Grady on 2011-08-12:
sounds like that'll just delay the issue, rather than solve it. I assume that multiple connections made all at the same time would still hit some sort of internal buffer of connections, and the problem is that they are dropped before they can interact at all. I do not require them to be sequential

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.