After the upgrade, we are experiencing Tomcat service outages every weekend. We have observed the following errors. Could you please review and suggest how we can prevent this issue?
14-Mar-2026 01:17:56.035 WARNING [Thread-281] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [identityiq] registered the JDBC driver [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
14-Mar-2026 01:17:56.035 WARNING [Thread-281] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [identityiq] appears to have started a thread named [Log4j2-TF-4-Scheduled-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.base@17.0.17/jdk.internal.misc.Unsafe.park(Native Method)
java.base@17.0.17/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:252)
java.base@17.0.17/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1679)
java.base@17.0.17/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
java.base@17.0.17/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
java.base@17.0.17/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1062)
java.base@17.0.17/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1122)
java.base@17.0.17/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
java.base@17.0.17/java.lang.Thread.run(Thread.java:840)
14-Mar-2026 01:17:56.067 SEVERE [Thread-281] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [identityiq] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@334fa48e]) and a value of type [sailpoint.api.Meter.MeterSet] (value [sailpoint.api.Meter$MeterSet@40b0f2e6]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
The errors you are seeing in your Tomcat logs are shutdown-time warnings rather than the direct cause of your weekly outages. Tomcat is reporting that during its stop/restart process, some resources (JDBC drivers, threads, and ThreadLocal variables) were not cleaned up properly, which could lead to a memory leak if you were redeploying the app multiple times without restarting the server.
However, since your services are going down every weekend, it is more likely that your Java Heap Space is being exhausted over time by a background process.
THIS USALLY HAPPENS WHEN
IdentityIQ often runs heavy background tasks (like Identity Refresh or Account Aggregation) over the weekend. If these tasks process more data than the server’s memory can handle, the JVM will crash with an OutOfMemoryError.
I recommend you to take these below Actions
Increase Tomcat Memory: After an upgrade, IIQ may require more resources. Ensure your setenv.sh (Linux) or setenv.bat (Windows) has sufficient heap space. A common recommendation for larger environments is at least 8GB to 16GB.
Example: CATALINA_OPTS=“-Xms8g -Xmx8g”
Check Weekend Tasks: Review the Setup > Tasks section in IIQ. Look for any tasks scheduled on Friday or Saturday nights that might be hanging or failing.
Clean Up Leftover Processes: Sometimes a “restart” doesn’t fully kill the old Java process. Before starting Tomcat, manually check for and kill any lingering Java processes.
Example (Linux): ps -ef | grep tomcat followed by kill -9
Patch Level: Ensure you are on the latest patch for your IIQ version, as SailPoint frequently releases fixes for specific memory leaks in the MeterSet or API layers.
Could you please share the versions of the software currently in use, including SailPoint IIQ, Database, Tomcat, and Java? Also, let us know the SailPoint IIQ version you upgraded from and the version you upgraded to.
Since SailPoint provides environment recommendations, please verify that all upgraded components are using compatible and supported versions. if you are interested share your environment details as well( mask confidential values). I have performed similar upgrades multiple times and am confident I can help.
at sailpoint.web.SailPointContextRequestFilter.doFilter(SailPointContextRequestFilter.java:85) ~[identityiq.jar:8.4.p2]
Caused by: sailpoint.tools.GeneralException: User is not logged in.
RROR ServerThread sailpoint.server.Servicer:1165 - Unable to execute service: SIEMService
sailpoint.tools.GeneralException: Unable to connect to: jdbc:sqlserver://Test:1433;databaseName=identityiqPlugin;encrypt=false;verifyServerCertificate=false;
at sailpoint.plugin.PluginBaseHelper.getConnection(PluginBaseHelper.java:52) ~[identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
at sailpoint.server.BasePluginService.getConnection(BasePluginService.java:35) ~[identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
at com.sailpoint.siem.db.SIEMAlertService.getNewAlerts(SIEMAlertService.java:65) ~[?:?]
at com.sailpoint.siem.server.SIEMService.createAlerts(SIEMService.java:148) ~[?:?]
at com.sailpoint.siem.server.SIEMService.execute(SIEMService.java:131) ~[?:?]
at sailpoint.server.Servicer.execute(Servicer.java:1162) [identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
at sailpoint.server.Servicer.processServices(Servicer.java:1113) [identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
at sailpoint.server.Servicer.run(Servicer.java:831) [identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
Caused by: java.sql.SQLException: Unable to connect to: jdbc:sqlserver://Test:1433;databaseName=identityiqPlugin;encrypt=false;verifyServerCertificate=false;
at sailpoint.persistence.SailPointDataSource.getConnection(SailPointDataSource.java:50) ~[identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
at sailpoint.plugin.PluginBaseHelper.getConnection(PluginBaseHelper.java:50) ~[identityiq.jar:8.4p2 Build a559eb467b2-20241211-210440]
... 7 more
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: The TCP/IP connection to the host Test, port 1433 has failed. Error: “connect timed out. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall.”.
As per this error, it suggestes that wrong information has been added for identityiqPlugin Database in iiq.properties. SailPoint is not able to find this Database and error is showing up.
Hi @sureshbomm This is a good observation. It is looking like a database based side issue. It might be a firewall deployment or some other activity on the DB causing the issue. Check with the database teams, since it is happening on the weekends. or the DB temp folder is full!.
On the IIQ side, make sure you use an updated SQL Server JAR.
@sureshbomm Could you please specify few more things, is it causing this issue while starting the tomcat? or IIQ is running and it is causing the outage?
You might also want to check few things:
if there are any outdated jars.
unwanted locks on the objects remains due to improper task cancellation.
plugins database is properly accessible
Some issue while assigning initial connection to DB. check the maximum connection allowed in DB
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(,, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
After checking both of your errors, it seems the issue is caused by the SIEM service repeatedly failing to connect to its database on port 1433, fixing the database connectivity or disabling the unused SIEM integration resolves the problem.
,
, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.