[rabbitmq-discuss] JavaClient HeartbeatSender

Fri Feb 21 11:09:30 GMT 2014

I think I understood. If HeartbeatSender is the only piece of RabbitMQ 
which creates its own executor (given that I tell it to use another 
executor for consumer work pool), then yes, I can use a custom thread 
factory and always return the same thread. This effectively make all 
HeartbeatSenders to share the same thread and yes, it is what I want.

The concern I expressed in previous email was only about the case if 
RabbitMQ can create any other executors under some circumstances. In 
that case I would not be able to distinguish between them in my thread 
factory and the same thread would be used not just for HeartbeatSenders 
but for something else. Which would be undesired behaviour.
But if there are no other executors created, your solution will work. 
(Although feels a little bit dodgy because if you introduce more 
executors later, our custom thread factory will break everything)

Yes, we are going to use multiple machines to generate load. But before 
going there we want to optimise for single machine as much as possible 
so in the end we will need smaller cluster.

Thanks for your help.

On 21/02/14 10:48, Michael Klishin wrote:
> On 21 Feb 2014, at 14:13, Dmitry Andrianov <dmitry.andrianov at alertme.com> wrote:
>
>> But it won't be possible to see that this particular newThread() is invoked by executor created by HeartbeatSender?
> If you provide a ThreadFactory, j.u.c. executors will use it. I’m not sure what you’re saying.
>
>> If we return the same thread without such checks we effectively make the entire stress testing client single threaded so it won't serve its purpose.
> You said you intend to open lots of connections. If that’s the case, all connections will share a heartbeat thread but network I/O
> threads won’t be shared. Consumer work pool executor can be shared via ConnectionFactory#setSharedExecutor (I don’t recall if this is in 3.2 or not).
>
> In practice shared consumer work pool executor makes much more difference than heartbeat sender.
> If the # of threads is a limiting factor for your test suite (can’t you just use multiple machines?),
> consider using Go client [1] for your stress tests.
>
> 1. http://github.com/streadway/amqp
>
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss