On 04/18/2013 05:11 PM, NeilOwens wrote:
Hi there, I've deployed qpid on our embedded TI platform, and I'm seeing some
odd behaviour with long-term (36-48 hour) use, and I'd like some advice
about whether how I'm configuring and using qpid is the cause of this.
[...]
Hi Neil,
Are there any other warnings in the logs? The timeout could in theory be
caused by the timer thread getting stuck running a task of long
duration, preventing it from triggering heartbeats.
What sort of queue depths are you seeing typically? (e.g. qpid-stat -q)
On possible cause of work on the timer thread is the queue purge
operation, and I note that you have that said to kick in every 10
seconds. Was there a specific motivation to that setting? Were you
seeing expired messages building up too quickly with the default? What
sort of ttl do you set on your messages?
The proliferation of bindings and temp queues is likely caused by
recreation of receivers for the given exchanges. That could be related
to the timeouts. E.g. those connections timeout, the original queue is
deleted along with its bindings and then on reconnecting a new queue
with new bindings is created. The interesting thing would be why it
seems that is only happening on the slave.
Recreating the connection when there is any error is the right strategy.
Note that the qpid.policy is not valid for an exchange (which is what a
node of type 'topic' is implemented as). If you want the subscription
queue used by the receiver from such a node to use a ring policy you
need to move that into the 'link' sections, e.g.
<name> { create: always, assert: never, node : {type: topic}, link:{
x-declare: {auto-delete: True, exclusive: False, arguments:
{'qpid.policy_type': ring}}}
How are the two brokers on the master and slave connected/related? Do
you have federation routes set up? Or is your own application connecting
directly to both of them and sending messages to each?
The reconnect function should not spawn any threads. Can you give a
little more detail on the mysterious crash you observed? (Not that you
should need to have reconnect on, just that I don't understand exactly
whats going on there).
--Gordon.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
