Visual COBOL Compiling using containers Java memory climbing

Using vc_build_tools_dockerfiles_10.0_windows_pu04 we build and license the docker container.

When the container is run in 'process isolation' where  can see the java process from the license daemon running using task manager on the host.
These containers use a mounted volume.

We run multiple  Visual COBOPL compile containers.

The host machine is Windows Server 2022 datacenter.

Today ALL our COBOL  containers are failing and it seems to be due to the java process. The contains start and perhaps you start to compile a few times, then it sems the java process from the autopass daemon consumes such high CPU that the containers fail.

Remember this is process isolation. We  can't run hyper-v because the host doesn't support nested hyper-v.

If we quickly kill the java process we can exec into the container to do some exploratory work, but the question is what are we looking for?

We  even stopped all containers, removed all the images and rebuilt them all, but we get the same behaviour. No updates have been applied to the host server, we see no reason for a change in behaviour.

Running MFLicenseAdmin.exe list  - shows a valid license is installed, it does  allow compile until the memory is exhausted.

Ideas?

Neil

Hello Neil Hayes,

You might try enabling AutoPass logging within your container, to gather more information for investigation. The general instructions for enabling this logging are described in the following Knowledge Article (you might need to log in to view the article):

Enabling logs for troubleshooting AutoPass licensing issues

Based on the complexity of the issue, I'd recommend creating a Support Case for this problem, and attaching any AutoPass logs created with the above to the Support Case.

The logging didn't really help us as we didn't know what we where looking for. Using procmon we could see it was constantly looking for Usage.txt, which even when found didn't write to it.

Content of log - basically 84,000 lines of it before we had to kill the java process.

In the interim we edited : C:\\Program Files (x86)\\Micro Focus\\Licensing\\AutoPass\\clientdetails\\client_properties\\autopassj_client1.ini file and set autopassj.enable.usage.scheduler to false and did a brief test, this seemed to resolve the issue for now, rebuilt the containers and see how far we get.

Cause at this stage is still unknown as so machine updates had been applied.

Neil




[DEBUG] 2025-04-30 08:01:36.992 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : getUsageStoreDirectory()] :: usage directory is not configured or not a directory, hence by default set to autopass data directory C:\\ProgramData\\Micro Focus\\
[DEBUG] 2025-04-30 08:01:36.992 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : formUsageFileName()] :: formed usage file name : C:\\ProgramData\\Micro Focus\\\\Usage\\Usage.txt
[DEBUG] 2025-04-30 08:01:37.006 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : getUsageStoreDirectory()] :: usage directory is not configured or not a directory, hence by default set to autopass data directory C:\\ProgramData\\Micro Focus\\
[DEBUG] 2025-04-30 08:01:37.006 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : formUsageFileName()] :: formed usage file name : C:\\ProgramData\\Micro Focus\\\\Usage\\Usage.txt

The logging didn't really help us as we didn't know what we where looking for. Using procmon we could see it was constantly looking for Usage.txt, which even when found didn't write to it.

Content of log - basically 84,000 lines of it before we had to kill the java process.

In the interim we edited : C:\\Program Files (x86)\\Micro Focus\\Licensing\\AutoPass\\clientdetails\\client_properties\\autopassj_client1.ini file and set autopassj.enable.usage.scheduler to false and did a brief test, this seemed to resolve the issue for now, rebuilt the containers and see how far we get.

Cause at this stage is still unknown as so machine updates had been applied.

Neil




[DEBUG] 2025-04-30 08:01:36.992 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : getUsageStoreDirectory()] :: usage directory is not configured or not a directory, hence by default set to autopass data directory C:\\ProgramData\\Micro Focus\\
[DEBUG] 2025-04-30 08:01:36.992 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : formUsageFileName()] :: formed usage file name : C:\\ProgramData\\Micro Focus\\\\Usage\\Usage.txt
[DEBUG] 2025-04-30 08:01:37.006 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : getUsageStoreDirectory()] :: usage directory is not configured or not a directory, hence by default set to autopass data directory C:\\ProgramData\\Micro Focus\\
[DEBUG] 2025-04-30 08:01:37.006 [pool-7-thread-1] LocalUsageStore - [com.hp.autopassj.core.usage.providers.LocalUsageStore : formUsageFileName()] :: formed usage file name : C:\\ProgramData\\Micro Focus\\\\Usage\\Usage.txt