Skip to main content

Configuration

The mentioned options can be accessed via the instance configuration of your system (_____CONFIGURATION). All configurations, except for those that need expert parameters, will only be shown if you have an alias for the CalendarCache.

General Settings​

calendarCachingAlias​

Expert: No
Default: SystemAlias (leere Anzeige)
Type: Alias

Description
If calendar caching is used, this property defines the database alias, which is used to cache calendar entries.
Typically the ADITO system database alias is chosen here.
If no value is set, then the value 'defaultDataAlias' (Preferences) is used to determine the alias to use.

calendarCachingBlacklistEnabled​

Expert: Yes
Default: True
Type: Boolean

Description
Activates the calendar caching blacklist.
This blacklist contains calendar entries, which provoked an error and are placed on this blacklist to be prevented from being loaded.

calendarCachingPreload​

Expert: Yes
Default: True
Type: Boolean

Description
Enables preloading of the cache at server start
All calendar entries that are within a period of +/- 4 weeks are loaded into the cache, based on the date of the user’s login.

  • The period is set when the client logs in and is automatically updated if the client remains logged in for a longer period of time.

  • Only the entries of the respective user are preloaded. In the case of active subscriptions, the entries for this period are kept permanently up-to-date, otherwise the preloaded elements are updated if an element or a period that lies within the preload period is requested.

  • The Preload request is independent of the defined calendarCachedRequestLimit and is never deleted when the limit is reached.

  • If the legacy cache is used, the entries are only loaded when the client logs in for the first time and are not automatically updated.

    The entries are updated with every explicit request from the client.

calendarCachingAlwaysUseOwnerCredentials​

Expert: Yes
Default: False
Type: Boolean

Description
Always uses credentials of owner for filling cache, even if access is by another user

calendarShowErrorOnGetEntries​

Expert: Yes
Default: False
Type: Boolean

Description
If active, errors that occur when fetching calendar entries are displayed, otherwise those errors will only be logged.

calendarCachingUseLegacyCache​

Expert: Yes
Default: False
Type: Boolean

Description
If enabled, the server uses the old cache implementation from ADITO 2020 and earlier.
The legacy cache does not support continuous updates like delta requests and subscriptions for any calendar alias.
The default is false.
This option has the exact same effect as the server command line option -Dadito.calendar.useLegacyCache=true.

Properties for the new Cache​

The new properties are shown if you set the property "calendarCachingUseLegacyCache" to "false".

calendarCacheUseOptimizedFullUpdates​

Expert: Yes
Default: False
Type: Boolean

Description
Flag that allows the use of the optimized full updates in the CalenderCache.
When true, all differences of the calendar elements are determined via the UID and LAST_MODIFIED_TIME properties.

  • This means that the elements do not have to be loaded completely from the cache, which speeds up the synchronization and reduces the data transferred from the cache.

  • This only works with calendars that support the usage of the LAST_MODIFIED_TIME property.

Default is false.

calendarCachingFullUpdaterMaxChunkSize​

Expert: Yes
Default: 50
Type: Integer

Description
Specifies the maximum amount of requests for a single synchronisation performed by the full updater of the calender cache.
Default is 50.

  • If set to a value of 0 or smaller the limit is deactivated.

  • If more requests are sent to the full updater than specified by this limit, they are divided into smaller chunks and executed one after the other.

  • This limit applies to all requests, regardless of the type.

Be aware that the property calendarCachingFullUpdaterSyncPeriodLimit also limits the chunk size for a single execution based on the search period of every request.

WARNINGS:

  • The smaller the value, the more requests are carried out, which leads to just as many SQL selects when the database is used as a cache.

  • The higher the value, the higher the memory usage can be during synchronization, since all entries of the cache and the calendar are loaded into memory per chunk for synchronization.

calendarCachingFullUpdaterSyncPeriodLimit​

Expert: Yes
Default: 56
Type: Long

Description
Defines the limit for the overall time period of a single synchronisation performed by the full updater of the calender cache. The defined value specifies the sync period in days.
Default is 8 weeks (56 days).

  • If set to a value of 0 or smaller the limit is deactivated.

