How to work with memory leak of a third-party DLL (without source code) accessed by the Tomcat application?

We have a project in which you can access a third-party DLL through JacoZoom in a Tomcat application. The DLL seems to be leaking memory (confirmed by the vendor), but the vendor does not intend to fix it. A memory leak causes Tomcat to restart at regular intervals, which, of course, is a big inconvenience for users.

What would be the best way to get around this? One of the options we are considering consists of two instances of the Tomcat server and regularly restarting the other and redirecting the user to the other.

Edit: decide by creating another DLL that kills and recreates the provider DLL if necessary. Basically, these three kernel32 calls were used to execute 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

Fortunately, the JacoZoom JAR file does not seem to mind that the DLL is being killed and recreated.

+2
source share
2 answers

I assume that such obvious things as "do not use this DLL" are not included in the table.

Can you create a wrapper, service or layer around a crappy DLL that you can manage and restart yourself, and use Tomcat / Jacozoom / any call this instead? In a sense, moving a memory leak to another application outside the container?

+5

, - .

COM-, . , , , .

, LeakDiag, , , , .

[Edit: exists- > exit - , .]

+2

Source: https://habr.com/ru/post/1721786/


All Articles