From: Geoffrey B. <g....@au...> - 2006-03-08 23:29:09
|
I've had a look now. I was able to reproduce the problem you were having using a modified version of the example. I set it to pull mode without a replace rule and added a 10 second sleep between reads. As you found, the server's message queue overflowed and the client never returned from the read. I tracked the problem back to the Push function of the server's message queues. What's happening is that in pull mode without the replace rule, the data messages very quickly overflow the client queue (the default length is 32 messages). Then, when the client requests data, the server marks all messages in the queue as ready and tries to push on the sync message necessary to tell the client where the end of the requested data is, but because the queue is full, the sync push fails. The client goes on reading forever waiting for a sync that will never come while the server merrily continues on its way, producing ever more data packets. There are two ways to solve this problem. The first is to add a suitable replace rule from the client, as mentioned earlier. The second is the following patch: --- message.cc 2 Mar 2006 01:15:51 -0000 1.14 +++ message.cc 8 Mar 2006 23:15:23 -0000 @@ -369,7 +369,7 @@ } } // Are we over the limit? - if(this->Length >= this->Maxlen) + if(this->Length >= this->Maxlen && hdr->type != PLAYER_MSGTYPE_SYNCH) { PLAYER_WARN("tried to push onto a full message queue"); this->Unlock(); This will allow sync packets to be pushed onto the queue, even if it is full. I'm not sure this is a good idea, however, as the message queue has a limited length for a reason. But it would ensure that the client gets out of the read, even though the data it gets is ancient because all new data couldn't get onto the queue. I'll leave it up to someone who has access to that file to apply it if people agree it's necessary. The solutions aren't mutually exclusive, and even if that patch is used clients should still set replace rules to ensure they receive up to date data. Also, if you're not encountering this in your javaclient, that makes me wonder if your client is behaving like the C client now does. When you read while in pull mode, do you read just what is available, or do you keep reading until the sync message arrives? The latter is what you should do in pull mode to get all waiting data. The C client will do this, and while in push mode will just read a single message, then return. Geoff Radu Bogdan Rusu wrote: > Did some tests with Javaclient2.... it works fine... so I think it's a > libplayerc issue. -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |