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.
Other Managers, e.g. EntityCapsManager, may be notified if e.g. a
feature is added or removed. While they are notified, the state of SDM
must be consistent, therefore synchronize SDM methods that modify the
state.
Until now the reconnection used a fixed policy using random
increasing delay as the number of attempts grows. Even if
that policy is still the default one, it is now possible to
select a fixed delay policy that always waits a fixed amount
of time before trying to reconnect
