SMACK 4.1 rc3 stream resumption

Seems that smack with enabled stream management and stream resumption, doesn’t send

<resume xmlns=‘urn:xmpp:sm:3’

h=‘some-sequence-number’

previd=‘some-long-sm-id’/>

stanza after reconnecting as described in XEP-0198: Stream Management

Use -rc4 and report back if it works for you. I guess you run into the issue fixed with Only reset smSessionId if the stream is no longer resumeable · 92c76d1 · igniterealtime/Smack · GitHub

Hi guys.

I have tested the stream resumption in release version 4.1.0 and this bug is happening. I believe the problem is in method** XMPPTCPConnection.isSmResumptionPossible(), **in the last if condition:

if (shutdownTimestamp + maxResumptionMillies > current) {

  •        return false;*
    
  •    } else {*
    
  •        return true;*
    
  •    }*
    

The returned values should be in inverse order.

In addition, other bug can be found in the methods which call to XMPPTCPConnection.getMaxSmResumptionTime(). If the client, or the server, have not set any resumption time this method returns the **Integer.MAX_VALUE. **Until here all is fine, but then in some pieces of code this value returned is incremented, provoking a overflow and getting negative values from this time. You can reproduce this bug setting a listener using XMPPTCPConnection.addStanzaIdAcknowledgedListener(), In this line:

final int removeAfterSeconds = Math.min(getMaxSmResumptionTime() + 60, 12 * 60 * 60);

The variable **removeAfterSeconds **get a negative value, so the listener is never called.

if (shutdownTimestamp + maxResumptionMillies > current) {

  •        return false;*
    
  •    } else {*
    
  •        return true;*
    
  •    }*
    

The returned values should be in inverse order.

Right, thanks for reporting SMACK-654.

In addition, other bug can be found in the methods which call to XMPPTCPConnection.getMaxSmResumptionTime(). If the client, or the server, have not set any resumption time this method returns the **Integer.MAX_VALUE. **Until here all is fine, but then in some pieces of code this value returned is incremented, provoking a overflow and getting negative values from this time

Good catch, logged as SMACK-653. Note that I expect scheduled thread pool executor’s schedule to throw a IllegalArgumentException if ‘delay < 0’, which means addStanzaIdAcknowledgedListener will throw and the listener not being added at all.