To prevent
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:788)
at java.util.HashMap$KeyIterator.next(HashMap.java:815)
at org.jivesoftware.smackx.ping.PingManager.pingMyServer(PingManager.java:252)
at org.kontalk.service.msgcenter.MessageCenterService$3.run(MessageCenterService.java:1114)
at java.lang.Thread.run(Thread.java:818)
Thanks to Daniele Ricci for reporting this.
We can't always setup the carbons listener in the constructor of the
manager, as the our local XMPP address may not be available yet. So
setup the carbons listener on a connection listener *and* in the
constructor.
I'm not sure why i've put the removeAsyncStanzaListener() call into
the finally block. If callback.processStanza(Stanza) takes a long
time (or even blocks), then it would appear to the "no response"
handling Runnable as if there was no response, when in fact there was
one.
instead of an EntityFullJid, because according to XEP-0045 § 7.8.1.:
"The <room@service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant
JID of the inviter …"
The jids list doesn't have to be lazy initialized, because every IQ of
that type is guaranteed to contain at least one JID.
Also use ParserUtils.getJidAttribute().
for the last message. We now count the number of messages we want to
retrieve, and don't wait for another message if we have already
received all.
Thanks to King Jeong Hun for reporting this.
Fixes the following exception thrown if the user had entered a non-existend XMPP domain:
java.lang.IllegalArgumentException: Must provide at least one InetAddress
at org.jivesoftware.smack.util.dns.HostAddress.<init>(HostAddress.java:55)
at org.jivesoftware.smack.util.dns.DNSResolver.lookupHostAddress(DNSResolver.java: 56)
at org.jivesoftware.smack.util.DNSUtil.resolveDomain(DNSUtil.java:209)
at org.jivesoftware.smack.util.DNSUtil.resolveXMPPServiceDomain(DNSUtil.java:136)
at org.jivesoftware.smack.AbstractXMPPConnection.populateHostAddresses(AbstractXMP PConnection.java:626)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPC onnection.java:556)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection. java:888)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.ja va:377)
Thanks to Grigory Fedorov for reporting.
Before this, if there was a stream error response by the server to our
stream open, that error response would only be handled in the reader
thread, and the user would get a message like:
"org.jivesoftware.smack.SmackException$NoResponseException: No
response received within reply timeout. Timeout was
5000ms (~5s). While waiting for SASL mechanisms stream feature from
server"
while the server may actually sent something like
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='6785787028201586334'
from='jabbim.com'
version='1.0'
xml:lang='en'>
<stream:error>
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
</policy-violation>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Too many (2) failed authentications from this IP
address (1xx.66.xx.xxx). The address will be unblocked at 04:24:00
06.01.2017 UTC
</text>
</stream:error>
</stream:stream>
It was necessary to change saslFeatureReceived from SmackException to
XMPPException in order to return the StreamErrorException at this sync
point. But this change in return required the introduction of a
tlsHandled sync point for SmackException (which just acts as a wrapper
for the various exception types that could occurn when establishing
TLS). The tlsHandled sync point is marked successful even if no TLS
was established in case none was required and/or if not supported by
the server.
