Database timeout or deadlock on IBM i.
We've just completed at setup of RTC on IBM i (everything including WAS is running on IBM i).
Everything seems to work fine, we can log in and then try to create the first project. Deployment of templates worked fine. Project is created and the initialization begins.
After some time (about 1 min) the operation aborts and we see the following in the ccm.log:
2015-12-17 16:15:58,515 [WebContainer : 35 @@ 16:14 <unauthenticated> <LQE/1.0@10.200.62.65> /ccm/process-trs2] ERROR com.ibm.team.process - CRJAZ1318E The server could not connect to the database. Try the operation again.
Could this be because the database (Library or *FILE) on the IBM i is running very slowly and then aborts?
The performance measurement reports 1300ms which is on the low side I must admit.
Could we maybe increase some timeout on the DB connection or on the IBM i file object itself?
Please, any comments are greatly appreciated!
/Morten.
|
One answer
Hi Morten,
I have not encountered this symptom before. We found a couple of articles that may lead to a solution: http://www-01.ibm.com/support/docview.wss?uid=swg21190797 http://www-01.ibm.com/support/docview.wss?uid=nas8N1016772 If changing the wait times on file JAZZCCMDB/PRCSSPRCSS does not help, then consider opening a PMR against IBM i DB2 or JAZZ foundation. Ensure all PTF's are applied and provide version information (RTC, i/OS, WAS, ...). Comments
Morten Madsen
commented Jan 18 '16, 5:27 a.m.
Hi Alfonso, thanks for your suggestions. I will try to see if I can get someone IBMi savvy to give this a try. I will report my findings here.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Did you check and see what job had a lock on the file
PRCSSPRCSS in JAZZCCMDB type *FILE?
Sorry, I don't have access to the host right now. But yes, we checked it, and it looked like the normal jobs spawned by RTC. When we shut down the RTC WAS profile, all jobs where closed. So it seems to me, it is not a deadlock, just a slow database that exceeds the timout threshold.