Guus reports the following infinite recursing causing a
StackOverflowError:
Exception in thread "main" java.lang.StackOverflowError
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:142)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraphInternal(ModularXmppClientToServerConnection.java:399)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.walkStateGraph(ModularXmppClientToServerConnection.java:339)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.shutdown(ModularXmppClientToServerConnection.java:551)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.instantShutdown(ModularXmppClientToServerConnection.java:530)
at org.jivesoftware.smack.AbstractXMPPConnection.notifyConnectionError(AbstractXMPPConnection.java:1024)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.access$100(ModularXmppClientToServerConnection.java:134)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$1.notifyConnectionError(ModularXmppClientToServerConnection.java:185)
at org.jivesoftware.smack.websocket.impl.AbstractWebSocket.onWebSocketFailure(AbstractWebSocket.java:128)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.onWebSocketFailure(Java11WebSocket.java:162)
at org.jivesoftware.smack.websocket.java11.Java11WebSocket.disconnect(Java11WebSocket.java:146)
at org.jivesoftware.smack.websocket.XmppWebSocketTransportModule$XmppWebSocketTransport.disconnect(XmppWebSocketTransportModule.java:265)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection$CloseConnectionState.transitionInto(ModularXmppClientToServerConnection.java:1086)
at org.jivesoftware.smack.c2s.ModularXmppClientToServerConnection.attemptEnterState(ModularXmppClientToServerConnection.java:472)
...
This is because sendClose() in Java11WebSocket.disconnect() throws,
potentially because the output stream is already closed. We previously
would feed the exception into the onWebSocketFailure(Exception)
machinery, which would then again attempt a disconnect.
Since a failed sendClose() is nothing that needs special handling, we
simply log the exception as error. Furthermore, we only issue
sendClose() if the WebSocket's output is still open, i.e., if there is
a chance that it actually works.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
Previously low-level tests where run, potentially multiple times, with
the default connection descriptor.
Reported-by: Guus der Kinderen <guus@goodbytes.nl>
While markdown is easier to write, Smack's markdown documentation was
never tightly coupled with the source. For example, the markdown
documentation never provided links to the actual Java classes and
methods. This poses the risk that the documentation and the code
diverge over time. Furthermore, javadoc is constantly improving (for
example @snippet annotations) and I expect that one will be able to
write javadoc in markdown.
Fixes SMACK-928.
When enabled, the websocket implementation will attempt to use two implicit endpoints, using these URLs:
- `wss://[host]:5443/ws`
- `ws://[host]:5443/ws`
These endpoints should include ports that are used by default by known implementations, such as 5280/5281 (Prosody) and 7070/7443 (Openfire).
Set started with Smack 4.4 to set myRoomJid to null, introduced by
ab2822be3e ("muc: also set myRoomJid to null if we have left the
room"), however the code comment still states that we "do not reset
nickname here" (and myRoomJid contains the nickname as its
resourcepart).
Reported-by: Damian Minkov <damencho@jitsi.org>
On dinamically remove the last existed presence interceptor
we also should to remove the MUC's main presence interceptor from the connection.
Fixes: 60fee7b ("[muc] Fix Presence interceptors")
I am not happy with the concept of a build system wrapper, not to say
that I despise it. There is no reason why a single machine couldn't
have multiple versions of a build system-wide installed, and there is
no reason why each developer should download an individual copy of a
build system into the developers home directory. But here we are…
This option is meant a quick and dirty hack until
XMPPConnection.sendStanza() throws a dedicated Exception in case the
connection's outgoing queue is full.
The lambda we schedule in 25ms captures a strong reference to the
XMPPConnection. However the lambda is part of the scheduled action,
which we save in the renewEntityCapsScheduledAction field. This causes
a memory leak, since the ServiceDiscoveryManager now holds a strong
reference to its XMPPConnection.
Fix this by obtaining the strong reference to the XMPPConnection, if
one still exists, within the lambda.
Fixes SMACK-926.
Reported-by: Damian Minkov <damencho@jitsi.org>
Presence interceptors where hooked into stanza sending listeners,
which are called *after* the stanza has been put on the wire, i.e., to
late for interceptors that any modifications, they may perform, to
take effect.
Fixes SMACK-925.
We now also dynamically add the MUC's main presence interceptor to the
connection.
Reported-by: Damian Minkov <damencho@jitsi.org>
