powered by Jive Software

Viewing and Managing Queued Messages

Hi All - Running Openfire 4.2.2 - Chat clients are Spark and Pidgin

We have some home grown processes which relay messages to a user which then distributes those to groups who are subscribed. These processes recently went bananas and started sending thousands of messages out, spamming those who were subscribed.

I’ve done some cursory research and can’t seem to find much documentation regarding message queuing and management – Aside from looking at the “queued packets” metric - Is there any way to tell how many messages are queued for delivery? Does the “queued packets” value represent that?

Additionally - are there any built in or plugins available to have more granular control over the queue? i.e. if the process went nuts again - can I review all messages from a specific user and kill those?

Any relevant reading or documentation would be helpful -
Many Thanks!

Jaime Murray

Additionally, What does a server restart do to the queue? Would it just resume on start-up or clear out?

pinging @guus

Although it’s not exactly clear to me what queue you’re referring to (Openfire has several), I’m unsure if you’ll find the level of control that you’re after in Openfire. I suspect that what you call ‘queuing’ is in reality little more than in-memory caching, waiting for some async process to finish. Depends a little on the details though.

If more granular control is needed, I suspect that a) a better definition of exactly what data, under what circumstances, are being passed to what queue, and b) implement the coveted control.

Unless the queues are database-bound (certain queues in the muc and pubsub functionality are, for example), it’s likely that a server restart would simply cause the (in-memory) queues to be cleared.

If it exists, I suppose I’m referring to the message queue. i.e. think of half a million messages being sent in a second - those all can’t immediately be delivered to their intended recipients. They have to be logged (we have IM Auditing turned on), routed, etc. There has to be some type of queue that the messages sit in waiting to be processed and eventually sent.

For Example - although not apples to apples, in the email world - if an SMTP server receives 250k messages in a second, they are stored in a message queue, being routed in order, FIFO. You can view this queue, sort by sender, delete things if something gets stuck (huge message), etc.