Monitor plugin fails to handle start date properly
Description
my company uses Openfire since version 3.8.2. and we have recently began using the monitoring plugin for archiving and synchronization purposes using XEP-0136 automatic archiving and retrieval. However, both the old 1.3.3 version and the newer 1.4.2 have a bug in chatsession list retrieval, though it may go unnoticed. In our case this resulted in more bandwidth being spent downloading conversations we had already downloaded once.
Specifically he monitoring plugin fails to handle correctly the start attribute in list requests. An example request would be:
The expected result would be that only chat sessions started at or after the given date will be added to the resultset.
However this does not get parsed correctly, and the data returned does not use the given date, and returns all the chat sessions regardless of date. Internally the bug seems to depend on the getAuditedStartDate inside JdbcPersistenceManager that checks for valid retrieval dates within the configured ranges, but returns null on valid retrieval dates.
public Date getAuditedStartDate(Date startDate) { long maxRetrievable = JiveGlobals.getIntProperty("conversation.maxRetrievable", ConversationManager.DEFAULT_MAX_RETRIEVABLE) * JiveConstants.DAY; Date result = null; if (maxRetrievable > 0) { Date now = new Date(); Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable); if (startDate == null) { result = maxRetrievableDate; } else if (startDate.before(maxRetrievableDate)) { result = maxRetrievableDate; } } return result; }
We fixed it by adding the "else" condition:
public Date getAuditedStartDate(Date startDate) { long maxRetrievable = JiveGlobals.getIntProperty("conversation.maxRetrievable", ConversationManager.DEFAULT_MAX_RETRIEVABLE) * JiveConstants.DAY; Date result = null; if (maxRetrievable > 0) { Date now = new Date(); Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable); if (startDate == null) { result = maxRetrievableDate; } else if (startDate.before(maxRetrievableDate)) { result = maxRetrievableDate; }else{ result = startDate; } } return result; }
I looked over the open issues and couldn't find it so I thought I would point it out. Thanks for reading ,
Environment
None
Activity
Show:
Linus November 20, 2014 at 7:04 AM
Another choice: Date result = startDate; // init result to the startDate. if (maxRetrievable > 0) { Date now = new Date(); Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable); if (startDate == null) { result = maxRetrievableDate; } else if (startDate.before(maxRetrievableDate)) { result = maxRetrievableDate; } } return result;
This issue should be reopened.
Linus November 20, 2014 at 6:39 AM
Edited
if (maxRetrievable > 0) { Date now = new Date(); Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable); if (startDate == null) { result = maxRetrievableDate; } else if (startDate.before(maxRetrievableDate)) { result = maxRetrievableDate; } else { result = startDate; } // this line is NOT in Master branch. } else { result = startDate; } // this line is in Master branch.
2014-07-31 19:22 — Does anyone have an updated .jar file with this fix included? — Hi. i originally posted the issue on the forum. i have edited it today and added a patched jar in the forum post. hope it helps. Paolo Manili
Colton Yaroschak July 31, 2014 at 5:22 PM
Does anyone have an updated .jar file with this fix included?
my company uses Openfire since version 3.8.2. and we have recently began using the monitoring plugin for archiving and synchronization purposes using XEP-0136 automatic archiving and retrieval.
However, both the old 1.3.3 version and the newer 1.4.2 have a bug in chatsession list retrieval, though it may go unnoticed.
In our case this resulted in more bandwidth being spent downloading conversations we had already downloaded once.
Specifically he monitoring plugin fails to handle correctly the start attribute in list requests. An example request would be:
<iq type="get" id="EF7617C6-8766-4F17-A4DA-0A99E5FDB303">
<list xmlns="urn:xmpp:archive" with="testuser@testdomain.com" start="2014-05-15T17:52:57Z">
<set xmlns="http://jabber.org/protocol/rsm"/>
</list>
</iq>
The expected result would be that only chat sessions started at or after the given date will be added to the resultset.
However this does not get parsed correctly, and the data returned does not use the given date, and returns all the chat sessions regardless of date.
Internally the bug seems to depend on the getAuditedStartDate inside JdbcPersistenceManager that checks for valid retrieval dates within the configured ranges, but returns null on valid retrieval dates.
public Date getAuditedStartDate(Date startDate) {
long maxRetrievable = JiveGlobals.getIntProperty("conversation.maxRetrievable", ConversationManager.DEFAULT_MAX_RETRIEVABLE) * JiveConstants.DAY;
Date result = null;
if (maxRetrievable > 0) {
Date now = new Date();
Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable);
if (startDate == null) {
result = maxRetrievableDate;
} else if (startDate.before(maxRetrievableDate)) {
result = maxRetrievableDate;
}
}
return result;
}
We fixed it by adding the "else" condition:
public Date getAuditedStartDate(Date startDate) {
long maxRetrievable = JiveGlobals.getIntProperty("conversation.maxRetrievable", ConversationManager.DEFAULT_MAX_RETRIEVABLE) * JiveConstants.DAY;
Date result = null;
if (maxRetrievable > 0) {
Date now = new Date();
Date maxRetrievableDate = new Date(now.getTime() - maxRetrievable);
if (startDate == null) {
result = maxRetrievableDate;
} else if (startDate.before(maxRetrievableDate)) {
result = maxRetrievableDate;
}else{
result = startDate;
}
}
return result;
}
I looked over the open issues and couldn't find it so I thought I would point it out.
Thanks for reading ,