Sponge: Error PaginationService

[lesbleu]

• SpongeVanilla version: 1.11.2-7.0.0-BETA-264
• Java version: Java 8
• Operating System:
  
  
  
  
  • [x] Linux (Debian)
  
  
  • [ ] macOS
  
  
  • [x] Windows
  
  
• Plugins/Mods: No plugins, no mods.

After when player die, the pagination doesn't work correctly.
Example :

[Minecrell]

What exactly did you type in the chat to get this error?

[dualspiral]

It's not completely clear, but what @lesbleu is referring to is the fact that Sponge does not track the last viewed pagination for a player across player deaths. You can reproduce this by typing /help, dying then /page 2.

The reason is that the Pagination system stores a weak reference to the MessageReceiver. When a player dies, their EntityPlayerMP object is recreated, and the old one disposed of - so the MessageReceiver changes and the PaginationService which stores a MessageReceiver against the current pagination in a weak map can no longer find the associated player (because it technically changed).

[parlough]

I was trying to think of the best way to solve this as I need to handle something similar for conversations as well. There are a few solutions but I cannot think of any that are too clean.

[dualspiral]

The major problem is with the lookup. A weak map is a very good solution because it effectively cleans up after itself, most other solutions that I have would require manual cleaning of the map, probably by scheduled task.

What I am going to try to do is see if there is some sort of (safe) token associated with a logged in player that gets removed when a player logs out. That way, I can use a weak map with this key, and keep the pagination session persisted over deaths.

[Minecrell]

In my opinion, all player entries should be tracked using their UUIDs. There is no need to remove the pagination immediately when the player leaves the server as you might just be experiencing some connection problems. This could be implemented using a cache from Caffeine or Guava where entries expire after a while. Of course, not every MessageReceiver has an UUID so they would need to be handled differently....

[dualspiral]

Yeah, that was my other option, split the lookup map into two, one UUID based, one MessageReceiever based. Might just do that, easier in the long run.