This content has been marked as final. Show 2 replies
First of all, what is your problem exactly?
What are the implications on the client API side ifMainly Performance.
this was set wrongly.
What are the max numbers ofCould you please clarify what you mean by transaction?
allowed transactions from an API ? Is there any
y setting to increase this setting , if so ??
What should the "capi_storage" parameter incapi_storage is a legacy parameter and should not be specified in the unison.ini anymore, s.t. the default value is used (OPTFH).
unison.ini be ?
Although you might have to run the calendar server utility unifhconv(should be found in your $OH/ocal/bin) not to loose any event information before removing the keyword from your unison.ini.
Here is documentation I found for the reason why we would use that utility:
// Fieldholders are records which are "attached" to other structures as
// a means of dynamically expanding the fields of a structure. This has
// been largely obsoleted by attribute lists, but some data is still kept
// in field holders, notably extra event/instance/attendee information which
// has been stored by the unical client-side library (used by old versions
// of CAPI, and old native clients for import/export of iCalendar).
// With the addition of many attributes in direct support of various
// iCalendar properties, we don't need to store this data in field holders
// anymore, and we can do away with the inefficient calls required to
// fetch and store them. However, we need to convert the existent data
// on the server to the new attributes.
Thanks for that reply Jean-Philippe,
The actual problem we have is that the client API we use was inflicting a significant performance hit ( in terms of CPU) on our Calendar server. Normally, we have about 2500 active users using native client to access and CPU utilization is around 20%.
When we have about 50 API calls hitting the server doing basic appointments and free dates range searches.
The API side kept falling over , which a TAR has been logged (TAR#: 4850071.992). While that is being investigated, I am looking from the server side of things. Hence the question of whether the entry of "capi_storage" is affecting the API calls.
Appreciate your response.