Retrieving room topic when specifying no room history

I’ve filed this under XIFF but it’s probably (?) applicable to any client library you use.

Up till now we’ve set the ‘no history’ option on our MUC services. When clients join, they receive the room topic automatically (we just listen to the event on the room).

Now we’ve got a need to turn on room history BUT only show it in client A and not client B. To implement this we use the MUC extension on client B to join with no history.

We’ve now noticed a weird thing on client B - the room subject message isn’t sent. The spec does say ‘In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room’ so I can understand why we don’t get it when specifically asking for no history.

So bizarrely -

  • history off = room subject retrieved

  • history on and join room with no history = no room subject retrieved

Is this a bug or standard behaviour?

OK, found the line in Openfire source code - in the addMessage method:

// store message according to active strategy

if (strategyType == Type.none){

if (subjectChange) {





else if (strategyType == Type.all) {



else if (strategyType == Type.number) {

if (history.size() >= strategyMaxNumber) {

// We have to remove messages so the new message won’t exceed

// the max history size

// This is complicated somewhat because we must skip over the

// last room subject

// message because we want to preserve the room subject if

// possible.

Iterator historyIter = history.iterator();

while (historyIter.hasNext() && history.size() > strategyMaxNumber) {

if ( != roomSubject) {







So this means

  • if you have strategy set to be none you’ll always get the room subject sent to you.

  • If you have strategy set to anything but none but join the room asking for no history, you won’t get the message sent to you

  • If you have strategy set to anything but none and join asking for anything except no history, you’ll get the room message sent to you in the delayed message packets that turn up (but not necessarily as the first message received)

Found the issue on JIRA -