How to improve performance of thread-per-connection?

[marc]

That fixes it. That is, the video never appears delayed anymore in the client. But, if you bang away on the keys in the client (sending lots of drive commands in a short amount of time), enough commands fill up (presumably since Ice is transparently delaying commands, as it does in the thread pool model when no more threads are available in the pool?) that the relay starts throwing timeout exceptions back to the client (though the commands do eventually get executed on the robot).

I'm not sure what you mean with "transparently delaying commands". Do you mean that the only dispatch thread is busy? If so, then this is expected for the thread-per-connection model, since your server can only dispatch one request at a time (since there is only one thread with one connection).

You can also configure Glacier2 to delay requests, but this is purely a configuration choice to avoid having rogue clients flood your server (and to allow for oneway batching--see the Ice manual for details).

So, that's definitely an improvement, thanks. However, it's not really an ideal, long-term solution for our architecture since it's conceivable that the robot might need to make repeating, two-way calls on the client at regular intervals (i.e. where it really does needs a return value).

Is there no other way to make a thread-per-connection client talk to Glacier2 in a duplex kinda way? Would Joe's suggestion of two communicators work? Maybe one for incoming traffic (calls from the GUI client and responses from it) and one for outgoing traffic (calls to the GUI client and responses to it)? Any other possibilities?

No, Glacier2 requires bi-directional connections, otherwise it wouldn't be any good for firewall traversal.

Multiple communicators with multiple sessions (one per communicator) would work. You could also establish multiple sessions with a single communicator, but the setup for this is probably more complex than just using multiple communicators.

[bartley]

I'm not sure what you mean with "transparently delaying commands". Do you mean that the only dispatch thread is busy? If so, then this is expected for the thread-per-connection model, since your server can only dispatch one request at a time (since there is only one thread with one connection).

Yeah, sorry, that's what I meant. By questioning it, I was just trying to show that it's likely I don't know what the heck I'm talking about and wasn't entirely sure that that's where the buffering is occurring. I stole the "transparently delaying commands" phrase from the Ice manual's discussion of the thread pool model (p. 776):

"If a thread pool is exhausted because all threads are currently dispatching a request, additional incoming requests are transparently delayed until a request completes and relinquishes its thread"

I was just wondering if the buffering is happening for the same reason. Sounds like it is, thanks.

Multiple communicators with multiple sessions (one per communicator) would work. You could also establish multiple sessions with a single communicator, but the setup for this is probably more complex than just using multiple communicators.

Ok, thanks. Both sound more complicated than what we need for now. But good to know that it's an option.

Thanks again for all your help. And sorry if I didn't sound appropriately appreciative in my last post. Your one-way proxy solution for the video really is a huge improvement over what we had! Many thanks!

best,

chris