Skip to content

Stanzas not always stored for one-to-one messages whilst clustered #138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Fishbowler opened this issue Dec 2, 2020 · 0 comments
Closed

Stanzas not always stored for one-to-one messages whilst clustered #138

Fishbowler opened this issue Dec 2, 2020 · 0 comments

Comments

@Fishbowler
Copy link
Member

Following a previous issue due to stanza reconstruction, itself due to missed stanza storing (see #137 and related commits for more), I've observed that some one-to-one message stanzas are not stored in the ofmessagearchive table which could cause similar issues in the future.

Using a similar construct as before, with a 2 node xmpp cluster (infrastructure here), 3 users connected.

User 1 connected to Node 1 via Smack
User 2 connected to Node 2 via Smack
User 3 connected to Node 2 via Conversations

User 1 sent a message to User 2. User 2 replied.
User 2 sent a message to User 3. User 3 replied.
User 3 sent a message to User 1. User 1 repled.

With 6 messages total, only the messages sent by User 1, on Node 1, were stored.
image
In this instance, Node 1 was the Senior cluster node.

I'm fairly certain that it's caused by this: https://github.com/igniterealtime/openfire-monitoring-plugin/blob/master/src/java/org/jivesoftware/openfire/archive/ConversationEvent.java#L57 - this was an empty string in 2015. The ConversationEvent got a stanza property in 2016.
guusdk added a commit to guusdk/openfire-monitoring-plugin that referenced this issue Dec 2, 2020
@guusdk
fixes igniterealtime#138: Process stanza in ConversationEvent
3b31db3 
When in 2015 the XEP-0313 implementation was added to the code, this API of ConversationManager got expanded to take in the complete 'stanza' element. The ConversationEvent did not have that, which is why an empty string was used instead. Later (in 2016), the stanza was made available in ConversationEvent, but that empty string never got replaced. This commit fixes that.
guusdk added a commit to guusdk/openfire-monitoring-plugin that referenced this issue Dec 2, 2020
@guusdk
fixes igniterealtime#138: Process stanza in ConversationEvent
9c09346 
When in 2015 the XEP-0313 implementation was added to the code, this API of ConversationManager got expanded to take in the complete 'stanza' element. The ConversationEvent did not have that, which is why an empty string was used instead. Later (in 2016), the stanza was made available in ConversationEvent, but that empty string never got replaced. This commit fixes that.
Fishbowler added a commit to guusdk/openfire-monitoring-plugin that referenced this issue Dec 3, 2020
@Fishbowler
fixes igniterealtime#138: Actually add the 1-to-1 stanzas to the Conv…
4a37114 
…ersationEvent
@Fishbowler Fishbowler mentioned this issue Dec 3, 2020
Merged
@guusdk guusdk closed this as completed in d01f621 Dec 8, 2020
guusdk pushed a commit that referenced this issue Dec 8, 2020
@Fishbowler @guusdk
fixes #138: Actually add the 1-to-1 stanzas to the ConversationEvent
7f94ee1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Fishbowler