When using the Enhanced Debugger, a UI application is very noticably slow, especially around establishing a new
session. Profiling shows that much of the overhead is caused by XMPP-data being added to the text areas that are
on the "raw sent packets" and "raw received packets" tabs of the debugger.
This commit improves performance (considerably) by:
- properly limiting the amount of lines in those text areas (this was intended but broken in the old implementation)
- buffering data to be added in batches, to reduce the amount of invocations to JTextChat.append()
As an aside: some newline-based formatting was removed. As the provided data is now already formatted, retaining that
did not make much sense anymore.
Similar fix as 9b339efbc1 ("Prevent password enforcement for SASL
anonymous") just for SASL GSSAPI. Fixes SMACK-920.
Fixes: 92f4aadfdc ("[sasl] Avoid mechanisms that need a password when none is available")
Since notify() is a rather expensive operation, we should only invoke
it once. Especially since some servers include 110 in all self
presences, not just the initially reflected one on MUC join.
The change in 52a49769f9 ("[muc] Check for self-presence first in
presence listener") caused all self-presences (MUC user status 110) to
be ignored in the further processing chain eventually invoking
checkRoleModifications() and checkAffiliationModifications(). However,
some servers (e.g., ejabberd) include 110 not only in the initial
presence but in all following, and we ant to process these.
Fixes SMACK-918
Fixes: 52a49769f9
The UserTuneIntegrationTest, in rapid succession:
- add a listener for PEP-published usertune data
- publishes a usertune
- waits for a notification to arrive
Implicit to adding the listener is the publication of a change in
Pubsub notification filtering. This can involve a stanza handshake,
as CAPS is involved.
A race condition exists where the usertune data can be published
before the notification filter has been properly applied.
The changes in this commit add a synchronzation point that ensures
that the notification filter is in place, before the usertune data
is published.
Co-authored-by: Paul Schaub <vanitasvitae@fsfe.org>
Connections like XMPPTCPConnection may still reported connected, if
they are, for example disconnected but resumable. This is already
accounted for in throwAlreadyConnectedExceptionIfAppropriate(), hence
the assert is unnecessary and leads to false negatives for
XMPPTCPConnection.
For the sake of completeness, the right condition, assuming
XMPPTCPConnection is used, for the assert would be:
assert !connected || disconnectedButResumable;
