Set started with Smack 4.4 to set myRoomJid to null, introduced by
ab2822be3e ("muc: also set myRoomJid to null if we have left the
room"), however the code comment still states that we "do not reset
nickname here" (and myRoomJid contains the nickname as its
resourcepart).
Reported-by: Damian Minkov <damencho@jitsi.org>
On dinamically remove the last existed presence interceptor
we also should to remove the MUC's main presence interceptor from the connection.
Fixes: 60fee7b ("[muc] Fix Presence interceptors")
I am not happy with the concept of a build system wrapper, not to say
that I despise it. There is no reason why a single machine couldn't
have multiple versions of a build system-wide installed, and there is
no reason why each developer should download an individual copy of a
build system into the developers home directory. But here we are…
This option is meant a quick and dirty hack until
XMPPConnection.sendStanza() throws a dedicated Exception in case the
connection's outgoing queue is full.
The lambda we schedule in 25ms captures a strong reference to the
XMPPConnection. However the lambda is part of the scheduled action,
which we save in the renewEntityCapsScheduledAction field. This causes
a memory leak, since the ServiceDiscoveryManager now holds a strong
reference to its XMPPConnection.
Fix this by obtaining the strong reference to the XMPPConnection, if
one still exists, within the lambda.
Fixes SMACK-926.
Reported-by: Damian Minkov <damencho@jitsi.org>
Presence interceptors where hooked into stanza sending listeners,
which are called *after* the stanza has been put on the wire, i.e., to
late for interceptors that any modifications, they may perform, to
take effect.
Fixes SMACK-925.
We now also dynamically add the MUC's main presence interceptor to the
connection.
Reported-by: Damian Minkov <damencho@jitsi.org>
Using any of the two methods is error prone, see 0e0c0a4093 ("[tcp]
Fix handling in connection exceptions when resuming a stream"), as one
can easily forget to check for connection exceptions after it
returned. There are also no longer any call sites of those methods.
Let's inline both variants of this method.
Smack would previous run into "assert smResumptionFailed != null;" at
line 407, since if a connection exception was encountered,
waitForConditionOrConnectionException() would return, but we afterards
just assumed that either SM resumption was successful or not.
