From 826c83a2310342217c1e58aeafdd397b75d40b72 Mon Sep 17 00:00:00 2001 From: Marc Blank Date: Thu, 10 Jun 2010 14:27:23 -0700 Subject: [PATCH] Work around problem w/ large CalendarProvider2 transactions * We're seeing binder transaction failures when we try to send more than around 1500 CPO's to CalendarProvider2 in a batch (the limit is related to memory usage in binder transactions) * When an event has A attendees and E exceptions in an event, we currently must create A*E CPO's; this number can become very large and cause a binder failure * The result of a failure is looping behavior, resulting in failed sync and very much reduced battery life * The workaround here is to redact all non-organizer and non-user attendees from exceptions once we reach half of the maximum number of CPO's. This has been determined empirically and is set to 500 CPO's in this CL * We also reduce our sync "window" to 4 calendar/contact items per sync command to help limit the potential size of our batch * For later releases, we should reconsider this and see if something that is more of a "fix", rather than a workaround, can be implemented Bug: 2760514 Change-Id: I06ca1a1ae88c772342a9e46b5997c41678e95144 --- src/com/android/exchange/EasSyncService.java | 2 +- .../exchange/adapter/CalendarSyncAdapter.java | 27 +++++++++++++++---- 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/src/com/android/exchange/EasSyncService.java b/src/com/android/exchange/EasSyncService.java index 82a375f78..3eb48c6c5 100644 --- a/src/com/android/exchange/EasSyncService.java +++ b/src/com/android/exchange/EasSyncService.java @@ -105,7 +105,7 @@ public class EasSyncService extends AbstractSyncService { public static final boolean DEBUG_GAL_SERVICE = false; private static final String EMAIL_WINDOW_SIZE = "5"; - public static final String PIM_WINDOW_SIZE = "5"; + public static final String PIM_WINDOW_SIZE = "4"; private static final String WHERE_ACCOUNT_KEY_AND_SERVER_ID = MailboxColumns.ACCOUNT_KEY + "=? and " + MailboxColumns.SERVER_ID + "=?"; private static final String WHERE_ACCOUNT_AND_SYNC_INTERVAL_PING = diff --git a/src/com/android/exchange/adapter/CalendarSyncAdapter.java b/src/com/android/exchange/adapter/CalendarSyncAdapter.java index 9a4909b20..cfefb6798 100644 --- a/src/com/android/exchange/adapter/CalendarSyncAdapter.java +++ b/src/com/android/exchange/adapter/CalendarSyncAdapter.java @@ -139,11 +139,17 @@ public class CalendarSyncAdapter extends AbstractSyncAdapter { // Maximum number of allowed attendees; above this number, we mark the Event with the // attendeesRedacted extended property and don't allow the event to be upsynced to the server - private static final int MAX_ATTENDEES = 50; + private static final int MAX_SYNCED_ATTENDEES = 50; // We set the organizer to this when the user is the organizer and we've redacted the // attendee list. By making the meeting organizer OTHER than the user, we cause the UI to // prevent edits to this event (except local changes like reminder). private static final String BOGUS_ORGANIZER_EMAIL = "upload_disallowed@uploadisdisallowed.aaa"; + // Maximum number of CPO's before we start redacting attendees in exceptions + // The number 500 has been determined empirically; 1500 CPOs appears to be the limit before + // binder failures occur, but we need room at any point for additional events/exceptions so + // we set our limit at 1/3 of the apparent maximum for extra safety + // TODO Find a better solution to this workaround + private static final int MAX_OPS_BEFORE_EXCEPTION_ATTENDEE_REDACTION = 500; private long mCalendarId = -1; private String mCalendarIdString; @@ -560,7 +566,7 @@ public class CalendarSyncAdapter extends AbstractSyncAdapter { // busyStatus is inherited from the parent unless it's specified in the exception) // Add the insert/update operation for each attendee (based on whether it's add/change) int numAttendees = attendeeValues.size(); - if (numAttendees > MAX_ATTENDEES) { + if (numAttendees > MAX_SYNCED_ATTENDEES) { // Indicate that we've redacted attendees. If we're the organizer, disable edit // by setting organizerEmail to a bogus value and by setting the upsync prohibited // extended properly. @@ -692,7 +698,7 @@ public class CalendarSyncAdapter extends AbstractSyncAdapter { logEventColumns(cv, "DTEND/DURATION missing"); return false; // Exceptions require DTEND - } else if (isException && !cv.containsKey(Events.DTEND)) { + } else if (isException && !cv.containsKey(Events.DTEND)) { logEventColumns(cv, "Exception missing DTEND"); return false; // If this is a recurrence, we need a DURATION (in days if an all-day event) @@ -853,21 +859,32 @@ public class CalendarSyncAdapter extends AbstractSyncAdapter { int exceptionStart = ops.mCount; ops.newException(cv); // Also add the attendees, because they need to be copied over from the parent event + boolean attendeesRedacted = false; if (attendeeValues != null) { for (ContentValues attValues: attendeeValues) { // If this is the user, use his busy status for attendee status String attendeeEmail = attValues.getAsString(Attendees.ATTENDEE_EMAIL); + // Note that the exception at which we surpass the redaction limit might have + // any number of attendees shown; since this is an edge case and a workaround, + // it seems to be an acceptable implementation if (mEmailAddress.equalsIgnoreCase(attendeeEmail)) { attValues.put(Attendees.ATTENDEE_STATUS, CalendarUtilities.attendeeStatusFromBusyStatus(busyStatus)); + ops.newAttendee(attValues, exceptionStart); + } else if (ops.size() < MAX_OPS_BEFORE_EXCEPTION_ATTENDEE_REDACTION) { + ops.newAttendee(attValues, exceptionStart); + } else { + attendeesRedacted = true; } - ops.newAttendee(attValues, exceptionStart); } } // And add the parent's reminder value if (reminderMins > 0) { ops.newReminder(reminderMins, exceptionStart); } + if (attendeesRedacted) { + mService.userLog("Attendees redacted in this exception"); + } } private int encodeVisibility(int easVisibility) { @@ -935,7 +952,7 @@ public class CalendarSyncAdapter extends AbstractSyncAdapter { attendeeCount++; // Allow one more than MAX_ATTENDEES, so that the check for "too many" will // succeed in addEvent - if (attendeeCount <= (MAX_ATTENDEES+1)) { + if (attendeeCount <= (MAX_SYNCED_ATTENDEES+1)) { attendeeValues.add(cv); } break;