Smack (4.4)

• 

  Florian Schmaus <flo@geekplace.eu> 20 Sep 2020 02341f6330e9b53938fba3c04f30785cee393fd1

  Smack 4.4.0-beta3-SNAPSHOT

  • version (version 02341f6330e9b53938fba3c04f30785cee393fd1) (diffs)
• 

  Florian Schmaus <flo@geekplace.eu> 20 Sep 2020 6837c305e86593cf968dabf4fcfd45abb1ce05ec

  Smack 4.4.0-beta2

  • version (version 6837c305e86593cf968dabf4fcfd45abb1ce05ec) (diffs)
• 

  Florian Schmaus <flo@geekplace.eu> 20 Sep 2020 4db7d787f7e4b6e525c9482d7088f673ff795026

  [tcp] Add code comment why we have to copy the ByteBuffer

  • smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XmppTcpTransportModule.java (version 4db7d787f7e4b6e525c9482d7088f673ff795026) (diffs)
• 

  Florian Schmaus <flo@geekplace.eu> 20 Sep 2020 08fc0ba0b4ecb33e882a9f3c722f5425e8772f0d

  [tcp] Improve pendingWriteInterestAfterRead code comment

  • smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XmppTcpTransportModule.java (version 08fc0ba0b4ecb33e882a9f3c722f5425e8772f0d) (diffs)
• 

  Florian Schmaus <flo@geekplace.eu> 18 Sep 2020 525ee09ea15d7843e20d2d376f343cd5fe8ab76a

  [tcp] Do not send SM ack after we send a </stream:stream>
  Do net put an ack to the queue if it has already been shutdown. Some
  servers, like ejabberd, like to request an ack even after we have send
  a stream close (and hance the queue was shutdown). If we would not
  check here, then the ack would dangle around in the queue, and be send
  on the next re-connection attempt even before the stream open.
  
  See the following trace of the MUC bookmarks integration test. The
  fact that it is a MUC test does not matter, but this test does
  disconnect the connection and reconnect it. Not how the server,
  ejabberd in this case, requests an SM ack by sending an <r/> even
  though we already send the </stream:stream>:
  
  22:22:05 SENT (4):
  <iq id='MD4UC-61' type='set'>
    <query xmlns='jabber:iq:private'>
      <storage xmlns='storage:bookmarks'>
        <conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'>
          <nick>
            Nick-P2VXD7
          </nick>
        </conference>
      </storage>
    </query>
  </iq>
  22:22:05 RECV (4):
  <r xmlns='urn:xmpp:sm:3'/>
  22:22:05 SENT (4):
  <a xmlns='urn:xmpp:sm:3' h='29'/>
  22:22:05 RECV (4):
  <message to='sinttest-7in7j-4@salem.geekplace.eu' from='sinttest-7in7j-4@salem.geekplace.eu' type='headline'>
    <event xmlns='http://jabber.org/protocol/pubsub#event&#39;>
      <items node='storage:bookmarks'>
        <item id='current'>
          <storage xmlns='storage:bookmarks'>
            <conference name='Smack Inttest: 7in7j' autojoin='true' jid='y9jcn5@conference.salem.geekplace.eu'>
              <nick>
                Nick-P2VXD7
              </nick>
            </conference>
          </storage>
        </item>
      </items>
    </event>
    <addresses xmlns='http://jabber.org/protocol/address&#39;>
      <address jid='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' type='replyto'/>
    </addresses>
  </message>
  22:22:05 RECV (4):
  <iq xml:lang='en-US' to='sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090' from='sinttest-7in7j-4@salem.geekplace.eu' type='result' id='MD4UC-61'/>
  22:22:05 SENT (4):
  <presence id='6MS6J-20' type='unavailable'/>
  <a xmlns='urn:xmpp:sm:3' h='31'/>
  <!-- We have closed the stream -->
  </stream:stream>
  <!-- But the server still requests an SM ack -->
  22:22:05 RECV (4):
  <r xmlns='urn:xmpp:sm:3'/>
  22:22:05 RECV (4):
  </stream:stream>
  22:22:05 XMPPConnection closed (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4))
  22:22:05 SENT (4):
  <a xmlns='urn:xmpp:sm:3' h='31'/>
  22:22:05 SENT (4):
  <stream:stream xmlns='jabber:client' to='salem.geekplace.eu' xmlns:stream='http://etherx.jabber.org/streams&#39; version='1.0' from='sinttest-7in7j-4@salem.geekplace.eu' xml:lang='en-US'>
  22:22:05 RECV (4): ?xml version='1.0'?>
  <stream:stream id='3379123514446782311' ver
  22:22:05 RECV (4): sion='1.0' xml:lang='en' xmlns:stream='http://etherx.jabber.org/streams&#39; xmlns='jabber:client'>
  <stream:error>
    <invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
  </stream:error>
  </stream:stream>
  22:22:05 XMPPConnection closed due to an exception (XMPPTCPConnection[sinttest-7in7j-4@salem.geekplace.eu/1415073683806426185213090] (4))
  org.jivesoftware.smack.XMPPException$StreamErrorException: invalid-xml You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
  <stream:error><invalid-xml xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
          at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:981)
          at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$700(XMPPTCPConnection.java:913)
          at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:936)
          at java.base/java.lang.Thread.run(Thread.java:834)

  • smack-core/src/main/java/org/jivesoftware/smack/util/ArrayBlockingQueueWithShutdown.java (version 525ee09ea15d7843e20d2d376f343cd5fe8ab76a) (diffs)
  • smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XMPPTCPConnection.java (version 525ee09ea15d7843e20d2d376f343cd5fe8ab76a) (diffs)
• 

  Florian Schmaus <flo@geekplace.eu> 17 Sep 2020 488d01796a5e64e9b62aecf58699daf1c3858f7c

  [tcp] Fix TlsState by aborting the channel selected callback
  Instead of breaking in case the SSLEngine signals NEED_WRAP, which
  leads to an endless loop while holding the
  channelSelectedCallbackLock, we have to return, so that the
  asynchronously invoked callback can aquire it, and do its work.

  • smack-tcp/src/main/java/org/jivesoftware/smack/tcp/XmppTcpTransportModule.java (version 488d01796a5e64e9b62aecf58699daf1c3858f7c) (diffs)