Vinnie, at which point in the catalog full job cycle does this happen? In other words:
- does the metadata get to be copied to the /E/win_repo_temp/some_temp_folder location?
- does metadata get decrypted in that folder to hf7b-decrypted.xml and pd5-decrypted.xml?
- does blpatchcheck2.exe run to generate the xml file in the next step?
- does the error happen once the patch information starts to be populating to the catalog?
setting helper agent to debug and reviewing full agent rscd log and appserver logs would help determining at which point the issue happens; from there it may be easier to troubleshoot.
So this happens waay early in the update catalog process. As soon as the job is started on one of the job servers we have (we have two on the same VM), looking in the jobserver log it errors out immediately right below the log entry "
Catalog mode is set to Offline mode and Depot oject processor batch size is set to 1000.
win_repo_temp doesnt even get populated with any file.
The Linux Patch Catalog works, though (also offline). Similar setup as the windows as far as location of payload and temp location (/e/linux_repo and /e/linux_repo/temp).
Nothing in the FileServer/appserver (same server as location of the patch catalogs) RSCD.log file.
How can I get the helper agent configured for debug?
if nothing even get created on the helper server, and no errors in the rscd.log, then it's probably not an issue, and setting helper rscd to debug not necessary, but in case you still want to do that, it's the c:\windows\rsc\log4crc.txt file. set "info1" to debug" for the line with path to rscd.log, and restart the agent.
as for the catalog job, if it fails instantly, then set the catalog job to debug and review new appserver log... paste here if that's an option, if cannot figure out ... to set catalog to debug, Open the Job, go to Properties tab, and there should be True/False option to set this catalog to debug.
also, maybe try creating a new catalog and retest..
Ok - interesting. Attempted to create a NEW patch catalog for windows. Used the same inputs as identified on my first post (first catalog).
When I attempted to click on the + sign to add a filter, a pop up appears:
com.bmc.sa.patchfeed.FeedException: Error occurred while UnMarshalling the product_categories.xml
Thoughts? The reason why we didnt encounter this on the previous catalog is probably because it was already created ages ago and the filter is already there.
I think that means the data collected from product_categories.xml is not consistent in some way with how the data is used in the next step at a code level.. That xml is bundled inside a windows patching jar file (don't remember the name). I remember in the past we were offering a hotfix in the form of a jar file to fix some catalog issues, and now I wonder if this has something to do with that.... If your production and test are on the same versions, then do file comparison in the NSH/stdlib (or br/stdlib - I don't remember).. see if there are any mismatching files (jar files to be more specific). If yes, then maybe need to replace... I'd file a ticket with Support as well, perhaps this issue is already known and resolved in the past two weeks ; )
Yeah it's br/stdlib,
1) Open the br/stdlib subdirectory of app server's installation directory;
2) Check that you have only one each of the following files in this directory (no any backup files):
3) Should you find older versions, or versions with changed names (that is, backups of older versions), do the following:
A: Stop the app service;
B: Move the older files out of the stdlib directory -- DO NOT SIMPLY RENAME THEM, as they are XML files and are still getting loaded into the app service at startup;
C: Restart the app service and run a fresh catalog update.
If it's still an issue then check the md5sum of above said jar files from any of the working environment and compare with non working environment. If you find any discrepancy then you probably need to replace the correct files at br/stdlib .
That was exactly the problem. We previously applied patched jar files to our BSA 8.1 SP2 instance, and then recently upgraded to 8.2 SP1.