Smack 4.2.1-beta2-SNAPSHOT: No response received within reply timeout even before the request is sent

I am raising this observation again, as it seems to happen very frequent for slow device on first launch immediately after the apk is installed. The stanza request seems not specific but generally is on system startup after installation. Not sure if this is due to large amount of Omemo data need to be process during system up, as I do not remember such frequent reply timeout before implementing Omemo.

See also:

Smack 4.2.1-beta2-SNAPSHOT: No response received within reply timeout even when reply is received well within the specified PacketReplyTimeout.

Smack Omemo Identities Regenerate failed on slow android device due to reply timeout

=============== aTalk logcat capture on Sony Xperia Tablet S ================

08-25 09:19:24.450 E/αTalk: [14] org.jivesoftware.smack.roster.Roster.processException() Exception reloading roster

org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 10000ms (~10s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=0ibal-113)), : fromFilter (OrFilter: (FromMatchesFilter (full): null, FromMatchesFilter (ignoreResourcepart): smith476@atalk.org, FromMatchesFilter (full): atalk.org)).

at org.jivesoftware.smack.AbstractXMPPConnection$7.run(AbstractXMPPConnection.java :1560)

08-25 09:21:37.420 D/SMACK: SENT (0): BckyQ4ns69pHmGYCVndH3uG41d1r4l/sm8xngtt6GTtr</signedPreKeyPu blic>bxomkKsXqZstMjOSepmsgUp4iulcaCNDg0K5Y40NJtZLMi5fnCou mst3T4a5HMuV22DrtuTcePsQMLSSBQLojA==BaYfEh9 Rp5HJDsSROw4MIW84Ub1tkyEhEf1BFZ1pARtU<preKeyPublic

preKeyId=‘37’>BVvzWjAJlRIwDPh1tcy/PhsANiqSP6/pYW8KrFChdM9UBYMYj8B0UQic6xwPqlEPdKgan3gRFmS6Yxvy+rrjMA4ABfBOWPLFT62aTCNlKE

08-25 09:21:37.650 D/SMACK: SENT (0): <iq id='0ibal-113’ type=‘get’>30a1591ab3403f8842d938ebc363db39789de62548</ph oto>

08-25 09:21:43.380 D/SMACK: RECV (0):

08-25 09:21:43.410 D/SMACK: RECV (0):

08-25 09:21:43.410 D/SMACK: RECV (0):

1 Like

I’m considering to lower the count of published prekeys from 100 to something around 30. More should not be necessary anyway. That should reduce the amount of data that is exchanged on startup. Still, I don’t think this is the cause of the problem.

I now have a better understanding what is the actual cause of my observation. Please refer to my discussion on

Smack Omemo Identities Regenerate failed on slow android device due to reply timeout

I believe there are two folds to the problem.

1a. From the test observation, I believe the Smack/OmemoManager starts the reply timeout timer immediately after it has triggered the process to send Omemo prekeys. So the timer starts to count down while the generation of prekey is still in progress (async). On a slow device or device with AOT disabled, it takes almost 3 minutes to generate the prekeys before the actual prekey bundles are sent to the server.

1b. In order to resolve this problem, the smack must ensure the stanza reply timer is sync to the actual stanza sending i.e. the reply timer count down should only start after the stanza has been sent. Otherwise reduces the prekeys bundle to 30 will not eliminate this problem.

FYI: Actually I also faced similar problem on S3 during login process due to challenge sasl reply generation. I have to increase the reply timer to 50 seconds to get S3 to work.

1c. Even with the above problem resolved, a slow device like S3, the time taken from prekeys bundle sending and server reply is about 7 seconds for 100 prekeys bundle, I propose OmemoManager to set the reply timeout to 10 seconds to take care of some slow device or heavily loaded server during prekey bundle sending process.

aTalk currently sets the timer to 10-second globally, as I cannot find a reliable way to know prior to omemoManager prekey sending.

2a. The second problem is pending whether the android device is running with Dalvik (prior KitKat 4.4) or ART.

On Android KitKat 4.4, android introduces the ART (AOT) versus the old Dalvik (JIT). When I disable ART on my Note 3, it immediately failed the reply timeout on first apk installation/launch as it deploys the JIT approach.

2b. Even on Note 3 with ART, it takes about 4 seconds turn around time for prekeys sending and reply from server. So the current default 5 seconds may be a bit tight on a busy server.

2c. From observation, I can see that on the subsequent launching of aTalk, it is faster. Look like android device performs some cache of the earlier JIT compiled byte code even on S3.

With 1b implemented and a 10-second smack reply timer, it should resolve the problem.

Note. the stanza reply timeout also happen on other stanza iq sending even with the reply is received within 100mS. I am not sure what is the root cause of this problem. Look like some smack processes are holding the cpu resource; I see the iq reply checking is by polling.

1 Like

I cannot imagine that it takes 3 minutes to generate the prekeys. OMEMO uses pretty fast ciphers so the key generation should not take more than a few seconds even on slow devices. But I also havent tested it yet. If it really takes so long, reducing key count would actually make sense.

Actually most of 3 minutes is taken by Android JIT compilation. The time taken by prekey generation is fast.

All the timing info are highlighted in the log cat I sent earlier.

Shouldnt the JIT compilation happen at install time or am i missing something?

Only for device with Kitkat 4.4 and above with ART. I have provided a link on this topics in the other discussion. You can read more about this to understand JIT-Just in time and AOT-Ahead of time.