Clearing the Process Scheduler Cache – without a Reboot June 11, 2007Posted by Duncan in Administration, Application Engine, PeopleSoft, SQL.
I subscribe to a couple of PeopleSoft technical mailing lists / websites and I came across an interesting tip tonight that I thought I’d pass on.
The post was on IT Toolbox (peoplesoft.ittoolbox.com) and the poster was a guy called Neil Pak (at least that’s what the email said, I guess his real name could be anything).
The issue being discussed was one that’ll be familiar to all developers who’ve written a few App Engines in their time – needing to bounce the Process Scheduler to clear the cache, to get the Process Scheduler to use the latest changes. Sometimes it picks them up, sometimes it doesn’t, particularly if you’re changing an existing object – and for me this has happened mostly with SQL Objects.
The normal solution is to bounce the Process Scheduler and clear the cache, however this isn’t possible all the time. Perhaps there’s a long-running job that’s processing, or perhaps your friendly DBA/SysAdmin is busy getting a cuppa etc. Other times I’ve just cloned the SQL Object in question and appended a digit to the object name and used that version instead. This works also, but you do tend to end up with a stack of similarly named SQL Objects in your project.
Neil’s solution – and you’ll need access to the Process Scheduler server for this – is to delete some specific cache files. To quote Neil:
I did some testing and found that, at least for app engines that finished successfully, I could go in and delete the .dat and .key files (but not the cache.lok) and basically the cache was deleted … One could probably just delete all the .key and .dat files without much regard to which folder it was since any files still in use would not delete.
Note: I haven’t tested this myself yet.
The original post did say that this was tested with the AESRVs disabled. I had a quick test today and couldn’t delete any of the cache files under the AESRV directories. I guess the processes keep them locked, or perhaps it was just that we had lots running. I’ll update this post again if I find out more.