Hi
I've also seen this issue with our application.

My solution to this was to remove the synchronized keyword from the Session.reset function.

I've also attached a unit test we have to check for the issue.

Pete

had this one too, but I haven't changed the library so I synchronized on the "Session" (=> so locks are taken in the same order).

Erratum on the preceding comment.
Synchronizing "send" on the session created a huge performance hit when having heavy load.

Peter's was solution was the best one from the beggining and my workarround is not that good ;o)

I just put the code I used for the "reset" method :

public void reset() throws IOException {
  if (!resetting.compareAndSet(false, true)) {
    return;
  }
  try {
    if (hasResponder()) {
      if (application != null && application instanceof ApplicationExtended) {
        ((ApplicationExtended) application).onBeforeSessionReset(sessionID);
      }
      generateLogout();
      disconnect("Session reset", false);
    }
    resetState();
  }
  finally {
    resetting.set(false);
  }
}

Peter and John,
thanks for your contributions. I have changed the reset() method accordingly and have added the UnitTest (I changed it slightly to work with a pausable Executor and made it detect the deadlock programmatically).