Pubsub get all items started returning a subset of items after adding plugin

Hi.

I am using strophe-js in a javascript project to fetch items from a pubsub node with an iq stanza.

My pubsub configuration is an open access model, persist items to storage and max number of items to persist is -1 (unlimited, I guess?)

I am fetching without max_items, and as the standard specifices, it would always return all items in the pubsub node.

At some point I added a plugin which implements the PacketInterceptor, however I am never rejecting any packages, so in terms of Openfire I should only have added some computing time to some messages.

However, after adding this plugin my pubsub get items call started returning only a subset of the items it had, usually only the newest item.

I am generally only publishing around 3-4 items in a pubsub node.

I am NOT getting any XEP-0059: Result Set Management, so it doesn’t seem like Openfire is actively truncating the results.

Note: If I add the max_items to the call, I will receive all items again.

Does anybody have an explanation for this behavior?

That’s curious. I’m not seeing how PacketInterceptor would be a factor here.

My best guess is that it’s something cache-related. Our pubsub persistence provider uses a write-behind cache. Perhaps that’s causing issues?

Try creating or updating the property with the name provider.pubsub-persistence.className to value org.jivesoftware.openfire.pubsub.DefaultPubSubPersistenceProvider. You need to restart Openfire afterward. This will remove the write-behind cache decorator.

Thanks for the fast reply @guus

I tried your suggestion, but it didn’t work.

It could also be our event handling regarding openfire in the frontend is to blame - it is just curious that it only started happening after adding the plugin :slight_smile:

Can you provide a dump of the traffic that is exchanged between client and server? That serves two purposes:

  1. Verify if this is an Openfire issue, or something related to your client frontend event handling (as suggested)
  2. It shows the actual requests that we can use to reproduce the problem.

Is this problem happening consistently (for each request), or just occasionally?