on 02-07-2016 7:19 PM
Hi Experts.
We have an environment where releasing the changes list does not trigger cache update job as background job automatically. It take half an hour to 3 hours sometimes. Which has led me to believe somewhere during the installation cache update job's frequency may have been set to 3 hours (assumption). And depending on when we activate the change list in that window of 3 hours, it takes remaining time of that window for cache refresh.
e.g. so if I release the change list at say 1 hour of that 3 hour window, cache refresh will take 2 hours. Now if I release the change list at say 2:30 hour mark in that 3 hour window. It will take 30 minutes to refresh/update the cache.
Can you please let me know if my assumption is correct? If yes, can you please tell me where is this frequency set so that I can reset it to automatic mode or some other mode where it gets refreshed as soon as objects are activated?
If possible can you please at least redirect me to the link or navigation path where I can see this job's properties?
Regards
Saurabh
Hello Saurabh,
Please check value of a property cacheUpdateDelay of a Java service XPI Service: CPA Cache. This property controls delay (value of the property is in seconds) between cache invalidation (for example, when you activate a change list in ESR / Integration Directory) is processed and CPA cache update is triggered. By default, this property value is "0" and normally it shall not be changed, but if somebody changed it, it will cause a delay between change list being activated and CPA cache being updated.
If this property was not changed, then please collect CPA Cache trace (for example, using XPI Inspector - inspection example #1 "CPA Cache") so that it captures all time between change list activation and cache update completion, and check when delay occurs.
Regards,
Vadim
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
HI Vadim,
I ran it by my BASIS team and this is what is currently configured the mentioned environment:
And because we are not facing similar issue in another environment, I thought to get it checked there as well. This is whats configured there:
<I hope the parameters are visible to you.>
In both environments the parameter value is set to "5". Seems like it is not the one which is contributing the delay.
Can you please suggest any other plausible reasons for this delay in cache update? Also right now might want to consider another possibility if the issue is related to cache at all or not.
Please advise on this issue.
Hi Saurabh,
Check if the below SAP note applicable to your environment.
The reason for such incident is that there is no sufficient number of executor threads in the application thread pool. Usually, this is because there are multiple IDoc_AAE resource adapters and they have several threads configured in MaxReaderThreadCount property.The number of Executor threads is configured in ApplicationThreadManager -> ExecutorPoolMaxSize property. It is set to 60 by default.The problem happens when the sum of threads configured in MaxReaderThreadCount for all resource adapters exceeds the number specified in ExecutorPoolMaxSize.
Also check the below sap notes.
2043602 - AS Java hangs due to many CPA cache refreshes
2143811 - CPA Cache thread hanging on socketRead. Different issues with CPA locks after lock timeout
1997107 - Full CPA Cache refresh hangs while reading adapter metadata schema from the database
Regards,
Praveen.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Praveen,
Thanks for the info. Though I wont say my cache refresh hangs in middle. It keeps refreshing after certain intervals irrespective of when you released the change list. From the pattern I have observed so far, I think it refreshes 8 times a day. But I would like to know the place where this parameter is actually set.
Nonetheless I will pass on the information given by you to my BASIS team once.
Hi Saurabh,
Entire concept of CPA cache update is based on a an event based trigger (change list activation event), followed by invalidation of corresponding updated objects in a cache, polling new state of these objects (XML representation of these objects) and persisting this newly obtained state in a CPA cache. In a clustered environment, retrieval of new state of updated objects is done by thread of only one server node, and after CPA cache on this server node has been successfully refreshed, the thread broadcasts this update to all other cluster nodes (this is done in sake of performance, so that not every server node has to query information about updated objects, but only one of them). In this way, invalidation of a cached object and its update in a cache are decoupled. You may customize delay between cached object invalidation and request (polling) of its current state (which I mentioned in one of posts above and which shall not be changed normally).
In normal circumstances, cluster event broadcasting and cache refreshment on entire cluster shall be consistent and robust, but there is possibility to enable a periodic job that aims to resolve inconsistencies in CPA cache across cluster nodes. By default, this job is disabled. It can be enabled by setting value of a property enableCPACacheJob of a Java service XPI Service: AF Core to true. When enabled, the job will run daily. If you need to adjust periodicity of this job, make change of a value of a property updateCPACacheJobInterval[min] of the same Java service (value is in minutes, default is 1 day). Refer to a SAP Note 1611284 for more details.
It shall be noted that if you experience such issues with CPA cache update across a cluster, that are resolved by a mentioned job, then it is worth investigating why normal CPA cache update mechanism fails and why cluster events broadcasting / processing fails or is delayed. It would be great, if you or your colleagues from Basis team could collect thread dumps and CPA cache traces so that better visibility of cached object invalidation processing upon change list activation as well as cache update on every server node in a cluster, are obtained. This will indicate when delay happens and if it is cluster-wide or specific to particular server nodes.
Regards,
Vadim
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.