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.
