IndexOutOfBoundsException in EnetPeer - Android Client 6.2.1

edited January 2012 in Android Java (deprecated)
In my production released game, I have reports provided by the Android Market crash reporting system as follows:
at java.util.LinkedList.remove(
at de.exitgames.client.photon.EnetPeer.serializeToBuffer(
at de.exitgames.client.photon.EnetPeer.sendOutgoingCommands(
at de.exitgames.client.photon.PhotonPeer.sendOutgoingCommands(

It seems this could be a threading issue and possibly be causing other, un-reported issues with the client not processing messages correctly. I have nothing further on this exception, as it was just reported through the Android Market and I have no direct customer feedback on it. It does seem "rare", with only a few reports, but again, it could be indicative of a larger issue, so would appreciate a update to fix this in a compatible 2.x client.


  • We will take a look at what's happening but it will be hard to verify that this is fixed.
  • Thanks for looking into it. It is hard to fix things like these reports, and sometimes it is impossible without more detail which we just can't get in these scenarios, so I completely understand.
    Tobias wrote:
    We will take a look at what's happening but it will be hard to verify that this is fixed.
  • As far as I can see, the only cause for this exception would be a call to PhotonPeer.disconnect() while sendOutgoingCommands() is called at the same time.
    Maybe this happens when user-input is directly used to disconnect while some thread sends and dispatches commands.

    I added synchronization for the outgoing queues in use here. You still should not use a PhotonPeer concurrently from different threads but it should solve your problem.

    For testing, the new build is available here: ...

    I hope you can somehow verify this solution. Any feedback is welcome.
  • Thanks Tobias, you guys always amaze me with how fast you turn things around - really appreciate it. I think you are probably right about how it may be happening, and we will see what we can do to investigate further.

    We used the example/demo provided for Android as the basis for how we do disconnect/etc. and as that does the disconnect call directly and not inside the timer that is setup (which is in it's own thread), then we incorrectly assumed that was the way to do it and that the disconnect was just a message that would be processed like any other (in hind sight, it seems clear that it must not be a message at all as it shuts the timer down first). I'm betting the demo provided probably then has this same issue and should be updated (if not already in 3.x) to move that disconnect into the same thread as everything else as a "best practice" example.

    Thanks again, and we will check this test build out as best we can.
  • Thanks for pointing me to the demo. It gives a wrong impression, obviously. We will double check for next release.