NOTE:
This property does only support a plain number as input.
Values like 2W, 2S and 1D are not supported.

This property defines a threshold for paging that limits the overall time span the full updater can synchronize at once, based on the requested period in days.
If the limit is reached or exceed the current chunk is executed even if maximum chunk size has not yet been reached.

The limit is only applied to requests that query a period of more than one day. All requests that query less than a full day, including queries for individual elements, are not affected by this limit.

They are only limited by the maximum chunk size. If a single request queries a longer period than the specified limit, it is divided into several smaller requests that do not exceed the specified maximum query period.

NOTE: Requests towards infinity are not divided up if the calendarCachingFullUpdaterMaxSyncYearsForInfinity property is set to 0, but they are still divided into chunks based on their search period and, if necessary, executed individually and one after the other.

WARNINGS:

  • The smaller the value, the more requests are carried out when synchronizing larger periods of time, which leads to just as many SQL selects when the database is used as a cache.

  • The higher the value, the higher the memory usage when synchronizing large periods of time, since all entries of the cache and the calendar are loaded into memory for the specified period per chunk for synchronization.

calendarCachingFullUpdaterMaxSyncYearsForInfinity​

Expert: Yes
Default: 0
Type: Long

Description
Defines a limit in years for the maximum search period of a request that specifies infinity as start or end time.
Default is 0.

If set to a value of 0 or smaller the limit is deactivated.

This limit only affects the period synchronized by the full updater of the calendar cache.

Examples:

  • The examples use 100 years as limit and 2021-01-01 as the current day. A requests from 2021-01-01 to infinity will result in actual request from 2021-01-01 to 2121-1-1

  • A request from infinity to 2021-01-01 will result in an actual request from 1970-01-01 to 2020-01-01.
    The period is limited to 1970-01-01 since this is the smallest supported system date (0ms).

  • A request form infinity to infinity will result in an actual request from 1971-01-01 to 2071-01-01.
    The search period is then calculated from +/- the half of the limit (e.g. +/- 50) depending on the current day.

NOTES:

  • When this option is disabled, infinity requests are not split into multiple smaller requests based on the threshold defined by the calendarCachingFullUpdaterSyncPeriodLimit property, which results in them always being executed one at a time when the threshold is active.

  • This property has a direct effect on internal requests made to determine reminders or performed by the CalenderSync when the calendar cache is used, since they use infinity requests by default.

WARNINGS:

  • Deactivating this limit can result in a large memory consumption when querying towards infinity, since all elements of the cache an the actual calender are loaded into memory for synchronization.

  • Setting this value too high can result in longer synchronization execution times because the request is broken up into several smaller requests that are executed one at a time. This also results in as many SQL selections when the database is used as a cache.

  • If the value is set too low, the calendar may not be updated correctly and can therefore quickly become out of date.

calendarCachedRequestLimit​

Expert: Yes
Default: 100
Type: Integer

Description
Defines the maximum number of requests that the cache can temporarily store.

  • With active subscriptions, all elements of the cached requests are automatically kept up-to-date for a limited period of time.

  • Without subscriptions the cache uses scheduled full updates for the stored requests if needed.

If the limit is exceeded, old cached requests are discarded in order to save the current ones.

The limit only applies to requests that are not covered by the preload of the cache.

calendarCachedRequestInfinityLimitation​

Expert: Yes
Default: 8 Weeks
Type: Long / Duration

Description
Defines a limitation for the search period for cached calender requests when a request against infinity is carried out.
Default is 8 weeks.

If set to value smaller or equal to 0 the default limitation will be used.

This will not prevent any request against infinity to be executed, only the actual stored request in the cache is limited to this search period.

calendarCachingMaxPendingRequests​

Expert: Yes
Default: 10
Type: Integer

Description
Number of new requests (not already stored) the cache can buffer, before sending them to the actual calender in one request if possible.
Default are 10 requests.

  • All buffered requests are merged and executed in an interval specified by the property calendarCachingPendingRequestsExecutionInterval ( Default 1 second ).

  • If the limit is exceeded, old requests in the buffer are executed immediately.

