[QFJ-637] QuickFixJ appears to modify headers of a message after delivery; iteration over the Header's fields on another thread produces a ConcurrentModificationException Created: 29/Sep/11 Updated: 15/Nov/11 Resolved: 15/Nov/11 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | Engine, Message Generation |
| Affects Version/s: | 1.5.0, 1.5.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Default |
| Reporter: | Michael Guyver | Assignee: | Unassigned |
| Resolution: | Not a bug | Votes: | 0 |
| Labels: | Concurrency, ConcurrentModificationException, QuickfixJ | ||
| Environment: |
RHEL kernel 2.6.18; Sun/Oracle Java 1.6.20; QuickFixJ 1.5.1 |
||
| Description |
|
We have created a client to the QuickFixJ engine which implements the Application interface; in order to manage our threading we have put a thread barrier between our client Application and QuickFixJ, where its invocations of the Application API are converted into Runnable commands which are executed on the client thread. Other parts of the system interact with the client across the thread barrier in the same way and it enables the client to run in a single-threaded manner. We log the messages we get from QuickFixJ and fairly frequently see a ConcurrentModificationException being raised when we iterate over the fields in a message's header: Iterator<Field> iter = message.getHeader().iterator(); I would have thought that a message and its header should be immutable after it has been delivered to the client Application, but it seems it is being changed on a different thread. Is this expected behaviour? Does QuickFixJ implement some sort of Message pooling? Thanks Michael |
| Comments |
| Comment by Michael Guyver [ 05/Oct/11 ] |
|
It seems that this was being caused by the presentation of messages by QuickFixJ to the toAdmin(Message,SessionID) and toApp(Message,SessionID) methods prior to sending: in these two cases the subsequent modification of the message header is expected due to the addition of a sending-time field. Since the thread boundary was implemented ascynchronously, it's likely that the CME was being produced by QuickFixJ adding the header while the message was being inspected. IOW, expected behaviour. |
| Comment by Michael Guyver [ 10/Oct/11 ] |
|
Handling the message on the QuickFixJ server thread in the .toAdmin method would appear not to have solved the problem. We have just seen this exception while attempting to .clone() the message in order to provide an immutable message to pass to the client application: Could someone suggest how QuickFixJ can realistically expect to modifiy the fields of a message while it is being processed by application code? |
| Comment by Michael Guyver [ 10/Oct/11 ] |
|
Please ignore the above - the issue was caused elsewhere and not by QuickFixJ. Apologies. |