LO92524: LARGE CALENDAR EVENT CAUSING LONGER TOTAL SYNC TIMES
Direct links to fixes
Closed as program error.
If a device is syncing multiple data types in the same sync and there is a large enough item in the data type that isn't synced first such that it doesn't fit in the response message and needs to be split across multiple messages, it is possible that overall sync speeds can be decreased due to the processing time for the item that doesn't fit as this processing could be done multiple times to often determine that it still doesn't fit. For example, if a device is syncing mail and calendar together and in that order and there is a large enough calendar event that it won't fit in a single message, you could see a sync that looks like this: 1. A mail is added to the response. 2. The large calendar event is prepared to be added to the response but then is too large, so the response is sent with just the mail from #1. 3. The client makes the next request and another mail is added to the next response. 4. The large calendar event (same event as #2) is prepared to be added to the response but then is too large, so the response is sent with just the mail from #3. This will repeat until there are no mails that need to be synced and the event can be added to the response. In the end, the same data (all mails and all events) is synced to the device. The only difference may be the total time to complete the sync. If the processing of the large calendar event does not take much time, nobody will probably notice this issue. However, if the large calendar event takes a significant amount of time to process each time (say it has hundreds of attendees that all need their canonical names or internet addresses looked up), a user may notice that the overall sync time is longer. Also, it will depend on how many items there are to sync. If you only have a few items to sync, you probably won't notice the issue. If you have hundreds or thousands of mails to sync (in this example; such as on an initial sync or after resetting the device), you would pay the preparation but too large processing that many times which would make it more noticeable. This issue can result with any of the data types (mail, calendar, contacts, todos) if any of them are not the previous types in the sync order and the previous types have data that needs to be synced to the device. It does not have to be just mail and then calendar such as given in this example, Given, the order of types data to sync, the number of items of each type to sync and the size of each item of each type to sync, this scenario is uncommon.
Slower than expected sync times with large Calendar events.
The IBM Traveler server has been updated to handle this scenario.
This fix will be included in IBM Traveler 18.104.22.168 and all later releases. For the latest available maintenance release see this technote: http://www.ibm.com/support/docview.wss?uid=swg24019529
Reported component name
LOTUS NOTES TRA
Reported component ID
NoSpecatt / Xsystem
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fixed component name
LOTUS NOTES TRA
Fixed component ID
Applicable component levels