calendarCachingPendingRequestsExecutionInterval​

Expert: Yes
Default: 1 Second
Type: Long/Duration

Description
Interval in which all buffered requests are passed on to the calendar.
Default is 1 second.

Cache ohne Subscriptions​

Die Properties werden nur angezeigt, wenn

  • nicht der Legacy-Cache verwendet wird.
    → calendarCachingUseLegacyCache = false

  • keine Subscription verwendet werden (Default).
    → calendarSubscriptionsEnabled = false

Both of these parameters are expertparameters, which are only shown if explicitly defined

calendarCachingUpdateRequestInterval​

Expert: Yes
Default: 30 Sekunden
Type: Long/Duration

Description
Interval at which full updates are performed for active cached requests.
The default is 30 seconds.

Cached requests are considered active if the client executes a similar request within the lifetime (default 5 minutes) of the request.

The option is only active if the cache does not use subscriptions.

calendarCachedRequestLifetime​

Expert: Yes
Default: 5 Minuten
Type: Long/Duration

Description
The maximum time that a request is cached without being requested again by the client.
The default is 5 minutes.

The lifetime is reset when a similar request is made by the client.

The option is only active if the cache does not use subscriptions.

Cache with Subscriptions​

calendarSubscriptionsEnabled​

Expert: Yes
Default: False
Type: Boolean

Description
When active, the elements of the cache are updated for a limited time via continuous updates.

The updates are only carried out for elements which are covered by the currently cached requests (including preload).

Subscriptions are only used for calendars that support them. e.g. Exchange. The type of updates used depends on the user’s calendar, the request and the implementation of the backend within the server.

WARNING Use only für testing purposes. System may become unstable due to high cpu usage.

calendarSubscriptionsCheckerInterval​

Expert: Yes
Default: 15 Sekunden
Type: Long/Duration

Description
Interval at which the cache checks for changes in the subscriptions.
Default is 15 seconds

Checker tasks:

  • If new requests have been cached, new subscriptions are created for them.

  • If a subscription has expired, the associated request is deleted from the cache.

  • If a cached request was used again by the client, the duration of the subscription will be extended if necessary.

calendarSubscriptionsInitialDuration​

Expert: Yes
Default: 10 Minuten
Type: Long/Duration

Description
The length of time a subscription for a cached request runs when the request is first executed (stored in the cache).
Default is 10 minutes.

calendarSubscriptionsUpdateDuration​

Expert: Yes
Default: 5 Minuten
Type: Long/Duration

Description
The duration by which a subscription for a cached request is extended if the request is executed again by the client and the remaining duration of the subscription is less than the extension.
Default is 5 minutes.

calendarSubscriptionsDeltaMinInterval​

Expert: Yes
Default: 3 Minuten
Type: Long/Duration

Description
Smallest interval in which delta queries of an active delta subscription (polling) can be carried out.
Default is 3 minutes.

calendarSubscriptionsDeltaMaxInterval​

Expert: Yes
Default: 10 Minuten
Type: Long/Duration

Description
Maximum interval to which the execution of the delta queries of a delta subscription (polling) can be increased (throttling) in the event of longer inactivity of the associated request in the cache.
Default is 10 minutes.

A request is considered inactive if the client no longer executes a similar request.

The interval is set back to the original minimum if the client sends a similar request before the subscription ends.

calendarSubscriptionMaxSearchPeriod​

Expert: Yes
Default: 56 (Tage)
Type: Long

Description
Maximum search period of delta queries and subscriptions in Days.
Default is 56 days.

Note: All delta request are split in request matching the specified search period.

The minimum is 5 days and the maximum is 365 days (1 year).

calendarSubscriptionsAlwaysUseDelta​

Expert: Yes
Default: False
Type: Boolean

Description
Flag which forces the cache to only use delta requests (polling) as subscriptions for calendars, even if it supports other methods.
Default is false.

  • The setting has no effect if the cache does not use any subscriptions or the calendar does not offer any other types of subscription.

  • If a calendar does not have a delta strategy, the setting is also ignored.