Home/ Questions/Q 427803
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T19:36:45+00:00

We have a project where a 3rd party DLL is accessed through JacoZoom in

  • 0

We have a project where a 3rd party DLL is accessed through JacoZoom in a Tomcat application. Apparently the DLL leaks memory (confirmed by the vendor), but the vendor has no intention to fix this. The memory leak forces Tomcat to be restarted at regular intervals, which is naturally a great inconvenience for the users.

What would be the best way to work around this problem? One option we consider is having two instances of the Tomcat server and regularly restarting the other one, and redirecting the user to the other one.

Edit: solved by creating another DLL which kills and recreates the vendor DLL when needed. Basically these three kernel32 calls were used to accomplish the functionality:


Private Declare Function GetModuleHandle Lib "kernel32.dll" Alias "GetModuleHandleW" (ByVal DllName As Long) As Long
Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long

Luckily the JacoZoom JAR file doesn’t seem to mind that the DLL is killed and recreated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’m assuming that obvious things like “don’t use that DLL” aren’t on the table.

    Can you create a wrapper, service, or layer around the crappy DLL that can be managed and restarted independently, and have Tomcat / Jacozoom / whatever call that service instead? In a sense, moving the memory leak to some other application outside the container?

    • 0