1. 22 Jun, 2015 4 commits
  2. 19 Jun, 2015 2 commits
  3. 17 Jun, 2015 1 commit
  4. 16 Jun, 2015 2 commits
  5. 15 Jun, 2015 1 commit
  6. 11 Jun, 2015 1 commit
  7. 10 Jun, 2015 3 commits
  8. 09 Jun, 2015 1 commit
  9. 08 Jun, 2015 1 commit
    • Dave Cridland's avatar
      Do not synchronize on isClosed() · 389c17c7
      Dave Cridland authored
      There is a deadlock while reading the state variable if close() is running.
      
      This switches the state to be volatile instead - it's only written to inside
      the lengthy close() lock, so this should be reasonable.
      389c17c7
  10. 31 May, 2015 2 commits
  11. 29 May, 2015 5 commits
    • Guus der Kinderen's avatar
      OF-883: Prevent sending data to known disconnected peers. · 3e54c820
      Guus der Kinderen authored
      By closing a session when the new MINA inputClosed() handler is triggered, we run
      the risk of sending data to the peer. As that peer is known to be dead, this is
      pointless (and potentially dangerous - deadlocks have been observed that are likely
      related to this scenario).
      
      To prevent sending data during session closure, the close() method has been
      overloaded with an argument that indicates if the peer is known to be dead. When
      set, its implementation will not attempt to send data.
      3e54c820
    • Dave Cridland's avatar
      OF-910 - Error stanzas to MUC room should remove occupants · b0a11dae
      Dave Cridland authored
      Currently, only stanzas containing errors of type cancel will cause the
      occupant to be removed, however this doesn't appear to catch and remove many
      occupants in practise.
      
      This patch therefore removes occupants from the service on any message or
      presence error stanza, irrespective of the error type. IQ stanzas do not
      trigger the same response, as these may be due to lack of client support
      rather than a vanished occupant.
      b0a11dae
    • Guus der Kinderen's avatar
      OF-883 & OF-881: Avoid potential deadlock with close listeners. · 9e95c34f
      Guus der Kinderen authored
      The close listeners should not be called from within a synchronized block.
      9e95c34f
    • Guus der Kinderen's avatar
      OF-883: Prevent multiple closes of the same connection. · 0cd1edef
      Guus der Kinderen authored
      When a connection is closed, several events can be involved (and can be triggered).
      Some of these events will attempt to close the connection (if it hadn't been already).
      This, at best, least to multiple invocations of close-listeners. At worst, a loop of
      close-calls is created.
      
      This commit replaces the two-way boolean that guards closure (isClosed) with a
      three-way guard. Now, a distinction is made between between a connection that is
      closed, and one that is closing.
      
      Additionally, some null pointer guards have been added, as I've seen those pop up in
      my local logs during development.
      0cd1edef
    • Guus der Kinderen's avatar
  12. 28 May, 2015 3 commits
  13. 01 May, 2015 3 commits
  14. 29 Apr, 2015 2 commits
  15. 26 Apr, 2015 1 commit
  16. 25 Apr, 2015 1 commit
  17. 21 Apr, 2015 1 commit
  18. 20 Apr, 2015 1 commit
  19. 10 Apr, 2015 3 commits
  20. 09 Apr, 2015 1 commit
    • Dave Cridland's avatar
      Change OF-888 fix to be based on error · 5115f9b8
      Dave Cridland authored
      OF-888 is presumed to be a recursion due to an attempt to bounce a bounce, in
      other words it's failing to handle a double-bounce.
      
      It appears to be caused when routing a stanza from a MUC fails, and for some
      reason I don't yet understand, the routing of the bounce to the originating
      MUC source also fails.
      
      The test for the double bounce is only present for the IQ case, but this fails
      in any case because it tests only for the IQ case, and uses a test which checks
      the IQ's symbolic type; this is not actually set by Packet.setError(), so does
      not trigger.
      
      Tom's fix inserted a sentinel into the original failing stanza, however a new
      stanza is created for the bounce, which will not contain the sentinel; therefore
      the fix will not protect from a recursion.
      
      Therefore this patch:
      
      1) Removes Tom's fix for OF-888.
      
      2) Tests for the message and presence error types.
      
      3) Tests for the presence of a stanza error (though this is a warning).
      
      4) Explicitly sets the stanza error type.
      5115f9b8
  21. 07 Apr, 2015 1 commit