It was a *very* bad idea to perform the SecurityMode.Required check in
the connection's reader thread and not at the end of
AbstractXMPPConnectin's connect(). :/
This behavior dates back to 8e750912a7
Fixes SMACK-739
The problem caused by opening input/ output stream before setting ssl
parameters to SSLSession and fixed by changing order of this operations.
Fixes SMACK-712.
Minor-Modifications-By: Florian Schmaus <flo@geekplace.eu>
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.
The cases where reversed. Change the condition for better readability.
Also fix int and long handling in the computation of
maxResumptionMillies.
Fixes SMACK-654.
Previously Smack would put messages in the unacknowledgedStanzas queue
after it received the 'enabled' element, when it should do so right
after sending the 'enable' stream element.
Imagine a session where '-->' denotes "received from server" and '<--'
"sent to server"
<-- enable
--> iq roster push set
--> presence some presence
<-- iq roster push result
--> enabled
then Smack would not add the iq roster push result stanza to the
unacknowledgedStanzas queue.
This fixes the issue by initializing the unacknowledgedStanzas queue
when the writer thread encounters a 'Enable' stream element.
The additional 'instanceof' invocation in the writer thread should not
be a big performance issue, since the existing "instanceof Stanza" check
should be the common case and the "instanceof Enable" is an exclusive
alternative to this case.
Instead of always bundling when the queue is empty, only bundle once the
queue has become empty and then only if it has been become empty again.
The previous algorithm would also bundle and defer the last element
found in the queue. This is not the case now.
in XMPPTCPConnection.
So that the hostname and not the IP is available to the SSLSocket and
the SSLSession, which handed over to HostnameVerifier. This leaves the
HostnameVerifier with the
- name of the XMPP service (first argument of verify(String, SSLSession)
- name of the used host (found in the SSLSession)
allowing more complex verification mechanisms performed by the
HostnameVerifier.
to allow graceful connectionClosedOnError() disconnects, since we
received a bunch of reports where the counter seems wrong, which is
causing a NPE in a thread pool executor, causing the VM or Android App
to terminate.
Now we throw the StreamManagementCounterError instead.
and remove getConnectionID().
Also make streamId a field of AbstractXMPPConnection. Most XMPP
connection types have a streamId, it appears to be optional when BOSH
is used though.
instead of just logging a warning if the XMPP domain has no DNS SRV
lookups, create the failedAddresses list now within DNSUtil and add the
information that the SRV lookup failed.
In initConnection, only initReaderAndWriter() throws IOException.
connectUsingConfiguration doesn't need to take an argument.
PacketReader.init does not throw a SmackException.
Use Async.go() in PacketWriter, just like it's already done in PacketReader.
from o.jsmack.tcp.sm, as XEP-198 Stream Management is not an "XMPP over
TCP" exclusive feature. It could also be use together with the Websocket
binding of XMPP, so we may have a smack-streammangement in the
future. This change prepares for that by moving the SM code out of the
XMPP TCP package namespace.
if connect() was not previously called. Previously calling login() with
arguments would not check for the preconditions.
The check to throw needs to be performed in AbstractXMPPConnection
before every 'abstract login(Non)Anonymously()' call. That's the two
lines that check the preconditions are duplicated.
Also fix NPE in
XMPPTCPConnection.throwNotConnectedExceptionIfAppropriate() when
packetWrite is null (i.e. if the connection was never connected before).
InterruptedExceptions should be treated as the users intention to
'cancel' the current thread's task. There is no such thing as a
spurious interrupt (not to be confused with "spurious wakeups").
after at most 12 hours.
Also set a keep alive time for the removeCallbacksService to 30 seconds
and add AbstractXMPPConnection.schedule(Runnable, long, TimeUnit).
Note that the logic determining the max resumption time has changed,
Math.min() is now used instead of Math.max(). This should match the real
life situation, e.g. if the server announced a max resumption time of 10
minutes and the client one of 5, then it should be assumed that the
connection/stream state is dropped by the parties after 5 minutes.
