[muscle] Re: Question about server behaviour

Hi James,
That's not the desired behavior, but it could happen if your sending client is able to send messages to the server so quickly that the server's incoming message queue never clears up. (The reason is that MessageIOGateway::DoInput() tries to read messages until there are no more messages left to read... and perhaps there are always more messages left to read in your case). You might try adding the line 

SetSuggestedMaximumTimeSlice(100000);
To the MessageIOGateway constructor (line 17 of iogateway/ MessageIOGateway.cpp) and see if that makes a difference... that will tell DoInput() to only read incoming messages for up to 100 milliseconds before going on to do other things (e.g. send buffered output messages to your receiving client). You can change the argument to taste, of course (it's in microseconds). 

Let me know if that makes a difference.

-Jeremy

On Jan 1, 2008, at 5:43 AM, James Mansion wrote:


I'm playing with MUSCLE 4.11 on my XP portable.
I've adjusted the server build to be a DumbReflectServer for convenience, and I have a couple of Java client apps - one of which pumps empty messages at the server, and one of which sucks in messages and counts the rate per second.
I also have a simple homebrew Java server implementation that implements Dumb by way of a learning tool for Apache MINA 2.0.
The behaviour of the two servers is different in a way that I had not expected. 

The Java server pretty much pumps messages as it receives them.
The C++ server, however, seems to prefer to read messages rather than to write them. If the sender application sends with little respite (a flush and 10ms sleep every 1000 messages) then the C++ server effectively just sucks in all the messages until the sender stops, and then they get spooled to the receiver.
If I increase the sleep time to 100ms then the message flow is even (at about 6000 messages per second with one sender and one receiver), with a little CPU spare on my machine. 

Is this expected behaviour?

James

Other related posts: