Data packets where not received by the InBandByteStream due to a missing
IQRequestHandler
Conflicts:
smack-extensions/src/main/java/org/jivesoftware/smackx/bytestreams/ibb/DataListener.java
smack-extensions/src/main/java/org/jivesoftware/smackx/bytestreams/ibb/InBandBytestreamManager.java
smack-extensions/src/main/java/org/jivesoftware/smackx/bytestreams/ibb/InBandBytestreamSession.java
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.
With bb8dcc9874 the concept if IQ request
handlers was introduced in Smack. This doesn't allow packet/stanza
collectors/listeners to filter for incoming IQ requests. Unfortunately
the file transfer code relied on this being able, so it broke with the
change.
There were two places where the file transfer code was listening for
incoming IQ requests:
- InitationListener(s)
- Negotiator(s)
With this change, we let the InitiationListener signal the existence of
an incoming initation request, send by an IQ of type 'set', using the
newly created EventManager utility.
The negotiator waits for those events to arrive and proceedes as it would
have done when the packet collector was used.
the combination with concurrencyLevel and LinkedBlockingQueue never
worked as intented. The idea was that the cachedExecutorService would
spawn new threads until maximumPoolSize (=concurrencyLevel) is reached,
and then start queing the Runnables.
But this was not the case, since ThreadPoolExecutor does not take into
consideration if the worker threads is busy, i.e. executing a Runnable,
or idle, i.e. waiting for a Runnable.
This means that if a busy Worker would execute a Runnable, which would
block, because it's waiting for an event (e.g. an incoming IQ
request), then the handling of those incoming IQ request would be
queued by ThreadPoolExecutor, because no fewer threads then corePoolSize
are running and the task can be queued (since the LinkedBlockingQueue is
unbounded).
In case the users tries to save a VCard he previously retrieved via
loadVCard() this would previously fail, as the 'to' address is set to
the clients full JID.
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.
smack-bosh was recently added to androidProjects, but it was not
filtered out from the dependencies for smack-android. Since it is an
optional dependency, it should not be a dependency of smack-android.
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.
Using the term 'enabled' was a terriable choice from a security
perspective, as it gives the user the impression that the security is
"enabled". In fact this setting is only slightly better then
"disabled".
Make that fact clear in the javadoc too.
The XMPPConnection interface does not define methods to manipulate the
connection state (e.g. connect(), disconnect()). The example should use
the connection type as declared type.
Anno van Vliet
Florian Schmaus