by changing
stanzasToResend.addAll(unacknowledgedStanzas);
to
unacknowledgedStanzas.drainTo(stanzasToResend);
Also use sendStanzaInternal to call the callbacks, which also requires
the smEnabledSyncPoint to got signaled.
Fixes SMACK-700. Thanks to Juan Antonio for reporting this.
in afterFeaturesReceived. As this will cause
maybeCompressFeaturesReceived.reportSuccess() never to be called if the
server announces 'starttls' but security mode is set to 'disabled' and
if 'compression' is also announced.
Fixes SMACK-678.
and use weak references.
Disabling the Socks5Manager every time the connection is terminated, and
re-enabling it when it got connected again causes unwanted side
effects. Like adding a new feature to the ServiceDiscoveryManager causes
an update of the entity's capabilities, which then triggers a new outgoing
presence (announcing the new caps version).
SMACK-671
Also don't override eventually send presences on
updateLocalEntityCaps(), instead save the last sent Presence stanza and
re-send that stanza.
SMACK-669.
Roster's INSTANCE map has a weak reference to XMPPConnection, which has
a field of RosterEntry(ies), and RosterEntry has a strong reference to
XMPPConnection resulting in a cycle which is preventing XMPPConnection
from getting gc'ed.
SMACK-659.
Must use interceptors instead of sending listeners, as those are
invoked *after* the stanza has been put on the wire. Also use the
correct filter, which excludes ack messages.
Fixes SMACK-656.
The cases where reversed. Change the condition for better readability.
Also fix int and long handling in the computation of
maxResumptionMillies.
Fixes SMACK-654.
as otherwhise SynchronizationPoint may report NoResponseException when
there was in fact a success or failure reported in case there are
multiple threads waiting for the condition.
to prevent a thread from not being notified about a change of the state
of the SynchronizationPoint.
If two threads are waiting for a change, which could happen e.g. because
of a connectivity change and one thread does instantShutdown() while the
other handles connectionClosedOnError(), then only one thread, usually
the one handling connectionClosedOnError(), would be notified and
resumed.
Fixes SMACK-652.
