|
wojciech.kapcia@tigase.net opened 4 years ago
|
|
|
Bigger log excerpt: |
|
I wonder, what actually was there and why it didn't have @wojtek What do you think? |
|
|
It happened again, or at least it seems so (logs so visibility is limited) |
|
|
I'm not sure that packets from the logs are indeed responsible. I agree it would be good to capture the exact stanza that causes the issue. |
|
|
should we modify source code that if NPE is thrown we would catch it and log stanza which caused it? |
|
|
I've looked into the code and decided to log those packets (if logging would be set to If we would catch those entries (stanzas causing the issue) we may decide to adjust this workaround. |
|
|
Fix seems sensible. One "but", with the changed code we won't receive any notifications - given it's temporary, maybe we should use |
|
|
I'm not sure if this change will be temporary as I do not know which stanza is actually causing the issue. Using default host is a good fix even for a long term and if/when we want to check what is causing this issue we can just change logging level for this class and then check logs. |
|
|
My comment about 'temporary' nature was more about logging those packets explicitly. Basically, currently with |
|
|
OK, I wrongly assumed that new "missing TO" entries were related to other issue (#issue #1075: https://projects.tigase.net/issue/issue #1075#focus=Comments-4-27110.0-0) They seems to be presence packets only. |
|
|
|
|
|
Considering the payload few comments come to mind:
|
|
|
As I've looked at I've fixed this error in the code and that should solve the issue. |
|
|
There is something generating those packets without to (they seem to originate from sess-man). Unfortunately logs in notification doesn't have anything relevant and those on the instances were already rotated.
It seems that At any rate - the issue was still happening even after update (version from 4th of September) and packets seemingly containing correct addressing: I slightly adjusted log entry and will monitor. |
|
|
There were two more cases with evidently missing "to" (packet and stanza). I'm not sure that using Still, it does seem that those presence packets should have full from/to. |
|
|
Are those presences even valid? Shouldn't they be processed by SM and |
|
|
@andrzej.wojcik It looks like that, but didn't we have mechanism that informs SM about stream closure but would allow processing of the incoming stanzas as if session was still open? |
|
|
Well, we do have a code which sends In this case, presence would be router back to the connection (as session was already closed?) and it delivers before confirmation of session close to the connection manager. Is that possible? |
|
|
It does seem impossible. Though, generated packets should still have proper addressing - maybe it's worth quickly checking out this as well? I'd lean towards dropping those packets - they are invalid, it's impossible to deliver them and they would be dropped later on either way. |
|
|
@wojtek Before I'll disable this questionable workaround, I've checked the code for possible sources of a I suppose that we may drop those packets, or maybe we should enforce setting I would suggest to "fix ACS" (add |
|
|
According to the RFC6121, section 4.5.2. Server Processing of Outbound Unavailable Presence:
Looking at this example (non-normative I suppose) we do see that it has |
|
|
The code was adjusted in default clustering and in ACS to include |
|
|
It seems the issue with weird presence is still happening and we are using build from October so it should already contain the fix. At any rate, I checked the logs and I don't see where it was generated - I adjusted logback as it was set to Current logs got copied on kotali@ec2-54-188-212-175.us-west-2.compute.amazonaws.com to /home/tigase/tigase-server/unacked/ and most relevant entries are between 54 and 56. It seems that it may be somewhat related also to CSI as it was logged before and client also generated |
|
|
(private) Excerpts from logs: |
|
|
I've reviewed code and logs and it looks like sess-man actually resends received messages on its own (same thread is used for filtering outgoing packets as it was for calling preprocess() filters). But still, I was not able to find cause of this issue. |
|
|
As I said before - the log level was not detailed enough so I did not dedicate more time to investigate it. Let's wait for the next occurrence and with more data we should be able to track it. |
|
|
Quite possibly same cause as in #issue #1271 - faulty stamping of |
|
|
Today we had another notification: I managed to get the logs: So it seems that initially when the packet arrives in Nevertheless, it's still curious why such packet ended up in |
|
|
Thank you for your comments Andrzej, merged. |
|
Referenced from commit 1 year ago
|
|
|
Referenced from commit 1 year ago
|
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Version |
tigase-server-8.2.0
|
| Spent time |
27h 45m
|
Related
-
tigase-private/systems-maintenance#98 You are not authorized to access this issue
Issue Votes (0)
Watchers (0)
Possible diff?: