PEP Items no longer written to database in Openfire 3.8.2

Openfire Openfire Dev
1

Hi,

After upgrading to 3.8.2 from 3.6.4 I noticed that PEP items are no longer written to the ofPubsubItems table. This means when the PEPService or Openfire restart current PEP items are lost until the client sends them again. Subscribed users then receive old data as the PEPService is recreated from the database.

I have tried making the PEP node persistent in the pubsub configuration, however, the ID changes every time and I get a new record in the database for the serviceID + nodeID. With 3.6.4 the id remained the same and overwrote the existing record. From what I understand, this is how it should work.

Does anyone have any pointers on how to write the latest PEP items to the table? I’m still feeling my way around Java and Openfire and diff’ing the two versions shows a lot of changes that I can’t get my head around.

Ideally I would like to write to the table each time the PEPService object is destroyed (removed from cache?, Openfire rebooted, etc). This would hopefully keep the performance increase that 3.8.2 gave me, as it isn’t writing the items every 2 minutes via a timer, but would mean that the last items are persisted and could be recovered when the PEPService is recreated. Is this a sensible way to do things?

Any help would be gratefully received as this is the last issue stopping me upgrading to 3.8.2 (I’ve had to downgrade to 3.6.4 for now)

Thanks,

Barry

2

The id change behaviour sounds pretty strange. The ID is usually created by the client. The server can autogenerate an id if none is supplied on node creation, but this would always generate a random id, even prior to the changes to pubsub in 3.8.

You can configure the pubsub service to not cache by setting the system property *xmpp.pubsub.flush.cache *to 0 (it defaults to 1000) which would turn caching off altogether so there is no risk of data loss. You can also reduce the interval between cache flushes with the property xmpp.pubsub.flush.timer. It defaults to 2min but can be reduced to as little as 20s.

You are the only one who can judge if the perfomance impacts of this are acceptable. Depending on your throughput, it may make no negligible difference at all.