Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flyway 6.1.0 introduces memory leak #2743

Closed
JamesGuthrie opened this issue Mar 26, 2020 · 1 comment
Closed

Flyway 6.1.0 introduces memory leak #2743

JamesGuthrie opened this issue Mar 26, 2020 · 1 comment

Comments

@JamesGuthrie
Copy link

JamesGuthrie commented Mar 26, 2020

Which version and edition of Flyway are you using?

versions 6.1.0-6.3.2, community edition

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

Java API

Which database are you using (type & version)?

Postgresql 11

Which operating system are you using?

Linux

What did you do?

We are running flyway in a Wildfly application server, and noticed that our application was being killed due to running out of heap. An initial analysis showed that Flyway was the cause of a memory leak, in particular the ResourceNameCache class seems to be ballooning in size.

Our application has a periodic job which calls the .info() method on a Flyway instance. It appears that this is the underlying reason for the memory leak.

We have performed an in-depth analysis and found a probable root cause.

The commit which causes this problem is b1e827f. It appears to have introduced a logic error when introducing the ResourceNameCache.
Our understanding is that the purpose of the ResourceNameCache is to cache intermediate results of the classpath scanning in the scope of the Flyway object, and reuse those intermediate results for future classpath scans. As such, on consecutive instantiations of the ClassPathScanner, the ResourceNameCache is passed in from outside.

Unfortunately the above change broke the functionality of the locationScannerCache in the ClassPathScanner class, this because the locationScannerCache is local to the ClassPathScanner.

Consider the first and a subsequent instantiation of the ClassPathScanner:

The result is that the ResourceNameCache fills up with numerous ClassPathLocationScanner instances, until the JVM runs out of heap.

A possible solution would be to hoist the locationScannerCache up to the same scope as the ResourceNameCache.

@juliahayward
Copy link
Member

juliahayward commented Apr 1, 2020

Will be fixed in the 6.3.3 release, expected early next week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants