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
As not including "role='none'" when kicking a user will result in an
XMPPErrorException. Also there appears to be nothing in XEP-45 which
says "if role is not set, then it defaults to 'none'".
and rename documentation links from .html to .md, since
markdown-gradle-plugin will now automatically transfer the links .md to
.html.
Now users can broswe the documentation in their markdown form (e.g. via
github) and via html.
Also add a symlink from README.md to index.md in documentation/.
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).
