You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of 4.3.0 of this plugin the Sequel connection the database is opened and closed for each scheduled run. While fixed some issues it also appears introduced a memory leak.
Sequel connect method clearly documents:
# If a block is not given, a reference to this database will be held in
# <tt>Sequel::DATABASES</tt> until it is removed manually. This is by
# design, and used by <tt>Sequel::Model</tt> to pick the default
# database. It is recommended to pass a block if you do not want the
# resulting Database object to remain in memory until the process
# terminates, or use the <tt>keep_reference: false</tt> Database option.
The connection code in this plugin does not pass a block, nor set the keep_reference flag. Through inspection of the heap it found that the database object had a reference, not allowing it be reclaimed on each connect/disconnect.
The fix for this is simple, we need to pass the keep_reference flag as false on connection. Local testing with a pipeline with multiple jdbc inputs on a 1 second interval with a non-trival amount of selected items in the sql, given enough time, will show a relatively slow memory leak when profiling.
Specifically, a hprof heap dump when examined via visualvm and the following OQL query [1] will show excessively high counts of the configuration map , for example.
As of
4.3.0
of this plugin the Sequel connection the database is opened and closed for each scheduled run. While fixed some issues it also appears introduced a memory leak.Sequel connect method clearly documents:
The connection code in this plugin does not pass a block, nor set the
keep_reference
flag. Through inspection of the heap it found that the database object had a reference, not allowing it be reclaimed on each connect/disconnect.The fix for this is simple, we need to pass the
keep_reference
flag as false on connection. Local testing with a pipeline with multiple jdbc inputs on a 1 second interval with a non-trival amount of selected items in the sql, given enough time, will show a relatively slow memory leak when profiling.Specifically, a hprof heap dump when examined via visualvm and the following OQL query [1] will show excessively high counts of the configuration map , for example.
Profiling before and after this flag being set:
Before (the dip is me forcing GC):
After:
PR coming soon.
[1]
The text was updated successfully, but these errors were encountered: