There's considerable idle memory churn due to the construction of Calendar objects for reset calculations

[philipwhiuk]

trafficstars

Describe the bug An idle QuickFIXJ application produces a stream of garbage to be collected in the form of throwaway (Gregorian)Calendar objects

To Reproduce

• Create a QFJ application that has a Session attached
• Observe the memory behaviour and see what objects are being allocated and garbage collected.

Expected behaviour

• Minimal (ideally 0) use of additional memory without traffic being passed

System information:

• OS independent
• Java version 8
• QFJ Version - 2.2.0-SNAPSHOT

Additional context The source of this is the DefaultSessionSchedule class which creates (and invokes creation of) Calendar objects every time it's called.

For example, the MessageStore implementations all retain a Calendar object for the creationTime. However the API exposes a getCreationTime() method - and so the store constructs a DateTime from the calendar. But DefaultSessionSchedule uses a Calendar, so it then reconstructs a Calendar object from that date time to then do the comparison.

This all happens every time isSessionTime is called - which (at least) is every time Session.next() is called - which is up to once a second.

[chrjohn]

Thanks for opening this issue (and the related PR). Were there other objects (in significant numbers) created during idle times?

[philipwhiuk]

I also found stuff in our internal app code to fix. Once I've landed both this change and that change, I'll re-test and have a look. Certainly the two collectively were the worst offenders based on the sampling data.

Most likely however this is it for idle usage as it's basically the sum of what happens. When FIX traffic of some form is actually being passed there might be other tweaks.