The quick answwr regarding thsi exception... 10/30/09 10:14:36:304 SGT 00000073 SystemErr R java.lang.RuntimeException: Cache query timed out after 60s 10/30/09 10:14:36:304 SGT 00000073 SystemErr R at com.ibm.websphere.personalization.resources.cache.CacheManager.get(CacheManager.java:491) 10/30/09 10:14:36:304 SGT 00000073 SystemErr R at com.ibm.websphere.personalization.resources.ResourceDomainWrapper.findResourcesByQuery(ResourceDomainWrapper.java:358) 10/30/09 10:14:36:304 SGT 00000073 SystemErr R at com.ibm.websphere.personalization.rules.PznXMLActionInterpreter.doQuery(PznXMLActionInterpreter.java:321)
Is the personalization query took longer than 60 seconds to execute is a query to load cache.
With that said, the rest of the stack is missing. Not sure what version of portal this is or if the cache is simply exhausted and it cant load, etc.
Version info and the rest of the stack before and after would help.
Also, what is happening in systemout.log during this time frame.
Fyi, our portal environment is a clustering of two portal servers with a web server sit on top of them for load balancing purpose, and both portal servers are using the one same database. We found out that content which is created from either one portal node, the changes sometimes is not reflected in the another portal node even though they are both using the same database. This behavior made us to believe that the content is actually pulled from the local portal cache.
We would like to know whether the content is being pulled out from local cache?
Is the personalization and the cache timed out problems caused by this operation of trying to get content in the cache where actually the content is not there because it is not synchronized?
Basically the cache timeout is not a excpetion and is really a warning. The real problem here comes from another timeout for thread id identified as 0000010f
10/28/09 11:02:28:983 SGT 0000010f TimeoutManage I WTRN0006W: Transaction 00000124991658AA00000001000A6C25B72E038B21439798C422ECEC7A3D1F807D09FA7700000124991658AA00000001000A6C25B72E038B21439798C422ECEC7A3D1F807D09FA7700000001 has timed out after 120 seconds. 10/28/09 11:02:30:592 SGT 00000448 ParameterFilt I Parameter prefix: cache.
This thread is probbaly tracked higher in the logs and should tell you what the timeout is from but I am assuming its a query to the backend database.
Also, the FFDC log I would think will show the trans timeout as well for that thread.
In answer to your other questions..The synchronization of cache is part of the dynamic replication service and is unrelated most likely to this problem. DRS is required to be configured in a cluster and I am sure thats done. Its replicates across the servers the portlet requests
In most cases these transaction timeouts are a result of the inactivity timeout being set too low. However, its possible you may have some hung threads as well. Have your looked through the systemout.log and searched for the word hung. The logs you have provided appear to be just snippets and usuallt you can also search for the thread id and follow it through the logs. If its not listed in earlier systemout.timestamp.logs and not in the ffdc logs, then in may be prudent to enable tracing, restart the server and monitor for the transaction timeout.
Please review this link for WTRN0006W: Transaction
http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21247192
