[rabbitmq-discuss] odd consumer behaviour
matthias at lshift.net
Thu May 1 19:22:18 BST 2008
David.Corcoran at edftrading.com wrote:
> 1. Run the HelloClient RabbitMQ example modified slightly so that it sends
> 20 messages instead of 1.
> 2. Run the HelloServer example but with a slight change to the code. Add a
> Thread.sleep(10*1000) before the return in handleStringCall().
> 3. Now run a normal HelloServer example, without any sleep.
> What I noticed here is that the normal example doesn't run at full speed.
> It looks like the slow server is slowing down the normal one.
> 5. Kill the slow server (the one with the sleep) and the normal HelloServer
> now runs at full speed and finishes the rest of the messages within the
How exactly did you modify the HelloClient? Did you just put the original
in a 20-iteration loop?
If so, then you are issuing 20 RPCs sequentially, i.e. the client will
be waiting for the result of the previous call before issuing the next.
Each call will be handled by one of the two HelloServers you are
running. If a call gets handled by the "slow" server then it will take
10 seconds to complete. If it happens to get handled by the fast server
then it will complete nearly instantly. As soon as you stop the slow
server all remaining requests will get handled by the fast server and
hence complete quickly.
So the behaviour you are seeing is to be expected.
Were you trying to construct a load balancing test? If so you'd need to
be issuing RPCs *concurrently*. Also, the RpcServer wasn't designed for
load balancing - it will actually consume messages from the underlying
AMQP queue as fast as it can without waiting for them to be processed.
You'd have to change that.
More information about the rabbitmq-discuss