WContentVerify throwing DBInterrupt errors

[avillanueva]

Its Deja Vu all over again. I last ran into similar issues back in 2023, coincidentally, about the time of my last upgrade:

https://community.ptc.com/t5/Windchill/Running-WContentVerify-and-getting-Socket-read-interrupted/m-p/895322#M73997

I think I resolved it by doing smaller batches. folder by folder. Some of my folders can get very large.  I saw in one case, that I was getting false positives where it said there were missing files but they were not.

Here is what I am running:

bin/windchill  wt.fv.tools.WContentVerify -user=wcadmin -vaults=main_vault -email=me@me.org -onlyExistence

Previously with my 12 system this ran without complaint. Is this an issue on my DB side or is this a tuning issue on the Windchill side? Or do I just have to break this up into chunks?

2025-08-12 20:29:13,020 ERROR [RMI TCP Connection(35)-10.128.20.219] wt.method.MethodContextMonitor.contexts.rmi wcadmin - 2025-08-12 20:27:35.956 -0400, 4eih3rq3;me98e4lb;395246;kxone5;9, -, -, -, wcadmin, 10.128.20.219, wt.fv.tools.WCV_BasicMasterFolderCheck, _server_getPerFolderStats, , 0, 15, 53.446267589, 10, 0.007917912, 19.662938153, 97.063269693 (wt.pds.pdsResource/29) wt.pds.DBOperationInterruptedException:
Database query operation interrupted
	at wt.pds.SQLDatabasePds.query(SQLDatabasePds.java:875)
	at wt.pom.PersistentObjectManager.query(PersistentObjectManager.java:1077)
	at wt.pom.PersistentObjectManager.query(PersistentObjectManager.java:986)
	at wt.fc.StandardPersistenceManager._query(StandardPersistenceManager.java:2047)
	at wt.fc.StandardPersistenceManager._find(StandardPersistenceManager.java:2083)
	at wt.fc.StandardPersistenceManager.find(StandardPersistenceManager.java:661)
	at jdk.internal.reflect.GeneratedMethodAccessor63.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at wt.services.ServiceFactory$ServerInvocationHandler.invoke(ServiceFactory.java:399)
	at jdk.proxy2/jdk.proxy2.$Proxy39.find(Unknown Source)
	at wt.fc.collections.RefreshHelper$Refresh.doSecondPass(RefreshHelper.java:944)
	at wt.fc.collections.RefreshHelper$Refresh.refresh(RefreshHelper.java:683)
	at wt.fc.collections.RefreshHelper.refresh(RefreshHelper.java:144)
	at wt.fc.collections.StandardCollectionsManager.refresh(StandardCollectionsManager.java:81)
	at jdk.internal.reflect.GeneratedMethodAccessor169.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at wt.services.ServiceFactory$ServerInvocationHandler.invoke(ServiceFactory.java:399)
	at jdk.proxy2/jdk.proxy2.$Proxy74.refresh(Unknown Source)
	at wt.fv.tools.WCV_BasicMasterFolderCheck._server_processResults(WCV_BasicMasterFolderCheck.java:610)
	at wt.fv.tools.WCV_BasicMasterFolderCheck._server_getPerFolderStatsForFvItemsOnMasterServer(WCV_BasicMasterFolderCheck.java:546)
	at wt.fv.tools.WCV_BasicMasterFolderCheck._server_getPerFolderStats(WCV_BasicMasterFolderCheck.java:500)

[avillanueva]

I am noticing this article which I saw before pointing to heap values:

https://www.ptc.com/en/support/article/CS382905?source=search

Yep, this is likely issue:

[MethodContextMonitor GC Baiter] wt.method.MethodContextMonitor.lowMemory.interrupt  - Still less than MinAvailableHeapThreshold [288358400] bytes available; attempting to interrupt method context '4eih3rq3;me98e4lb;395246;kxone5;8'; based on: result set size
2025-08-12 20:28:42,120 WARN  [MethodContextMonitor GC Baiter] wt.method.server  - Interrupting thread RMI TCP Connection(34)-XXXXXXXXXXXX
2025-08-12 20:28:42,121 WARN  [MethodContextMonitor GC Baiter] wt.pds.queryCancel  - QueryContext.cancel(): interrupting

Strange since I used the same values as my last system

wt.manager.maxHeap=3851
wt.manager.minHeap=3851
wt.method.maxHeap=5500
wt.method.minHeap=5000

[avillanueva]

Ok, increasing the Heap values solved this problem but it might have slowed down the system a bit. This article was helpful in pointing to the health stats:

https://www.ptc.com/en/support/article/cs26654 and this query:

select count(*),JVM_ID FROM MSHealthStats where HeapMemoryUsage > (0.9 * wt.method.maxHeap) and le_timestamp > sysdate - 30 group by JVM_ID ;

It showed the number of times I was hitting the limit.  Raising the ceiling allowed WContentVerify to execute without error to completion. I was watching the Server Status page and it was screaming high GC (about 20-25%) during execution but did not throw interrupt errors. I was able to verify content no issues. 

But now, I have degraded performance. I tested some add to workspace operations on some assemblies and previously some where completing in 12 seconds and now 37 and 20 seconds. I added 70% more memory to each MS and put a cap on OpenDJ which had no bound previously. I think the theory is that with a large amount of memory, GC would be less frequent but each cycle has to clean out more memory so it takes longer. Sound right? So is goal to find happy medium? Or do we plan those large tasks by scalling up Heap and then drop down when its complete?