BP/External SQL Calls are creating IRIS.WorkQueue but is not purging the global
I have been trying to track down an issue we are seeing in our TEST environment with Memory usage.
We have Several BP's for years now that take a HL7 message, parse it apart, and make calls to a Custom EnsLib.SQL.OutboundAdapter to have it execute Insert/Select/Update/Delete stored procedures against a MS SQL Database via JDBC connection. We are using Microsoft's JDBC 12.2 driver to do this.
What we are seeing is that IRIS.WorkQueue globals are being defined for these calls but then the IRIS.WorkQueue is not being cleaned up and taking up large amounts of Memory.
I have tried ensuring the context variables are set to "" when we are done with them in the BP, and that the parameter array in the Custom BO is killed once the stored procedure is executed and we have a result.
Why would this not clean up on its own once the HL7 message has been processed (completed) through the BP? Any way to tell why IRIS.Workqueue globals are being created?
You mention IRIS.WorkQueue globals consuming/using memory, but globals don't consume memory, they reside on disk.
I never seen any IRIS.WorkQueue globals, can you provide some detail?
What component is creating/using these globals?
There are some details within some of the globals to show us what is causing them to be created, but in my BP I don't get why they are being created.
Those that start with $lb(" actually point to the PID within the Application that is being used.
The one BPL in question takes the HL7 ADT message and parses it out into separate Insert/Update etc... stored procedures classes to be called against the BO.
Is your issue with memory (RAM) or disk usage?
Memory usage. We are seeing a decrease in the amount of available memory under at the OS Level. WRC has mentioned that the gmheap need to be increased in the application, however that is only increasing the amount of memory the application can use, it does not answer the issue of what is using all the memory.
The global IRIS.WorkQueue is located (mapped to) in the IRISLOCALDATA DB, which stores internal IRIS temporary data, including queue manager data.
This DB is being cleaned/purged at IRIS startup, but you may compact and truncate this DB while IRIS is running (either manually or programically)