[QFJ-386] Out of memory exception on massive message intake with slow application code Created: 19/Dec/08 Updated: 15/Nov/12 Resolved: 05/Apr/10 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | Engine |
| Affects Version/s: | 1.3.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Default |
| Reporter: | Stelian Dumitrascu | Assignee: | Unassigned |
| Resolution: | Not a bug | Votes: | 0 |
| Labels: | None | ||
| Environment: |
All platforms |
||
| Description |
|
When connected late in the day to the counterparty's fix engine, QuickFIX/J has trouble dealing with the large message backlog. An analysis of the garbage collector log reveals a large amount of objects in the tenured generation that stay alive and therefore cannot be collected. This is owing to the fact that the linked blocking queue in the following sources: SingleThreadedEventHandlingStrategy.java has the default capacity of Integer.MAX_VALUE. The message backlog is quickly loaded onto the queue and stays there until the client software is able to process it. Proposed fix: Define the message queue in the above sources with a reasonable capacity, ideally configurable via session settings. |
| Comments |
| Comment by Steve Bate [ 05/Apr/10 ] |
|
A fixed queue length would be a problem. Would we block the entire message processing chain all the way back to the sender? Or write messages to an persistent store or ???. A better solution is to either speed up the client, increase the JVM memory or read messages into a JMS queue for later processing (as examples). QFJ is not designed specifically to handle an excessively slow consumer. |