Daniele Ricci opened 10 years ago
|
|
Yes, you are getting this right. But it looks like really rare case delivery for packet and reconnection would need to be very fast which is rather uncommon. Looking at stacktrace you provided and your analysis, we can only ignore incoming packet as this OutQueue was already processed and we cannot do anything else. For sure we should not keep OutQueue after processing by connection close as it would create bigger issues as queue could be already empty or taken by other connection which resumed stream. I would like to look deeper into this issue and find out what really happened with this connection and how it was closed before processing packet, could you provide bigger part of logs which would show why this happened? ie. that other connection appeared and forced this one to close or anything similar? |
|
Thanks for the feedback. I will provide more logs as soon as I can, probably this evening. |
|
I reproduced it in my local environment by starting 100 connections with a random interval from each other (250ms +- 1000ms) and after a while I got this: http://beta.kontalk.net/tigase-debug.txt My debug options are:
I'm sorry I can't provide more information but inspecting Tigase logs can be really exhausting (believe me, I tried). The original log file was much larger (a few MBs), I only uploaded logs around the exception (especially before the exception). |
|
Thank you for logs. Part you attached helped me find root cause of this issue. I would like to point it here that this occured only in specific case when client enabled Stream Management without resumption, sent:
and closed TCP connection just after sending stream termination. This while it is done by many XMPP clients and client libraries, it is not proper stream termination according to RFC 6120: Section 4.4. Closing a Stream in which you can read that:
which forces XMPP client to wait reasonable amount of time before closing TCP connection after sending </stream:stream>. As in your case Tigase XMPP Server was processing incoming after stream termination I suppose that your XMPP client closed TCP connection just after sending </stream:stream> I would suggest to fix this if possible (or report to client library project you are using) as it may cause lost of data as XMPP server may send you data which your client will never receive due to closing TCP connection before receiving </stream:stream> from server. However I changed logic in Stream Management to:
This should eliminate issue you are expiriencing right now and allow proper close of stream without sending errors back to senders of non acked stanzas as stream was successfully closed. |
|
Thanks! I will notify Smack developers to address this. |
|
Fixed in upcoming Smack 4.2: https://igniterealtime.org/issues/browse/SMACK-633 |
Type |
Bug
|
Priority |
Normal
|
Assignee | |
RedmineID |
3164
|
Version |
tigase-server-7.1.0
|
Spent time |
24h
|
I'm having multiple NPE in StreamManagementIOProcessor.processIncoming, all of them happening during the "stopping connection" phase.
From what I've seen from the code, looks like e.g. the server gave up the connection (or a new one came through, invalidating the old one), but the old one sent ack anyway. However, StreamManagementIOProcessor doesn't find the OutQueue instance because it has already been deleted by StreamManagementIOProcessor.sendErrorsForQueuedPackets. Am I getting this right?
Here is the stacktrace:
I'm using Tigase 7.0.2, but I can see the code of that class didn't change.