2
40%
master: 40%

Ran 16 Jun 2015 08:06AM UTC

Files 522

Run time 25s

Badge

Embed ▾

Committed 13 Jun 2015 05:26PM UTC coverage: 35.707% (+0.03%) from 35.677%

Job # 278.2

Build Type

push

travis-ci

Committed by

Flowdalic

Commit Message

Fix a race on graceful disconnect

A sequence of connect(), disconnect(), and connect() could cause the
connection to get disconnected again by the old reader thread, which was
blocking on disconnect because a closing stream tag was read. If the
second connect() was processed before the disconnect(), then the
connectin would get disconnected right after the second connect().

This showed up as a "strange" sequence of stanzas in the XMPP servers
log. Note that the stanza ID of the unavailable presence has a lower
number then the previous stanzas:

Jun 11 23:11:11 c2s18c2370      debug   Resource bound: smack-inttest-two-93t70@geekplace.eu/two-93t70
Jun 11 23:11:11 c2s18c2370      debug   Received[c2s]: <iq id='qn03S-26' type='get'>
Jun 11 23:11:11 c2s18c2370      debug   Received[c2s]: <presence id='qn03S-27'>
Jun 11 23:11:11 c2s18c2370      debug   Received[c2s]: <presence id='qn03S-23' type='unavailable'>
Jun 11 23:11:11 c2s18c2370      debug   Received </stream:stream>

This is because the disconnect() of the first reader thread could
generate the unavailable presence, but was blocked afterwards when
entering the synchronized disconnect(Presence unavailablePresence).

SMACK-633.

Coverage Stats

7563 of 21181 relevant lines covered (35.71%)

0.36 hits per line

igniterealtime / Smack / 278 / 2
40%
master: 40%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 278.2

igniterealtime / Smack / 278 / 2 40% master: 40%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 278.2

igniterealtime / Smack / 278 / 2
40%
master: 40%

README BADGES
x