[QFJ-680] UtcTimestampConverter.convert() threading issue Created: 21/May/12 Updated: 24/Aug/12 Resolved: 15/Aug/12 |
|
Status: | Resolved |
Project: | QuickFIX/J |
Component/s: | Engine |
Affects Version/s: | 1.5.2 |
Fix Version/s: | 1.5.3 |
Type: | Bug | Priority: | Default |
Reporter: | N Byrne | Assignee: | Christoph John |
Resolution: | Fixed | Votes: | 1 |
Labels: | None | ||
Environment: |
n/a |
Attachments: | QFJ-680.patch |
Description |
The root cause is actually very simple. 1) Multiple threads call convert(String) for a new day [new = wasn't already in dateCache] Example stack trace Caused by: java.lang.ArrayIndexOutOfBoundsException: 101 There are many easy ways to fix this. I would even suggest just storing the millis in the dateCache |
Comments |
Comment by N Byrne [ 25/Jun/12 ] |
Suggested solution |
Comment by AE [ 20/Aug/12 ] |
Hi, while we haven't seen the exception above, we have twice seen 'SendingTime accuracy' issues between 2 quickfixj engines at exactly midnight, even though the clock on both machines are in sync, which I imagine is related to the above thread safety issues. We have seen this in both 1.3 and 1.5. When will the patch above make it into the next version of qfj? Thanks |
Comment by Christoph John [ 20/Aug/12 ] |
Currently it is not yet defined when the next patched version will be released. Hopefully soon. |
Comment by AE [ 20/Aug/12 ] |
Thanks, do you know if the 'SendingTime accuracy' I see can be related to the thread safety issue above? Thanks. |
Comment by Christoph John [ 21/Aug/12 ] |
This looks related. When doing the SendingTime check, the field is retrieved from the message and converted using the UtcTimestampConverter.convert() method. |