QuickFIX/J Jira
QuickFIX/J Jira
Displaying 978 issues at 30/May/17 03:31.
Project Key Summary Issue Type Status Priority Resolution Assignee Reporter Creator Created Last Viewed Updated Resolved Affects Version/s Fix Version/s Component/s Due Date Votes Watchers Images Work Ratio Linked Issues Environment Description Security Level Labels Epic Link Epic/Theme Flagged Rank Sprint
QuickFIX/J QFJ-926

Session reset happens after logon

Bug Open Major Unresolved Unassigned Nickolay Dul Nickolay Dul 23/May/17 08:54   23/May/17 09:44   1.6.0   Engine   0 2   scenario:

application is handling several FIX sessions (initiators)
app started in the *off* time – FIX sessions are successfully created and reset

{{11 May 23:40:10.450 INFO (Thread-3) Session FIX.4.4:SENDER_ONE->TARGET schedule is THU 04:05:00-UTC - THU 20:30:00-UTC
11 May 23:40:10.452 INFO (Thread-3) Session state is not current; resetting FIX.4.4:SENDER_ONE->TARGET
11 May 23:40:10.459 INFO (Thread-3) Created session: FIX.4.4:SENDER_ONE->TARGET

11 May 23:40:10.501 INFO (Thread-3) Session FIX.4.4:SENDER_TWO->TARGET schedule is THU 04:07:00-UTC - THU 20:30:00-UTC
11 May 23:40:10.502 INFO (Thread-3) Session state is not current; resetting FIX.4.4:SENDER_TWO->TARGET
11 May 23:40:10.509 INFO (Thread-3) Created session: FIX.4.4:SENDER_TWO->TARGET
}}

on the next day logons are initiated according to session’s schedules

but the first session reset is happened in the middle of message handling:
(which is result in re-logon and “MsgSeqNum too low” issue)

# SENDER_ONE
12 May 06:05:00.932 INFO (QFJ Timer) Initiated logon request
12 May 06:05:01.145 INFO (QFJ Message Processor) Received logon
12 May 06:05:01.149 INFO (QFJ Message Processor) Sent ResendRequest FROM: 1 TO: 2385
12 May 06:05:01.150 INFO (QFJ Message Processor) Logon has been established: FIX.4.4:SENDER_ONE->TARGET
12 May 06:05:01.156 INFO (QFJ Message Processor) Session state is not current; resetting FIX.4.4:SENDER_ONE->TARGET
12 May 06:05:01.168 INFO (QFJ Message Processor) Session has been logged out: FIX.4.4:SENDER_ONE->TARGET
12 May 06:05:16.928 INFO (QFJ Timer) Initiated logon request
12 May 06:05:17.160 INFO (QFJ Message Processor) Received logout request: MsgSeqNum too low, expecting 4 but received 1

on other hand second session starts normally (reset happens before logon):

# SENDER_TWO
12 May 06:07:00.929 INFO (QFJ Timer) Session state is not current; resetting FIX.4.4:SENDER_TWO->TARGET
12 May 06:07:00.930 INFO (QFJ Timer) Initiated logon request
12 May 06:07:01.103 INFO (QFJ Message Processor) Received logon
12 May 06:07:01.103 INFO (QFJ Message Processor) Sent ResendRequest FROM: 1 TO: 2612
12 May 06:07:01.103 INFO (QFJ Message Processor) Logon has been established: FIX.4.4:SENDER_TWO->TARGET

I guess the problem is how session reset is handled in Session::next() method:
look like sometimes the previous session time check is happenning less then 1 sec ago – it is skipped – and as a result session reset is accured already after logon

0|i00613:
QuickFIX/J QFJ-925

Unable to reset sequence number on end of the session

Other Closed Critical Not a bug Unassigned hemant hemant 12/May/17 10:41   12/May/17 11:00 12/May/17 11:00         0 2   Hello,

I am developing an adapter for FIX market.
As per our requirement, we want to maintain sequence number in case adapter gets restarts mid of the day. But we want to reset the sequence at a specific timing(market end of trading time).

We are using quick fix configurations:
StartTime: <some value>
EndTime: <some value>
ResetOnLogon: N

But sequence number does not get reset at the start of new session. Please suggest.

Thanks
Hemant
0|i0060v:
QuickFIX/J QFJ-924

unable to subscribe secuirty defintion Response for composite markets using Startegy Perefrence=1

Other Closed Default Not a bug Unassigned LakshmiBoppana LakshmiBoppana 26/Apr/17 03:37   26/Apr/17 08:55 26/Apr/17 08:55 1.6.3   Message Generation   0 2   Hi Team,
We are sending Security Definition request from our application with below values
SecurityRequestType=101
Strategy Preference=1
Markets=317,134,60,133

iam looking for composite spreads Security definition response i.e we are testing API 3.2 changes for composite vdissemination.
We are getting below response in our logs

ICE:WEBICE: 8=FIX.4.49=61935=UDS49=ICE34=70752=20170424-10:18:18.37856=3857=69322=247375320=OP008323=455=507819148=WMJ SQJ0017.M001722=8207=IFEU9048=WMJ 800 5078191167=MLEG541=20170501107=Freight Futures (USD) - TC5 - Q2 17326=17762=800996=mt9064=060=20161210-21:33:46.3459013=0.00019014=1.09083=4.09084=09061=32449030=39091=TC5 MEGulf-JP9092=19040=0.00019041=1.09100=USD9101=USD / mt9185=2.09022=39024=1.09205=19215=1555=3600=5038896609=FUT624=1623=19623=19624=19566=39567=1600=5052858609=FUT624=1623=19623=19624=19566=39567=1600=5070156609=FUT624=1623=19623=19624=19566=39567=110=077



But we are getting the below error in our logs
Error occurred while cracking the received message
quickfix.UnsupportedMessageType
at quickfix.fixt11.MessageCracker.onMessage(MessageCracker.java:29)

in response i coukld see that 35 has value'UDS' ,so can you please confirm whether i need to difine <message name="SecurityDefinition" msgtype="UDS" msgcat="app"> in my datadictionary? or <message name="SecurityDefinition" msgtype="d" msgcat="app"> should be fine where msgtype='d'?


QuickfixJ 0|i0060n:
QuickFIX/J QFJ-923

FileStore is leaking file handles

Bug Open Critical Unresolved Unassigned Constantin Florescu Constantin Florescu 20/Apr/17 11:01   24/Apr/17 09:22   1.6.2, 1.6.3   Engine   0 2   All The FileStore like all the other stores are not synchronized.
The access to this store, at times, can be done by 2 threads concurrently.

When a session is about to be estabilished, logon request is sent to the server, if the request is not answered by the server in within the timeout period the connection is closed and the reconnect timer starts.

The problem is that when the Timeout Timer [QFJ Timer] fires it also releases [QFJ Message Processor] thread which tries to process EndOfFille/Stream event, both threads will try to reset the MessageStore on next().

During the reset() the FileStore is (re)initialized which causes the following actions: close existing files, open the files, read stores.

When done in parallel, one thread may try to open or read while the other is closing the files resulting in:
1. Read corrupted data from message stores
2. Leak file handles


Some proof:
16:18:28.763 [QFJ Timer] INFO quickfix.FileStore - initialize() called from.
at quickfix.FileStore.initialize(FileStore.java:111) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.FileStore.reset(FileStore.java:465) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.SessionState.reset(SessionState.java:382) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.resetState(Session.java:2503) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.disconnect(Session.java:1968) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.next(Session.java:1808) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:278) [quickfixj-core-1.6.2.jar:1.6.2]

And from:
16:18:28.788 [QFJ Message Processor] INFO quickfix.FileStore - initialize() called from.
at quickfix.FileStore.initialize(FileStore.java:111) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.FileStore.reset(FileStore.java:465) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.SessionState.reset(SessionState.java:382) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.resetState(Session.java:2503) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.disconnect(Session.java:1968) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.next(Session.java:882) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.next(Session.java:1109) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:144) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:91) [quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:125) [quickfixj-core-1.6.2.jar:1.6.2]

Out of file handles:
ERROR [QFJ Timer] quickfix.SocketInitiator Error during timer processing
quickfix.RuntimeError: java.io.FileNotFoundException: [/..../Session].header (Too many open files)
at quickfix.SessionState.reset(SessionState.java:384) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.resetState(Session.java:2499) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.disconnect(Session.java:1967) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.Session.next(Session.java:1808) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:278) [quickfixj-core-1.6.2.jar:1.6.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_74]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_74]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_74]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_74]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_74]
Caused by: java.io.FileNotFoundException: [/.../Session].header (Too many open files)
at java.io.FileOutputStream.open0(Native Method) ~[?:1.8.0_74]
at java.io.FileOutputStream.open(FileOutputStream.java:270) ~[?:1.8.0_74]
at java.io.FileOutputStream.<init>(FileOutputStream.java:213) ~[?:1.8.0_74]
at java.io.FileOutputStream.<init>(FileOutputStream.java:133) ~[?:1.8.0_74]
at quickfix.FileStore.initializeMessageIndex(FileStore.java:198) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.FileStore.initializeCache(FileStore.java:121) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.FileStore.initialize(FileStore.java:116) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.FileStore.reset(FileStore.java:442) ~[quickfixj-core-1.6.2.jar:1.6.2]
at quickfix.SessionState.reset(SessionState.java:382) ~[quickfixj-core-1.6.2.jar:1.6.2]
... 11 more
Reconnect, logon, timeout 0|i0060f:
QuickFIX/J QFJ-921

Support receiving higher resolution timestamps

New Feature Resolved Major Fixed Christoph John Christoph John Christoph John 07/Apr/17 21:54   11/Apr/17 09:38 11/Apr/17 09:38   1.6.4 Engine   0 1   Also see related issue QFJ-873 which will support sending, receiving and processing higher resolution timestamps on the message objects.

QFJ-921 will merely deal with accepting messages with timestamps up to picosecond precision. Internally, QFJ will still use milliseconds.
0|i00607:
QuickFIX/J QFJ-920

LogOff FIX Message(35=5) is not send by initiator on stop

Bug Closed Blocker Duplicate Unassigned hemant hemant 04/Apr/17 15:53   04/Apr/17 19:35 04/Apr/17 19:35 1.6.3   Engine   0 2   Hello,

Whenever we stop the FIX initiator LogOff FIX message was not sent. It was working fine in previous versions as
In previous version(1.6.1)

public void stop(boolean forceDisconnect) {
logoutAllSessions(forceDisconnect); -> Logout session
stopSessionTimer(); ->Stop timer
....

In version 1.6.3.
public void stop(boolean forceDisconnect) {
+ stopInitiators(); -> which eventually invokes stopSessionTimer();
logoutAllSessions(forceDisconnect); -> As we stop the timer so Session.next() never get invoke and results that we did not send LogOut Fix Message(35=5)
QuickfixJ 0|i005zz:
QuickFIX/J QFJ-919

Upgrade to FIX 5.0.SP3 - EP206

New Feature Closed Major Duplicate Unassigned Anna Maria Cochetti Anna Maria Cochetti 03/Apr/17 13:12   04/Apr/17 07:19 03/Apr/17 13:55 1.6.3   Metadata/Specs   0 2   SP3 has been approved on November 30, 2015 to adjust timestamps to a granularity up to nanoseconds. This is a requirement for MIFID II reporting.
See "MiFiD II - Clock Synchronization Working Group
Global Technical Committee
TimeStamp Datatypes Enhancements"
Quickfix needs to upgrade before the end of 2017
0|i005zr:
QuickFIX/J QFJ-918

Initiator failover funtion

Other Open Default Unresolved Unassigned Cheng Guo Cheng Guo 03/Apr/17 11:10   03/Apr/17 11:29   1.6.3   Engine   0 2   Linux Hi,
I just learn the QuickFIXJ, and thinking if QuickFIXJ could support the below failover/ HA scenario, or if you could give me some suggestion for the custom dev?
We act as Initiator to connect to the external acceptor, as the Initiator, we want to deploy to two servers, one as the primary which is active, the other is the backup, and non-active.
Primary will be communicating with external acceptor, meanwhile, by HA module, the secondary sync with the primary at the seq number, msg, etc.. Once primary is down, secondary will take over the primary role, and connect to the external.
Checked the document, seems QuickFIX support the acceptor failover, but dont have the initiator case?
could you help let me know how address this? thanks.

by the way, i also developing to send the FIX msg to IBM MQ, could you suggest if QuickFIXJ has the persistence module/ api to store the un-delivery msg if MQ down, and then send out once MQ is up?

QuickfixJ 0|i005zj:
QuickFIX/J QFJ-917

Race condition between SocketAcceptorIoProcessor & QFJ Message Processor

Bug Resolved Default Fixed Paul Rowe Paul Rowe Paul Rowe 08/Mar/17 04:27   29/Mar/17 21:33 29/Mar/17 21:33 1.5.3 1.6.4 Build   0 2   Linux We experienced a race condition where *Application.onLogout()* method was not called.

On a Session, we issue a logout from another thread. The counterparty will then respond with a logout message and disconnect. When this happens, there are two threads in play, the "QFJ Message Processor" thread that processes the counterparty logout message, and another "SocketAcceptorIoProcessor" thread spawned by Mina when the socket disconnects. Both of these threads ultimately fall into the *Session.disconnect(String,boolean)* method. The sequence of events go like this in *Session.disconnect()*:

# "SocketAcceptorIoProcessor" sets the responder to null
# "QFJ Message Processor" sees that the responder is null and returns from Session.disconnect(). The body of the Session.disconnect() method is wrapped in a try..finally block, so when "QFJ Message Processor" exits this method via the return, it sets logonReceived and logonSent flags to false.
# "SocketAcceptorIoProcessor" reaches if statement that checks logonReceived and logonSent, these flags were false because "QFJ Message Processor" cleared them when it exited previously. As a result, *Application.onLogout()* is never executed.

I took a look at QFJ-803, QFJ-810 and QFJ-790 and they aren't quite the same issue as the one we experienced. I also pulled a latest copy of the QuickFix code from master, and it appears the current code could be potentially affected by this issue.

Can you please confirm if this is a current bug in the code and/or if it has been fixed by another jira that I did not see ?
logout, session 0|i005zb:
QuickFIX/J QFJ-916

Reconnection feature does not work under some circumstances

Bug Open Default Unresolved Unassigned Arsentii Nerushev Arsentii Nerushev 18/Feb/17 23:38   21/Feb/17 12:31   1.6.3   Engine, Networking   0 2   Java 1.8.0u66 x64, Windows 8.1, no network proxy Had an application running from morning but on the evening checkup I observed strange behavior of the reconnection feature. I believe there was some connectivity issue, the application missed a heartbeat so the session had been disconnected and logged out. I don't really understand what happened next, but it seems the connection itself (with the remote host) was restored but the messages weren't going anywhere as the session's state wasn't 'logged on' at the moment, and the Engine wasn't trying to log the session on again.
I tried to reproduce the issue by manually closing the connection slightly before the heartbeat check, but the Engine had actually reset the connection after I opened it again seeing the disconnection message.

I've got some logs from both cases (see below). reconnectionInterval = 30.
I've noticed that in the second ("OK") case there is a line
{noformat}
"d.q.m.i.IoSessionInitiator [QFJ Timer] - [...] - reset IoConnector"
{noformat}
whereas there's none such in the first case, but a couple of hours of digging the quickfix/j's sources haven't brought me anywhere. The line appears when the *reconnectionTask* (which runs at a schedule with 1 second interval) of *quickfix.mina.initiator.IoSessionInitiator* is at the '*resetIoConnector()*' method and the condition
{code:java}
ioSession != null && Boolean.TRUE.equals(ioSession.getAttribute("QFJ_RESET_IO_CONNECTOR"))
{code}
is true by the moment. So, either _ioSession_ is null or its "reset" attribute is not set to true. The '*disconnect*' method of *quickfix.Session* has a line *'responder.disconnect();*' which leads us to *quickfix.mina.IoSessionResponder*'s lines:

{code:java}
ioSession.closeOnFlush();
ioSession.setAttribute("QFJ_RESET_IO_CONNECTOR", Boolean.TRUE);
{code}


So, the attribute is definitely set, but as for the nullifying the _ioSession_'s reference I can't really say anything. All I know is that the _ioSession_'s reference is being read & written in *quickfix.mina.initiator.IoSessionInitiator :: resetIoConnector()* method at these two possible sections:

{code:java}
private void pollConnectFuture() {
try {
connectFuture.awaitUninterruptibly(CONNECT_POLL_TIMEOUT);
if (connectFuture.getSession() != null) { // probably true
ioSession = connectFuture.getSession();
connectionFailureCount = 0;
lastConnectTime = System.currentTimeMillis();
connectFuture = null;
} else {
fixSession.getLog().onEvent(
"Pending connection not established after "
+ (System.currentTimeMillis() - lastReconnectAttemptTime)
+ " ms.");
}
} catch (Throwable e) {
handleConnectException(e);
}
}
}
{code}

and

{code:java}
private void resetIoConnector() {
if (ioSession != null && Boolean.TRUE.equals(ioSession.getAttribute("QFJ_RESET_IO_CONNECTOR"))) {
try {
setupIoConnector();
log.info("[" + fixSession.getSessionID() + "] - reset IoConnector");
if (connectFuture != null) {
connectFuture.cancel();
}
connectFuture = null;
ioSession = null;
} catch (Throwable e) {
log.error("[" + fixSession.getSessionID() + "] - Exception during resetIoConnector call", e);
}
}
}
{code}

The latter one is definitely not the case as this method have never been invoked in the issue (we don't see the
{noformat}
"d.q.m.i.IoSessionInitiator [QFJ Timer] - [...] - reset IoConnector"
{noformat}
line in the log).

It's also unlikely that _ioSession_ is set to null in the former section, as the value comes from *connectFuture.getSession()* which, if being null, would lead to logging of a _"Pending connection not established"_ line. I thought maybe *connectFuture.getSession()* at some circumstances returns another IoSession object reference, for which there's no _"QFJ_RESET_IO_CONNECTOR"_ attribute set, but it would be too weird for MINA. So, it's likely not the case, and the only reason the *resetIoConnector()*'s check fails is that the *reconnectionTask*'s *run()* method is no more being invoked by *ScheduledExecutor*.

_ioSession_ have also never been closed as it would fire the *public void sessionClosed(IoSession ioSession)* callback in *quickfix.mina.AbstractIoHandler*, which in our case it wouldn't, even though *quickfix.Session :: disconnect* -> *quickfix.mina.IoSessionResponder :: disconnect* ->
*ioSession.closeOnFlush()* has been invoked.

I know that a bug is hard to fix when you can't reproduce the issue, so I've instrumented the quickfix/j source code in some places, and if this issue comes again, there will be more information available.

Here's a chunk of the log from the issue:

{noformat}
18:05:08.608 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=60 35=0 34=987 49=mySenderCompID 52=20170216-15:04:44.955 56=FG 10=245
18:05:08.608 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=61 35=0 49=FG 56=mySenderCompID 34=1031 52=20170216-15:05:02.450 10=004
18:05:48.648 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=82 35=0 34=988 49=mySenderCompID 52=20170216-15:05:42.889 56=FG 112=20170216-15:03:21 10=049
18:06:42.007 ERROR quickfixj.errorEvent [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Disconnecting: Timed out waiting for heartbeat
18:07:02.056 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=1 34=989 49=mySenderCompID 52=20170216-15:06:18.777 56=FG 112=TEST 10=024
18:07:07.852 INFO c.r.c.c.f.m.s.SessionManager [QFJ Message Processor]: the session has been logged out.
18:07:07.852 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: No responder, not sending message: 8=FIX.4.4 9=69 35=1 34=989 49=mySenderCompID 52=20170216-15:06:18.777 56=FG 112=TEST 10=024
18:07:24.587 INFO quickfixj.event [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: Already disconnected: Socket exception (/there-was-exchange-ip:port): java.io.IOException: Software caused connection abort
18:07:36.418 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: Sent test request TEST
18:10:45.383 ERROR quickfixj.errorEvent [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: quickfix.SessionException Logon state is not valid for message (MsgType=0)
18:11:53.890 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=0)
18:15:08.548 ERROR quickfixj.errorEvent [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: quickfix.SessionException Logon state is not valid for message (MsgType=1)
18:20:24.634 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=1)
18:27:38.224 ERROR quickfixj.errorEvent [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: quickfix.SessionException Logon state is not valid for message (MsgType=0)
18:29:40.972 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=0)
{noformat}

Here's a chunk of the log from the case when I manually switched off the connection:

{noformat}
00:57:35.829 INFO q.DefaultSessionSchedule [main] - [FIX.4.4:mySenderCompID->FG] daily, 07:00:00-UTC - 07:00:00-UTC
00:57:35.858 INFO quickfixj.event [main] - FIX.4.4:mySenderCompID->FG: Session FIX.4.4:mySenderCompID->FG schedule is daily, 07:00:00-UTC - 07:00:00-UTC
00:57:35.858 INFO quickfixj.event [main] - FIX.4.4:mySenderCompID->FG: Created session: FIX.4.4:mySenderCompID->FG
00:57:35.858 INFO c.r.c.c.f.m.s.SessionManager [main]: the session has been created.
00:57:35.865 INFO q.mina.NetworkingOptions [main] - Socket option: SocketTcpNoDelay=true
00:57:35.870 INFO q.mina.NetworkingOptions [main] - Socket option: SocketSynchronousWrites=false
00:57:35.870 INFO q.mina.NetworkingOptions [main] - Socket option: SocketSynchronousWriteTimeout=30000
00:57:35.939 INFO d.q.m.i.IoSessionInitiator [main] - [FIX.4.4:mySenderCompID->FG] [/there-was-exchange-ip:port]
00:57:35.940 INFO quickfix.SocketInitiator [main] - SessionTimer started
00:57:35.943 INFO quickfix.SocketInitiator [QFJ Message Processor] - Started QFJ Message Processor
00:57:35.988 INFO q.m.i.InitiatorIoHandler [NioProcessor-2] - MINA session created for FIX.4.4:mySenderCompID->FG: local=/there-was-my-ip:60450, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/there-was-exchange-ip:port
00:57:36.975 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=71 35=A 34=35 49=mySenderCompID 52=20170218-21:57:36.965 56=FG 98=0 108=30 10=234
00:57:36.980 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: Initiated logon request
00:57:37.003 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-2] - Processing a MESSAGE_RECEIVED for session 1
00:57:37.006 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=71 35=A 49=FG 56=mySenderCompID 34=35 52=20170218-21:58:55.258 98=0 108=30 10=231
00:57:37.007 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 49=FG 56=mySenderCompID 34=36 52=20170218-21:58:55.258 7=33 16=0 10=119
00:57:37.016 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received logon
00:57:37.016 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: MsgSeqNum too high, expecting 34 but received 35: 8=FIX.4.4 9=71 35=A 34=35 49=FG 52=20170218-21:58:55.258 56=mySenderCompID 98=0 108=30 10=231
00:57:37.016 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Enqueued at pos 35: 8=FIX.4.4 9=71 35=A 34=35 49=FG 52=20170218-21:58:55.258 56=mySenderCompID 98=0 108=30 10=231
00:57:37.017 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 34=36 49=mySenderCompID 52=20170218-21:57:37.017 56=FG 7=34 16=0 10=112
00:57:37.017 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent ResendRequest FROM: 34 TO: 34
00:57:37.017 INFO c.r.c.c.f.m.s.SessionManager [QFJ Message Processor]: the session has been logged on.
00:57:37.025 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Enqueued at pos 36: 8=FIX.4.4 9=69 35=2 34=36 49=FG 52=20170218-21:58:55.258 56=mySenderCompID 7=33 16=0 10=119
00:57:37.025 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received ResendRequest FROM: 33 TO: infinity
00:57:37.028 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=102 35=4 34=33 43=Y 49=mySenderCompID 52=20170218-21:57:37.027 56=FG 122=20170218-21:57:37.027 36=37 123=Y 10=040
00:57:37.028 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent SequenceReset TO: 37
00:57:37.033 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-2] - Processing a MESSAGE_RECEIVED for session 1
00:57:37.033 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=98 35=4 49=FG 56=mySenderCompID 34=34 43=Y 52=20170218-21:58:55.294 122=20170218-21:58:55 123=Y 36=37 10=072
00:57:37.033 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 49=FG 56=mySenderCompID 34=37 52=20170218-21:58:55.294 7=33 16=0 10=120
00:57:37.034 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: ResendRequest for messages FROM 34 TO 34 has been satisfied.
00:57:37.034 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received SequenceReset FROM: 34 TO: 37
00:57:37.034 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received ResendRequest FROM: 33 TO: infinity
00:57:37.035 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=102 35=4 34=33 43=Y 49=mySenderCompID 52=20170218-21:57:37.035 56=FG 122=20170218-21:57:37.035 36=37 123=Y 10=038
00:57:37.035 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent SequenceReset TO: 37
00:57:37.099 INFO OUTGOING [FIX Gate Mail Thread] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=139 35=D 34=37 49=mySenderCompID 52=20170218-21:57:37.097 56=FG 1=U51 11=0 38=1 40=2 44=17000 54=1 55=SRH7 59=0 60=20170219-00:57:37.096 1300=F 10=244
00:57:37.125 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-2] - Processing a MESSAGE_RECEIVED for session 1
00:57:37.125 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=231 35=8 49=FG 56=mySenderCompID 34=38 52=20170218-21:58:55.377 37=0 198=F:0 526=$01$ 11=0 17=3617265603 150=8 39=8 103=99 55=SRH7 54=1 38=1 40=2 151=1 14=0 6=0 60=20170218-21:58:55.376 58=3;Session inactive. 20018=[51000-3617265603-0] 10=090
00:57:42.123 DEBUG c.r.c.c.f.m.s.SessionManager [FIX Gate Mail Thread]: done processing an outgoing trading message.
00:57:42.131 INFO OUTGOING [FIX Gate Mail Thread] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=117 35=q 34=38 49=mySenderCompID 52=20170218-21:57:42.122 56=FG 1=U51 11=1F 55=SRH7 60=20170219-00:57:42.122 530=1 1300=F 10=079
00:57:42.149 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-2] - Processing a MESSAGE_RECEIVED for session 1
00:57:42.149 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=186 35=r 49=FG 56=mySenderCompID 34=39 52=20170218-21:59:00.409 11=1F 37=exec-201702181824434 530=1 531=1 533=0 58=0;Operation successful. 60=20170218-21:59:00.408 20018=[51000-3617265614-0] 10=123
00:58:11.992 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-2] - Processing a MESSAGE_RECEIVED for session 1
00:58:11.992 INFO INCOMING [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=59 35=0 49=FG 56=mySenderCompID 34=40 52=20170218-21:59:30.252 10=179
00:58:12.948 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=59 35=0 34=39 49=mySenderCompID 52=20170218-21:58:12.941 56=FG 10=191
00:58:42.948 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=59 35=0 34=40 49=mySenderCompID 52=20170218-21:58:42.941 56=FG 10=186
00:58:57.948 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=68 35=1 34=41 49=mySenderCompID 52=20170218-21:58:57.941 56=FG 112=TEST 10=212
00:58:57.949 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: Sent test request TEST
00:59:01.895 ERROR quickfixj.errorEvent [NioProcessor-2] - FIX.4.4:mySenderCompID->FG: Disconnecting: Socket exception (/there-was-exchange-ip:port): java.io.IOException: Connection reset by peer
00:59:01.903 INFO c.r.c.c.f.m.s.SessionManager [NioProcessor-2]: the session has been logged out.
00:59:02.563 INFO d.q.m.i.IoSessionInitiator [QFJ Timer] - [FIX.4.4:mySenderCompID->FG] - reset IoConnector
00:59:02.565 ERROR quickfixj.errorEvent [QFJ Timer] - FIX.4.4:mySenderCompID->FG: java.net.NoRouteToHostException during connection to /there-was-exchange-ip:port: java.net.NoRouteToHostException: No route to host: no further information (Next retry in 30000 milliseconds)
00:59:32.713 INFO q.m.i.InitiatorIoHandler [NioProcessor-12] - MINA session created for FIX.4.4:mySenderCompID->FG: local=/there-was-my-ip:60459, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/there-was-exchange-ip:port
00:59:32.941 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=71 35=A 34=42 49=mySenderCompID 52=20170218-21:59:32.941 56=FG 98=0 108=30 10=224
00:59:32.949 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: Initiated logon request
00:59:32.984 INFO quickfix.Session [QFJ Message Processor] - [FIX.4.4:mySenderCompID->FG] Disconnecting: Encountered END_OF_STREAM
00:59:32.992 INFO c.r.c.c.f.m.s.SessionManager [QFJ Message Processor]: the session has been logged out.
00:59:33.724 INFO d.q.m.i.IoSessionInitiator [QFJ Timer] - [FIX.4.4:mySenderCompID->FG] - reset IoConnector
01:00:02.879 INFO q.m.i.InitiatorIoHandler [NioProcessor-22] - MINA session created for FIX.4.4:mySenderCompID->FG: local=/there-was-my-ip:60480, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/there-was-exchange-ip:port
01:00:02.941 INFO OUTGOING [QFJ Timer] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=71 35=A 34=43 49=mySenderCompID 52=20170218-22:00:02.941 56=FG 98=0 108=30 10=209
01:00:02.952 INFO quickfixj.event [QFJ Timer] - FIX.4.4:mySenderCompID->FG: Initiated logon request
01:00:02.981 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-22] - Processing a MESSAGE_RECEIVED for session 3
01:00:02.991 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=71 35=A 49=FG 56=mySenderCompID 34=43 52=20170218-22:01:21.219 98=0 108=30 10=209
01:00:02.992 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 49=FG 56=mySenderCompID 34=44 52=20170218-22:01:21.219 7=40 16=0 10=095
01:00:02.992 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received logon
01:00:03.002 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: MsgSeqNum too high, expecting 41 but received 43: 8=FIX.4.4 9=71 35=A 34=43 49=FG 52=20170218-22:01:21.219 56=mySenderCompID 98=0 108=30 10=209
01:00:03.002 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Enqueued at pos 43: 8=FIX.4.4 9=71 35=A 34=43 49=FG 52=20170218-22:01:21.219 56=mySenderCompID 98=0 108=30 10=209
01:00:03.003 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 34=44 49=mySenderCompID 52=20170218-22:00:03.003 56=FG 7=41 16=0 10=086
01:00:03.003 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent ResendRequest FROM: 41 TO: 42
01:00:03.003 INFO c.r.c.c.f.m.s.SessionManager [QFJ Message Processor]: the session has been logged on.
01:00:03.003 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Enqueued at pos 44: 8=FIX.4.4 9=69 35=2 34=44 49=FG 52=20170218-22:01:21.219 56=mySenderCompID 7=40 16=0 10=095
01:00:03.013 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received ResendRequest FROM: 40 TO: infinity
01:00:03.014 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=102 35=4 34=40 43=Y 49=mySenderCompID 52=20170218-22:00:03.014 56=FG 122=20170218-22:00:03.014 36=45 123=Y 10=249
01:00:03.014 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent SequenceReset TO: 45
01:00:03.022 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-22] - Processing a MESSAGE_RECEIVED for session 3
01:00:03.022 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=98 35=4 49=FG 56=mySenderCompID 34=41 43=Y 52=20170218-22:01:21.270 122=20170218-22:01:21 123=Y 36=45 10=027
01:00:03.022 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=69 35=2 49=FG 56=mySenderCompID 34=45 52=20170218-22:01:21.270 7=40 16=0 10=093
01:00:03.022 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received SequenceReset FROM: 41 TO: 45
01:00:03.023 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Received ResendRequest FROM: 40 TO: infinity
01:00:03.023 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=102 35=4 34=40 43=Y 49=mySenderCompID 52=20170218-22:00:03.023 56=FG 122=20170218-22:00:03.023 36=45 123=Y 10=249
01:00:03.023 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: Sent SequenceReset TO: 45
01:00:33.049 DEBUG o.a.m.f.c.ProtocolCodecFilter [NioProcessor-22] - Processing a MESSAGE_RECEIVED for session 3
01:00:33.049 INFO INCOMING [NioProcessor-22] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=59 35=0 49=FG 56=mySenderCompID 34=46 52=20170218-22:01:51.258 10=182
01:00:33.060 INFO quickfixj.event [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: ResendRequest for messages FROM 41 TO 42 has been satisfied.
01:00:33.070 INFO OUTGOING [QFJ Message Processor] - FIX.4.4:mySenderCompID->FG: 8=FIX.4.4 9=59 35=0 34=45 49=mySenderCompID 52=20170218-22:00:33.070 56=FG 10=172
{noformat}
QuickfixJ, Reconnect 0|i005z3:
QuickFIX/J QFJ-915

After sending TEST REQUEST message, FIXEngine can't be connected

Bug Closed Default Incomplete Unassigned Dai Shinohara Dai Shinohara 14/Feb/17 17:16   15/Feb/17 08:19 15/Feb/17 08:19 1.5.3   Engine   0 2   Java 1.7, RHEL 6.3 We are using QuickFIX on the Initiator side.
Suddenly, QuickFIX sent TEST REQUEST.
Acceptor returned HEARTBEAT message immediately.
But QuickFIX didn't recognize HEARTBEAT message.
Therefore QuickFIX judged time-out.

After judging time-out, QuickFIX sent LOGON message.
Acceptor returned LOGON message immediately.
But QuickFIX didn't recognize LOGON message again.
Therefore QuickFIX judged time-out.

20170209-00:01:26: Sent test request TEST
20170209-00:02:20: Disconnecting: Timed out waiting for heartbeat
20170209-00:02:21: Initiated logon request
20170209-00:02:32: Disconnecting: Timed out waiting for logon response
20170209-00:02:33: Initiated logon request
20170209-00:02:43: Disconnecting: Timed out waiting for logon response
20170209-00:02:44: Initiated logon request
20170209-00:02:54: Disconnecting: Timed out waiting for logon response
20170209-00:02:55: Initiated logon request
20170209-00:03:05: Disconnecting: Timed out waiting for logon response

Acceptor message log:
2017 Feb 09 09:01:24.041.936 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:24.041,34=1195283,...
2017 Feb 09 09:01:24.203.275 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:01:24.203,34=1195284,...
2017 Feb 09 09:01:24.424.520 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:01:24.424,34=1195285,...
2017 Feb 09 09:01:25.012.688 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:01:25.012,34=1195286,...
2017 Feb 09 09:01:25.013.568 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:25.013,34=1195287,...
2017 Feb 09 09:01:25.109.057 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:01:25.108,34=1195288,...
2017 Feb 09 09:01:25.293.963 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:01:25.293,34=1195289,...
2017 Feb 09 09:01:25.525.713 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:25.525,34=1195290,...
2017 Feb 09 09:01:26.141.202 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:26.141,34=1195291,...
2017 Feb 09 09:01:26.270.703 [FIXRCV] 8=FIX.4.4,9=70,35=1,34=5411,49=...,52=20170209-00:01:26.270,56=...,112=TEST,10=146
2017 Feb 09 09:01:26.270.787 [FIXSND] 8=FIX.4.4,9=73,35=0,52=20170209-00:01:26.270,34=1195292,49=SCI,56=...,112=TEST,10=054
2017 Feb 09 09:01:26.424.711 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:01:26.424,34=1195293,...
2017 Feb 09 09:01:26.429.398 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:26.429,34=1195294,...
2017 Feb 09 09:01:26.641.169 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:01:26.641,34=1195295,...
2017 Feb 09 09:01:26.994.496 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:01:26.994,34=1195296,...
2017 Feb 09 09:01:26.994.933 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:01:26.994,34=1195297,...
2017 Feb 09 09:01:27.109.910 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:01:27.109,34=1195298,...
.
.
.
2017 Feb 09 09:02:18.992.329 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:02:18.992,34=1195523,...
2017 Feb 09 09:02:19.300.151 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:02:19.300,34=1195524,...
2017 Feb 09 09:02:19.310.049 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:02:19.309,34=1195525,...
2017 Feb 09 09:02:19.508.998 [FIXSND] 8=FIX.4.4,9=220,35=S,52=20170209-00:02:19.508,34=1195526,...
2017 Feb 09 09:02:19.720.621 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:02:19.720,34=1195527,...
2017 Feb 09 09:02:19.766.977 [FIXSND] 8=FIX.4.4,9=216,35=S,52=20170209-00:02:19.766,34=1195528,...
2017 Feb 09 09:02:19.888.979 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:02:19.888,34=1195529,...
2017 Feb 09 09:02:19.949.890 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:02:19.949,34=1195530,...
2017 Feb 09 09:02:20.050.769 [FIXSND] 8=FIX.4.4,9=218,35=S,52=20170209-00:02:20.050,34=1195531,...
2017 Feb 09 09:02:21.271.969 [FIXRCV] 8=FIX.4.4,9=76,35=A,34=1,49=...,52=20170209-00:02:21.271,56=...,98=0,108=60,141=Y,10=066
2017 Feb 09 09:02:21.312.495 [FIXSND] 8=FIX.4.4,9=76,35=A,52=20170209-00:02:21.312,34=1,49=SCI,56=JBKI-QUOTE01,98=0,108=60,141=Y,1

Initiator message log
8=FIX.4.4^A9=218^A35=S^A52=20170209-00:02:19.309^A34=1195525...
8=FIX.4.4^A9=220^A35=S^A52=20170209-00:02:19.508^A34=1195526...
8=FIX.4.4^A9=216^A35=S^A52=20170209-00:02:19.720^A34=1195527...
8=FIX.4.4^A9=216^A35=S^A52=20170209-00:02:19.766^A34=1195528...
8=FIX.4.4^A9=218^A35=S^A52=20170209-00:02:19.888^A34=1195529...
8=FIX.4.4^A9=218^A35=S^A52=20170209-00:02:19.949^A34=1195530...
8=FIX.4.4^A9=218^A35=S^A52=20170209-00:02:20.050^A34=1195531...
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:02:21.271^A56=...^A98=0^A108=60^A141=Y^A10=066^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:02:21.312^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=062^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:02:33.270^A56=...^A98=0^A108=60^A141=Y^A10=068^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:02:33.283^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=072^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:02:44.270^A56=...^A98=0^A108=60^A141=Y^A10=070^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:02:44.285^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=076^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:02:55.270^A56=...^A98=0^A108=60^A141=Y^A10=072^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:02:55.280^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=073^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:03:06.270^A56=...^A98=0^A108=60^A141=Y^A10=069^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:03:06.285^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=075^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:03:17.270^A56=...^A98=0^A108=60^A141=Y^A10=071^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:03:17.279^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=080^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:03:28.270^A56=...^A98=0^A108=60^A141=Y^A10=073^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:03:28.280^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=074^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:03:39.270^A56=...^A98=0^A108=60^A141=Y^A10=075^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:03:39.304^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=073^A
8=FIX.4.4^A9=76^A35=A^A34=1^A49=...^A52=20170209-00:03:50.270^A56=...^A98=0^A108=60^A141=Y^A10=068^A
8=FIX.4.4^A9=76^A35=A^A52=20170209-00:03:50.282^A34=1^A49=...^A56=...^A98=0^A108=60^A141=Y^A10=071^A


We hava 2 questions.
1.Why did QuickFIX send TEST REQUEST suddenly?
2.Is this problem settled by a newest version?
QuickfixJ, testRequest, timeout 0|i005yv:
QuickFIX/J QFJ-914

Generate and package javadoc for release build

Improvement Open Major Unresolved Christoph John Christoph John Christoph John 14/Feb/17 10:12   27/Apr/17 14:13     1.6.4     0 1   {quote}
-------- Forwarded Message --------
Subject: Re: [Quickfixj-users] QuickFIX/J 1.6.3 Javadoc - Message classes appear to be missing
Date: Wed, 1 Feb 2017 09:16:59 -0700 (MST)
From: thannon <th@ftlabs.com>
Reply-To: quickfixj-users@lists.sourceforge.net
To: quickfixj-users@lists.sourceforge.net


QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


I think it would be helpful for release builds. Having Javadoc is useful
with some IDEs, and particularly for those that are not as familiar with or
new to QF/J or those that only work with it occasionally.

Thank you.
{quote}


Javadoc generation was disabled some time ago since it took quite long. We should re-enable it for release builds only.
0|i005yn:
QuickFIX/J QFJ-913

SSL warning when using default keystore (quickfixj.keystore)

Bug Open Default Unresolved Unassigned chenbaoyi chenbaoyi 07/Feb/17 04:05   07/Feb/17 12:26   1.6.0, 1.6.1, 1.6.2, 1.6.3   Build, Networking   0 2   java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

Linux version 2.6.32-642.11.1.el6.x86_64 (mockbuild@c1bm.rdu2.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) ) #1 SMP Fri Nov 18 19:25:05 UTC 2016
[DEFAULT]
BeginString=FIX.4.3
ConnectionType=initiator
EndDay=xxxxx
StartDay=Sunday
EndTime=xxxxxx
StartTime=xxxxx
HeartBtInt=30
ResetOnLogon=Y
ResetOnLogout=N
ResetOnDisconnect=N
ReconnectInterval=xxxx
FileIncludeMilliseconds=Y
FileIncludeTimeStampForMessages=Y
FileLogPath=xxxxxx
FileStorePath=xxxxx
ValidateUserDefinedFields=N
ValidateFieldsHaveValues=N
ValidateFieldsOutOfOrder=N
ValidateUnorderedGroupFields=N
ValidateSequenceNumbers=N

[SESSION]
Username=xxxxx
Password=xxxxx
SenderCompID=xxx
TargetCompID=xxx
SocketUseSSL=Y
SocketConnectPort=xxxx
SocketConnectHost=xxx.xxx.xxx.xxx
DataDictionary=xxx.xml

using above setting
when connect to acceptor
console will log a warnning
SSLContextFactory.initializeKeyStore:111]quickfixj.keystore: keystore not found, using empty keystore

the root cause of this issue is when building quickfixj-1.6.3
quickfixj-core/pom.xml does not contains the /src/main/resources
0|i005y7:
QuickFIX/J QFJ-912

Support use of externally supplied ThreadPools

New Feature Resolved Default Fixed James Olsen James Olsen James Olsen 24/Jan/17 19:54   31/Jan/17 11:59 31/Jan/17 11:59 1.6.3 1.6.4 Engine   0 2   Currently when embedding QFJ inside a ResourceAdapter we end up with double the Threads running as we have to hand-off from QFJ ('dirty') Threads to the ResourceAdapter WorkManager ('clean') Threads before calling back into the EJB side of the container. Using 'clean' Threads for this is a requirement of the JCA/ResourceAdapter contracts.

To eliminate the extra Threads and hand-off context switching we need to be able to request QFJ to use the 'clean' Threads directly.
0|i005xz:
QuickFIX/J QFJ-911

ResendRequests that fail to be sent are treated as sent

Bug Open Default Unresolved Unassigned Philip Whitehouse Philip Whitehouse 03/Jan/17 16:55   04/Jan/17 10:43           0 2   https://github.com/quickfix-j/quickfixj/blob/629b801446431f06e0426aebcf669a2eca341a69/quickfixj-core/src/main/java/quickfix/Session.java#L2349

The return value from sendRaw() is ignored. If the message fails to send then we will still log that we have sent a resend request and (more crucially) still treat ourselves as having sent one for the purposes of whether we should send another.

At best this is merely misleading but I think it can actually cause problems in certain cases.
0|i005xr:
QuickFIX/J QFJ-910

MessageUtils.parse does not respect the dictionary order

Bug Closed Blocker Not a bug Unassigned anup singh anup singh 21/Dec/16 10:10   21/Dec/16 11:59 21/Dec/16 11:59 1.7.0   Message Generation   0 3   Hi Team,

I have a message which was not in order as dictionary but i try to use the MessageUtils.parse(messageFactory, dictionary, targetMessage.toString());

to re-ordered but it is still not respecting my dictionary order.can someone please help on this ?
QuickfixJ 0|i005xj:
QuickFIX/J QFJ-909

Unexpected Behaviour for ValidateIncomingMessage=N

Bug Closed Default Duplicate Unassigned Justin Phung Justin Phung 08/Dec/16 09:36   05/Apr/17 06:43 05/Apr/17 06:43         0 2   While configuring my fix engine I found out that the configuration tag ValidateIncomingMessage=N does not work as expected. My goal is to use the DataDictionary to recognize the message type. Still, while not validating incoming message I do not want my fix engine to bring the fix tags in the messages out of order.

Incoming fix messages
{quote}
8=FIX.4.4|9=264|35=AR|34=510|49=OTCX-GLOX|52=20161208-09:13:54.258|56=GLOX-OTCX|15=CHF|17=201612081000000171|22=4|48=CH0000975372|55=[N/A]|150=0|207=BNO|487=0|571=14811884339561|572=201612081000085|856=1|552=1|54=7|526=TESTBIR2|453=1|448=trts01|447=D|452=7|802=1|523=sauer|803=25|10=230|
8=FIX.4.4|9=285|35=AR|34=511|49=OTCX-GLOX|52=20161208-09:13:54.263|56=GLOX-OTCX|15=CHF|17=201612081000000172|22=4|48=CH0000975372|55=[N/A]|150=F|207=BNO|487=0|571=14811884339561|572=201612081000085|856=1|880=OTC16L08A0000933|552=1|54=7|526=TESTBIR2|453=1|448=trts01|447=D|452=7|802=1|523=sauer|803=25|10=124|

{quote}

Outgoing fix messages
{quote}
8=FIX.4.4|9=271|35=AR|34=1040|49=OTCX-GLOX|52=20161208-09:13:54.308|56=GLOX-OTCX|15=CHF|17=201612081000000171|22=4|48=CH0000975372|54=7|55=[N/A]|150=0|207=BNO|447=D|448=trts01|452=7|453=1|487=0|523=sauer|526=TESTBIR2|552=1|571=Glox-201612081000001|572=201612081000085|802=1|803=25|856=1|10=222|
8=FIX.4.4|9=292|35=AR|34=1041|49=OTCX-GLOX|52=20161208-09:13:54.313|56=GLOX-OTCX|15=CHF|17=201612081000000172|22=4|48=CH0000975372|54=7|55=[N/A]|150=F|207=BNO|447=D|448=trts01|452=7|453=1|487=0|523=sauer|526=TESTBIR2|552=1|571=Glox-201612081000001|572=201612081000085|802=1|803=25|856=1|880=OTC16L08A0000933|10=116|
{quote}
0|i005xb:
QuickFIX/J QFJ-908

-Dgenerator.decimal=true not working for existing fields

Bug Closed Major Cannot Reproduce Unassigned Vipin Chaudhary Vipin Chaudhary 18/Nov/16 08:59   18/Nov/16 10:50 18/Nov/16 10:50 1.6.2   Engine   0 2   when I am packaging code using -Dgenerator.decimal=true, the existing Price type field are not changing to BigDecima.

I want that all Price Type fields should take BigDecimal as input. As per the documentation this can be if we compile code using -Dgenerator.decimal=true option.

I used "package -Dgenerator.decimal=true -DskipAT=true" but still Price type fields constructor are taking double field.

I added some custom fields of Price type and those new custom fields constructor are taking BigDecimal value. So It seems that this(-Dgenerator.decimal=true) is working for new fields only.
generator.decimal 0|i005x3:
QuickFIX/J QFJ-907

Dead sockets are not closed when SocketInitiator is stopped

Bug Open Default Unresolved Unassigned Paul Rowe Paul Rowe 04/Nov/16 03:14   29/Mar/17 19:45   1.5.3   Engine   0 2   Steps to reproduce:

1. Create a socket initiator that connects to a socket that does nothing
2. Start the initiator and observe that it connects to the socket
3. Stop the initiator before the reconnectinterval kicks in
4. Observe that the socket remains open

Background:

Recently we observed that during our session end schedule processing, a client will logoff on time ... we delay a bit, and then we close our socket initiator. In-between the time the client logged off and the time that we closed the socket initiator, a new socket connection was established to the client. This connection was "dead," e.g. it did not respond to FIX requests/responses. This dead socket remained connected until the next session start, where an additional socket was opened. Just after a new additional socket was opened, the client realized they had a dead connection open to us, and decided to close that dead connection.

We have special handling on SessionStateListener.onConnect() and SessionStateListener.onDisconnect(). When a new socket was created on the session start, SessionStateListener.onConnect() was called. This led us to believe everything was OK with this session. Then, when the dead socket was closed, SessionStateListener.onDisconnect() was called just after. This broke our internal logic because we thought this session was disconnected, when in fact it was operating normally.

To avoid this problem in the future, if rogue dead sockets are created, then it should be up to the initiator to close these sockets.
0|i005wv:
QuickFIX/J QFJ-906

Compile QFJ 1.6.x against JDK7 and QFJ 1.7.x against JDK8

Improvement Closed Major Fixed Guido Medina Christoph John Christoph John 18/Oct/16 07:08   13/Dec/16 22:51 10/Dec/16 22:33   1.6.3, 1.7.0     0 2   We should compile at least against JDK7 for various reasons:
* JDK6 is quite old now and end-of-life (actually, even JDK7 is)
* some of the SSL tests do not work with JDK6 since it does not support all ciphers
* MINA 2.0.15 is compiled against JDK7
* some smaller improvements in the code could be made (multi-catch, diamond operator, ...)

Since there only is a 1.7.0-SNAPSHOT release now (i.e. no released version), we can simply compile against JDK8 there.
0|i005wn:
QuickFIX/J QFJ-905

MULTIPLECHARVALUE not handled in FieldType since FIX 5.0. version

Bug Open Default Unresolved Unassigned François Milot François Milot 23/Sep/16 13:32   23/Sep/16 14:08   1.5.0   Engine   0 2   I encountered an issue testing a simple order sending in FIX 5.0. SP2. I send an order with value 18=1 3 and got rejected because of IncorrectTagValue exception (in Session.next method while validating the message).

Problem is that isMultipleValueStringField method does return false for MULTIPLECHARVALUE type.
0|i005vz:
QuickFIX/J QFJ-904

Maven central repo releases don't support using BigDecimal

Improvement Closed Default Duplicate Unassigned Rose Rose 14/Sep/16 20:22   15/Sep/16 09:06 15/Sep/16 09:06         0 2   I was really happy to see quickfixj on Maven Central - thank you!

But unfortunately, the -bd jars to support using BigDecimal instead of Double aren't being published there.

Could you please update your build to publish the bd variants as well?
0|i005vr:
QuickFIX/J QFJ-903

Infinite Loop on Malformed Message - Bad BodyLength (tag 9)

Bug Closed Critical Fixed Christoph John Adam MacDonald Adam MacDonald 13/Sep/16 14:09   13/Dec/16 22:51 08/Oct/16 23:01 1.6.2 1.6.3 Engine   0 2   If two messages are received in a row with a malformed tag 9 - the fix engine enters an infinite loop of logging and eventually causes the JVM to crash with an OutOfMemory exception.

Sent the following message twice
{code}
8=FIX.4.4|9=A|35=D|49=ST|56=TS|34=3|52=20160830-14:21:45.472|11=Order32|1=Template1|21=1|55=VOD.L|48=VOD.L|22=5|167=CS|207=LSE|54=1|60=20160830-14:21:45.472|38=100|40=2|44=95|15=GBp|59=0|58=Staging|10=206|
{code}

Enter infinite loop in
{code}
quickfix.mina.message.FIXMessageDecoder#parseMessage
{code}
logging
{code}
quickfix.mina.message.FIXMessageDecoder - handleError - Length format error in message (last character:65)
{code}
0|i005vj:
QuickFIX/J QFJ-902

Logon rejected even though within session time

Bug Open Major Unresolved Unassigned anurag jain anurag jain 06/Sep/16 03:58   21/Sep/16 11:30   1.5.3   Engine   3 5   Software:
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

Operating System:
Linux earth 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
From time to time we have seen certain fix connection can not login even though within the session times. Please see logs below:

*[Session1 details]*
{noformat}
2016-09-02 06:03:02,607 [main] INFO quickfix.SessionSchedule - [FIX.4.4-MDAQOM_session1-session1_MDAQOM] daily, 23:00:00-UTC - 10:00:00-UTC
2016-09-02 06:03:02,607 [main] INFO quickfixj.event - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Session FIX.4.4-MDAQOM_session1-session1_MDAQOM schedule is daily, 23:00:00-UTC - 10:00:00-UTC
2016-09-02 06:03:02,607 [main] INFO quickfixj.event - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Session state is not current; resetting FIX.4.4-MDAQOM_session1-session1_MDAQOM
2016-09-02 06:03:02,607 [main] INFO quickfixj.event - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Created session: FIX.4.4-MDAQOM_session1-session1_MDAQOM
{noformat}

*[Session connects before allowed time of 7am Singapore time. First exception noticed]*
{noformat}
2016-09-02 06:17:21,636 [QFJ Message Processor] ERROR quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Error Reading/Writing in MessageStore
java.io.IOException: Stream Closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at quickfix.FileStore.set(FileStore.java:430)
at quickfix.SessionState.set(SessionState.java:310)
at quickfix.Session.sendRaw(Session.java:2433)
at quickfix.Session.generateLogout(Session.java:1339)
at quickfix.Session.generateLogout(Session.java:1309)
at quickfix.Session.next(Session.java:1036)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:745)

2016-09-02 06:17:21,636 [QFJ Message Processor] WARN quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Disconnecting: Logon rejected: quickfix.RejectLogon: Logon attempt not within session time
{noformat}

*[Logon happened again this time the stack trace looked like this]*
{noformat}
2016-09-02 06:17:26,635 [QFJ Message Processor] ERROR quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Error Reading/Writing in MessageStore
java.io.IOException: Stream Closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at quickfix.FileStore.set(FileStore.java:430)
at quickfix.SessionState.set(SessionState.java:310)
at quickfix.Session.sendRaw(Session.java:2433)
at quickfix.Session.generateLogout(Session.java:1339)
at quickfix.Session.generateLogout(Session.java:1309)
at quickfix.Session.next(Session.java:1036)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:745)

2016-09-02 06:17:26,635 [QFJ Message Processor] ERROR quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Stream Closed
java.io.IOException: Stream Closed
at java.io.RandomAccessFile.seek0(Native Method)
at java.io.RandomAccessFile.seek(RandomAccessFile.java:557)
at quickfix.FileStore.storeSequenceNumbers(FileStore.java:439)
at quickfix.FileStore.incrNextTargetMsgSeqNum(FileStore.java:333)
at quickfix.SessionState.incrNextTargetMsgSeqNum(SessionState.java:370)
at quickfix.Session.next(Session.java:1039)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:745)

2016-09-02 06:17:26,635 [QFJ Timer] ERROR quickfix.SocketAcceptor - Error during timer processing
quickfix.RuntimeError: java.io.IOException: Stream Closed
at quickfix.SessionState.reset(SessionState.java:381)
at quickfix.Session.resetState(Session.java:2451)
at quickfix.Session.reset(Session.java:814)
at quickfix.Session.next(Session.java:1749)
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:283)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Stream Closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
at quickfix.FileStore.closeOutputStream(FileStore.java:258)
at quickfix.FileStore.close(FileStore.java:243)
at quickfix.FileStore.deleteFiles(FileStore.java:263)
at quickfix.FileStore.initialize(FileStore.java:107)
at quickfix.FileStore.reset(FileStore.java:481)
at quickfix.SessionState.reset(SessionState.java:379)
... 11 more
{noformat}

*[Finally logon within the session time, even then the session could not connect]*
{noformat}
2016-09-02 07:00:00,760 [SocketAcceptorIoProcessor-2.0] INFO quickfixj.msg.incoming - FIX.4.4-MDAQOM_session1-session1_MDAQOM: 8=FIX.4.4^A9=169^A35=A^A34=1^A49=session1_MDAQOM^A52=20160901-23:00:00.820^A56=MDAQOM_session1^A98=0^A108=30^A141=Y^A553=session1^A554=<masked>^A10=028^A
2016-09-02 07:00:00,760 [SocketAcceptorIoProcessor-2.0] INFO quickfixj.event - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Accepting session FIX.4.4-MDAQOM_session1-session1_MDAQOM from /192.168.10.16:60121
2016-09-02 07:00:00,760 [SocketAcceptorIoProcessor-2.0] INFO quickfixj.event - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Acceptor heartbeat set to 30 seconds
2016-09-02 07:00:00,760 [QFJ Message Processor] WARN quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Logon rejected: quickfix.RejectLogon: Logon attempt not within session time
2016-09-02 07:00:00,760 [QFJ Message Processor] INFO quickfixj.msg.outgoing - FIX.4.4-MDAQOM_session1-session1_MDAQOM: 8=FIX.4.4^A9=108^A35=5^A34=1^A49=MDAQOM_session1^A52=20160901-23:00:00.760^A56=session1_MDAQOM^A58=Logon attempt not within session time^A10=071^A
2016-09-02 07:00:00,760 [QFJ Message Processor] ERROR quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Error Reading/Writing in MessageStore
java.io.IOException: Stream Closed
at java.io.RandomAccessFile.getFilePointer(Native Method)
at quickfix.FileStore.set(FileStore.java:422)
at quickfix.SessionState.set(SessionState.java:310)
at quickfix.Session.sendRaw(Session.java:2433)
at quickfix.Session.generateLogout(Session.java:1339)
at quickfix.Session.generateLogout(Session.java:1309)
at quickfix.Session.next(Session.java:1036)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:745)

2016-09-02 07:00:00,760 [QFJ Message Processor] ERROR quickfixj.errorEvent - FIX.4.4-MDAQOM_session1-session1_MDAQOM: Stream Closed
java.io.IOException: Stream Closed
at java.io.RandomAccessFile.seek0(Native Method)
at java.io.RandomAccessFile.seek(RandomAccessFile.java:557)
at quickfix.FileStore.storeSequenceNumbers(FileStore.java:439)
at quickfix.FileStore.incrNextTargetMsgSeqNum(FileStore.java:333)
at quickfix.SessionState.incrNextTargetMsgSeqNum(SessionState.java:370)
at quickfix.Session.next(Session.java:1039)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:745)
{noformat}

This happens endlessly. Finally we had to bounce to fix this. This has happened more frequently as we have on-boarded more users

Questions:
- Please tell us what is causing the issue
- Why does the stream closed issue happen so often?
- Is this issue fixed in a later version?
- Any workarounds ?

This is quite a critical item for us so would appreciate the turnaround, thanks!
0|i005vb:
QuickFIX/J QFJ-901

Value is incorrect (out of range) for this tag:35

Bug Closed Default Not a bug Unassigned SUNIL SUNIL 02/Sep/16 07:07   02/Sep/16 08:29 02/Sep/16 08:29         0 2   0|i005v3:
QuickFIX/J QFJ-900

CLONE - Need help to clarify if QuickFix/J supports TLS

Other Closed Default Not a bug Unassigned vijayasree vijayasree 08/Aug/16 09:23   08/Aug/16 09:51 08/Aug/16 09:44         0 3   Hi

We are using QuickFix/J to connect to ICE Exchange to poll our exchange trades. ICE exchange has notified us they would be discontinuing the support of SSL protocol & would be migrating to TLS. Since we are using QuickFix/J API from our code, we are unsure about the impact we would be going to face. So we would like your help to confirm if QuickFix/J supports TLS, and the API is not tightly coupled to network protocols. Kindly help us clarify., Thanks in advance


Thanks & Regards
Vijayasree
0|i005uv:
QuickFIX/J QFJ-899

Need help to clarify if QuickFix/J supports TLS

Other Closed Default Not a bug Unassigned vijayasree vijayasree 08/Aug/16 09:15   08/Aug/16 09:44 08/Aug/16 09:44         0 2   Hi

We are using QuickFix/J to connect to ICE Exchange to poll our exchange trades. ICE exchange has notified us they would be discontinuing the support of SSL protocol & would be migrating to TLS. Since we are using QuickFix/J API from our code, we are unsure about the impact we would be going to face. So we would like your help to confirm if QuickFix/J supports TLS, and the API is not tightly coupled to network protocols. Kindly help us clarify., Thanks in advance


Thanks & Regards
Vijayasree
0|i005un:
QuickFIX/J QFJ-898

auto reconnect fails?

Bug Closed Default Duplicate Unassigned Andre Mermegas Andre Mermegas 05/Aug/16 20:00   08/Aug/16 08:07 08/Aug/16 08:07 1.6.2   Networking   0 2   1.6.2 and mina 2.0.13 initiator configured as such fails to keep trying to reconnect after disconnect. I'm investigating now but has anybody had a similar experience?

TimeZone=America/New_York
StartDay=Sunday
StartTime=00:00:00
EndDay=Sunday
EndTime=00:00:00
ResetOnLogon=Y
HeartBtInt=30
ReconnectInterval=0


DEBUG (2016-08-05 05:39:07,372) [QFJ Timer] (Connector) - ::StartSession -> Thu Aug 04 13:04:01 EDT 2016
DEBUG (2016-08-05 05:39:07,372) [QFJ Timer] (Connector) - ::StopSession -> Fri Aug 05 05:39:07 EDT 2016
DEBUG (2016-08-05 05:39:07,372) [QFJ Timer] (Connector) -


INFO (2016-08-05 05:39:07,653) [NioProcessor-2] (event) - FIX.4.4:xxxx: Already disconnected: Socket exception (xxxx): java.io.IOException: An established connection was aborted by the software in your host machine
INFO (2016-08-05 05:39:07,949) [NioProcessor-2] (event) - FIX.4.4:xxxx: Already disconnected: Socket exception (xxxx): org.apache.mina.core.write.WriteTimeoutException
0|i005uf:
QuickFIX/J QFJ-897

AbstractSocketAcceptor does not stop its internal IoAcceptors correctly

Bug Closed Default Fixed Uwe Guenther Uwe Guenther Uwe Guenther 11/Jul/16 11:38   13/Dec/16 22:51 11/Jul/16 15:11 1.6.2 1.6.3 Engine   0 2   Linux We having a productive setup where we are reuse sessions and create, start, stop ThreadedSocketAcceptor as we need them. We do not reuse them.

In Prod we saw the following problem: We were running out of file descriptors on ore 32 CPU Linux box with a max open file desriptor settings of 4096 after several days running around 20 quickfixj sessions within one JVM.

*Issue:*
After debugging the quickfixj and the apache mina code we found out, quickfixj is only unbinding the internal used IoAcceptors in its protected method AbstractSocketAcceptor#stopAcceptingConnections(), but not disposing them which is releasing the NIO Selectors used by Apache Mina. As a result the ExecutorServices created by Mina are not shouting down and their run() method is waiting on an internal inter thread communication lock forever.

*Solution:*
Just do a ioAcceptor.dispose(true); in ioAcceptor.unbind(); in quickfix.mina.acceptor.AbstractSocketAcceptor#stopAcceptingConnections() after line 248

{code}
protected void stopAcceptingConnections() throws ConfigError {
Iterator<IoAcceptor> ioIt = ioAcceptors.values().iterator();
while (ioIt.hasNext()) {
IoAcceptor ioAcceptor = ioIt.next();
SocketAddress localAddress = ioAcceptor.getLocalAddress();
ioAcceptor.unbind();
ioAcceptor.dispose(true);
log.info("No longer accepting connections on " + localAddress);
ioIt.remove();
}
}
{code}
QuickfixJ 0|i005u7:
QuickFIX/J QFJ-896

Connection to Server is closed after sending Logon message

Bug Closed Default Not a bug Unassigned Jeff Lee Jeff Lee 10/Jul/16 08:09   11/Jul/16 08:12 11/Jul/16 08:12 1.6.0   Networking   0 2   Windows8, Java1.8, Eclipse Mars.2 Release (4.5.2) I want to logon to dukascopy and send a market data request message. the session can be created, but when a send a logon message, the connection is closed with message "INFO: [FIX.4.4:FEED_wangqilin2015_DEMOFIX->DUKASCOPYFIX] Disconnecting: Encountered END_OF_STREAM"

but sometimes, it gives the message "<20160710-08:06:48, FIX.4.4:FEED_wangqilin2015_DEMOFIX->DUKASCOPYFIX, error> (Disconnecting: Socket exception (demo-api.dukascopy.com/194.8.15.140:9443): org.apache.mina.core.write.WriteToClosedSessionException)"



logon 0|i005tz:
QuickFIX/J QFJ-895

Reconnecting initiator does not work under some circumstances

Bug Closed Major Fixed Guido Medina Christoph John Christoph John 23/Jun/16 06:02   13/Dec/16 22:51 11/Jul/16 14:51 1.6.2 1.6.3     0 5   Youyu Shao provided some fixes on the mailing list.

Original mail:

On 23/06/16 02:35, Youyu Shao wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Recently we have been seriously looking into using QuickFixJ (code base
> 1.6.2).
> In so doing, we have discovered several problems and subsequently resolved
> in house.
>
> 1. Mina would throw org.apache.mina.core.RuntimeIoException wrapping
> java.net.SocketException at various places.
> For example, this happens at:
> org.apache.mina.core.RuntimeIoException: java.net.SocketException:
> Invalid argument: no further information
> at
> org.apache.mina.transport.socket.nio.NioSocketSession$SessionConfigImpl.setTcpNoDelay(NioSocketSession.java:208)
> at quickfix.mina.NetworkingOptions.apply(NetworkingOptions.java:155)
> at
> quickfix.mina.AbstractIoHandler.sessionCreated(AbstractIoHandler.java:93)
> at
> quickfix.mina.initiator.InitiatorIoHandler.sessionCreated(InitiatorIoHandler.java:50)
> .....
> When this happens, exceptionCaught method of AbstractIoHandler is not
> able to properly detect there was an underlying socket IOException.
> AbstractIoHandler has been modified to un-wrap the exception and see if
> along the exception chain there is an IOException.
>
> 2. org.apache.mina.core.session.IoSession internal state is problematic. On
> and off,
> IoSession.isConnected() does not return the correct value after QuickFixJ
> called IoSession.close() method(up on experiencing IOException).
> quickfix.mina.initiator.IoSessionInitiator has been refactored to replace
> the old IoConnector with a new one upon experiencing IOException.
> quickfix.mina.AbstractIoHandler is adjusted accordingly to signal the
> IoSessionInitiator to do so.
>
> 3. Modified the run() method of ConnectTask in IoSessionInitiator to be
> protected by try block. This is to prevent the scheduled Task from
> stop running in presence of exception. (see javadoc on
> scheduleWithFixedDelay(...) method of
> java.util.concurrent.ScheduledExecutorService
> which states that "...If any execution of the task encounters an
> exception, subsequent executions are suppressed...")
>
> 4. Again, org.apache.mina.core.session.IoSession internal state is
> problematic. Even after the
> normal disconnect() from IoSessionResponder, on and off the
> IoSession.isConnected() still does not return the correct value.
> quickfix.mina.IoSessionResponder is adjusted to signal the
> IoSessionInitiator to replace the IoConnector. IoSessionResponderTest is
> adjusted accordingly.
>
>
> 5. quickfix.ThreadedSocketAcceptor leaks resources when stoped.
> Instead of calling stopSessionTimer() in the stop() method, it should
> call stopInitiators().
>
> Problems identified in 1, 2, 3, and 4 ultimately manifested them in ways
> that reconnecting would stop working (forever), even absent of IOExceptions.
>
> With the fix, we have the QuickFixJ engine running for a week where
> reconnecting works with no problem. During this period the counterparty
> logged out and severed the TCP connection more than 20000 times. Our test
> also indicates that the fix works equally SSL vs non-SSL.
>
> Modified files are attached.
>
> AbstractIoHandler.java
> <http://quickfix-j.364392.n2.nabble.com/file/n7579557/AbstractIoHandler.java>
> IoSessionInitiator.java
> <http://quickfix-j.364392.n2.nabble.com/file/n7579557/IoSessionInitiator.java>
> IoSessionResponder.java
> <http://quickfix-j.364392.n2.nabble.com/file/n7579557/IoSessionResponder.java>
> IoSessionResponderTest.java
> <http://quickfix-j.364392.n2.nabble.com/file/n7579557/IoSessionResponderTest.java>
> ThreadedSocketInitiator.java
> <http://quickfix-j.364392.n2.nabble.com/file/n7579557/ThreadedSocketInitiator.java>
>
0|i005tr:
QuickFIX/J QFJ-894

logon state is not valid for message

Bug Closed Default Not a bug Unassigned Ramesh Ramesh 19/May/16 14:00   19/May/16 14:02 19/May/16 14:02         0 2   Hi All,

previously when i try to logon , am getting timed out waiting for logon responce , so i set LogonTimeout=120 in setting file for fixing this issue . but now am getting other issue logon state is not valid for message , is anyone suggest me on this .

(Initiated logon request)
<20160519-11:38:26.401, FIX.4.2:MANAMARBTRPT->REDIRPT, incoming>
(8=FIX.4.29=7135=A49=REDIRPT56=MANAMARBTRPT34=1152=20160519-11:37:4498=0108=3010=014)
single reset topic = ""
<20160519-11:39:06.172, FIX.4.2:MANAMARBTRPT->REDIRPT, incoming>
(8=FIX.4.29=5935=049=REDIRPT56=MANAMARBTRPT34=1252=20160519-11:38:2310=233)
<20160519-11:39:06.172, FIX.4.2:MANAMARBTRPT->REDIRPT, event>
(Logon state is not valid for message)
<20160519-11:39:06.172, FIX.4.2:MANAMARBTRPT->REDIRPT, event>
(Disconnecting)
0|i005tj:
QuickFIX/J QFJ-893

(Invalid message: Expected BodyLength=472, Received BodyLength=478)

Bug Closed Default Not a bug Unassigned Ramesh Ramesh 19/May/16 13:53   19/May/16 13:58 19/May/16 13:58         0 2   Hi All,

I am facing this issue while receiving incoming message , I wasn't have much idea on quickfix , can anyone let your suggestions on this issue , where i have to do changes , in which file i have to do . the incoming message is encapsulated message , i know the reason why we are getting this error , due to encapulation the body length is higher than expecting where i have to fix this issue .
0|i005tb:
QuickFIX/J QFJ-892

Deadlock : quickfix.SessionState.setLastSentTime(SessionState.java:145)

Bug Open Default Unresolved Unassigned Yoni Touitou Yoni Touitou 16/May/16 15:10   13/Apr/17 12:59   1.5.3       0 2   Linux Hi team,

We have an production issue because of deadlock in quickfixj.
I searched in your JIRA and found this ticket : QFJ-645 that is very similar issue but i did not understand the solution.
Can someone advise ?

2016-05-13 13:49:07,162 [FrequentSched-1] ERROR TaUtils detectDeadLocks - DeadLock detected "TA-CRX-JPMC-WL_trading" Id=447 WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@366414ce owned by "TMS2InFCStoneUS_streaming" Id=364
at sun.misc.Unsafe.park(Native Method)
waiting on java.util.concurrent.locks.ReentrantLock$NonfairSync@366414ce
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at quickfix.SessionState.lockSenderMsgSeqNum(SessionState.java:338)
...
2016-05-13 13:49:07,162 [FrequentSched-1] ERROR TaUtils detectDeadLocks - DeadLock detected "TMS2InFCStoneUS_streaming" Id=364 BLOCKED on quickfix.Session@2f7fe578 owned by "TA-CRX-JPMC-WL_trading" Id=447
at quickfix.SessionState.setLastSentTime(SessionState.java:145)
blocked on quickfix.Session@2f7fe578
at quickfix.Session.initializeHeader(Session.java:680)
at quickfix.Session.sendRaw(Session.java:2304)
at quickfix.Session.send(Session.java:2402)
at quickfix.Session.sendToTarget(Session.java:636)
at com.tradair.tnet.driver.fix.client.FixClient.sendRequest(FixClient.java:462)
at com.tradair.tnet.driver.Driver.handleMessages(Driver.java:408)
at com.tradair.tnet.driver.Driver.run(Driver.java:299)
...
deadlock 0|i005t3:
QuickFIX/J QFJ-891

Upload release of BigDecimal versions to Maven or Sonatype central

Improvement Open Default Unresolved Unassigned Igor Nemtsov Igor Nemtsov 16/May/16 15:05   15/Sep/16 09:06   1.6.2       1 2   In repositories of Maven and Sonatype centrals missing BigDecimal versions. 0|i005sv:
QuickFIX/J QFJ-890

PossDupFlag Handlying Config

New Feature Closed Default Not a bug Unassigned Rohit Rohit 09/May/16 16:20   18/May/16 14:46 18/May/16 14:46         0 2   Hi

I am using QuickFixJ 1.6.1 for one of the projects as a FIX initiator.
Currently the default behavior of FIX client is to ignore any messages received with PossDupFlag(tag=43) set to "Y".
Due to which, call back method on fromApp is not invoked .

Is it possible to add a new feature to expose this property as a Config element and have clients override the behavior per their need?
0|i005sn:
QuickFIX/J QFJ-889

Leading zeros in int and float fields

Bug Open Default Unresolved Unassigned Roman Liverovskiy Roman Liverovskiy 23/Apr/16 10:22   28/Apr/16 09:47   1.6.0   Engine   0 2   Fedora 23 x86_64, Windows 7 64 bit SP1 I use quickfixj-examples-executor-1.6.0.jar as FIX 5.0 server.

Server does not respond on any client messages if there are leading zeros in int or float fields in client message, for example if there are leading zeros in sequnce number in message header (in login message or in heart beat message).
Server application outputs information about client conection on socket, but there is no any response on FIX message sent from client to server (there is no even an error message).
Leading zeros are permitted by FIX 5.0 protocol specification.
QuickfixJ 0|i005s7:
QuickFIX/J QFJ-888

DefaultMessageFactory does not support FIX5.0 SP1/2

Bug Open Default Unresolved Christoph John Christoph John Christoph John 21/Apr/16 09:16   29/May/17 07:09     Future Releases     0 1   In DefaultMessageFactory it is assumed that FIX50 is the only version that is used with FIXT. This has historic reasons.

However, we should extend the DefaultMessageFactory to also handle other FIX50-versions out of the box, i.e. SP1 and SP2.
Since this will most probably break backward compatibility, we will do it for version 1.7 only.

Workaround:
Use a custom MessageFactory.
Or add your needed message factory for the FIX50 begin string. For example:

final DefaultMessageFactory defaultMessageFactory = new DefaultMessageFactory();
defaultMessageFactory.addFactory(FixVersions.FIX50, quickfix.fix50sp2.MessageFactory.class);
0|i005rz:
QuickFIX/J QFJ-887

NoPartyIDs Tag 453 error in resend

Bug Closed Minor Not a bug Unassigned Gilberto Gilberto 14/Apr/16 17:43   21/Apr/16 09:13 21/Apr/16 09:13 1.5.0   Build, Message Generation, Networking   0 2   JVM 1.7, Centos 7 I am developing a client using quickfix / j generally works well, but I found a problem with the resend when there is a communication error with the Acceptor.

When sending a message like the following:

FIX.4.4 8 = 9 = 228 35 = D 34 = 463 52 = 49 = INITIATOR 20160405-16: 11: 34,226 ACCEPTOR 56 = 11 = 8746340000000002 21 = 3 22 = 4 38 = 2498 40 = 1 44 = 0 48 = MX01ME050007 54 = 2 59 = 0 60 = 20160315-17: 41: 06,000 432 = 20160315 20001 = 0 453 = 2 448 = 3 447 = D 452 = 24 448 = 0000 447 = D 452 = 12 10 = 255

Where the tag 453 has a value of 2 and their associated tags are:

First group:

448 = 3
447 = D
452 = 24

Second group:

448 = 0000 (eg)
447 = D
452 = 12

When communication is restored, the Acceptor ask for resend the request by , however the resend message looks like this:
FIX.4.4 8 = 9 = 231 35 = D 34 = 428 43 = Y 49 = 52 = ARKA1 20160328-23: 16: 02,215 BMVRII 56 = 122 = 20160328-23: 15: 30 11 = 8746340000000002 21 = 3 22 = 4 38 = 2498 40 = 1 44 = 0 48 = MX01ME050007 54 = 2 59 = 0 60 = 20160315-17: 41: 06,000 432 = 20160315 20001 = 0 453 = 2 448 = 0000 447 = D 452 = 12 10 = 052

The tag 453 still has a value of 2 and the tag 43 appears with "Y" because it is a resend, but only taken considered the second group in the message body, ie 448 = 0000, 447 = D 452 = 12 which invalidates it for processing as the first group is not in the message.

Have any idea what happens in the re-transmission of the message, I appreciate very much your help.
QuickfixJ, ResendRequest,, encoding 0|i005rr:
QuickFIX/J QFJ-886

FIX44.xml InstrumentLeg Inconsistently Defined

Bug Closed Default Fixed Christoph John Mike Starkie Mike Starkie 12/Apr/16 01:03   13/Dec/16 22:51 12/Dec/16 08:15   1.6.3 Message Generation   0 2   Hi,
Looks like the InstrumentLeg Component block is inconsistently defined in FIX44.xml in version 1.6.0

In some places (lines 915-917, msgType=SecurityDefinition) it is defined as :
<group name="NoLegs" required="N">
<component name="InstrumentLeg" required="N"/>
</group>

In other places (lines: 3557-3558, msgType=CollateralInquiry) it is defined like:
<field name="NoLegs" required="N"/>
<component name="InstrumentLeg" required="N"/>

The impact of this is that an XML parser can not correctly parse this component block across all message types.

Regards
0|i005rj:
QuickFIX/J QFJ-885

SocketInitiator::stop() can't send out the logout message

Bug Resolved Major Fixed Christoph John Shen liang Shen liang 07/Apr/16 13:07   12/Apr/17 11:39 12/Apr/17 11:39 1.6.2 1.6.4 Engine   0 3   stop() function will invoke the stop(false) to stop the connection.
In the code, the END_OF_STREAM will be put into the message queue first. So the session will believe the connection is broken. Then the intent "session.logout()" in the logoutAllSessions() will be able to get chance to executed since the session state will be not logon for that END_OF_STREAM message.

eventHandlingStrategy.stopHandlingMessages();
logoutAllSessions(forceDisconnect);
stopInitiators();
0|i005rb:
QuickFIX/J QFJ-884

quickfixj-messages-fix44 is including quickfixj-messages-all

Bug Closed Major Fixed Guido Medina Guido Medina Guido Medina 25/Mar/16 22:22   13/Dec/16 22:51 30/Apr/16 00:31 1.6.2 1.6.3 Engine, Message Generation   0 3   Dependency quickfixj-messages-fix44 is including quickfixj-messages-all, this wasn't like that before so I wonder if the generator was broken during latest commits. QuickfixJ 0|i005r3:
QuickFIX/J QFJ-883

Reject message definition missing from FIX50 package

Other Closed Default Not a bug Unassigned Tamas Tamas 24/Mar/16 02:06   24/Mar/16 09:05 24/Mar/16 09:05 1.5.3, 1.6.0       0 2   If you load only the relevant messages jar (e.g. quickfixj:quickfixj-msg-fix50:1.5.3 or quickfixj:quickfixj-msg-fix50:1.6.0) the Reject message type is not present as a class. However it is present in FIX50.XML.

Is this an oversight? We should not have to load quickfixj-msg-fix44 package or quickfixj-msg-all to get this message type.
0|i005qv:
QuickFIX/J QFJ-882

FIX50.xml / LegSecAltIDGrp incorrect

Bug Closed Default Fixed Christoph John Mike Starkie Mike Starkie 13/Mar/16 23:28   13/Dec/16 22:51 23/Aug/16 12:29 1.6.0 1.6.3 Message Generation   0 2   Hi,
I believe there is an error in FIX50.xml at line 4138 in the components element.

<component name="LegSecAltIDGrp">
<field name="NoLegSecurityAltID" required="N"/>
</component>

In the other xml files, as well as the FIX 4.4 spec, the component is defined as a repeating group. I believe the element should be defined as in the FIX44 xml file as follows:

<component name="LegSecAltIDGrp">
<group name="NoLegSecurityAltID" required="N">
<field name="LegSecurityAltID" required="N"/>
<field name="LegSecurityAltIDSource" required="N"/>
</group>
</component>

I checked the FixRepository.xml file from the FIX consortium and it appears to be ok in the file under FIX 5.0 components section so perhaps it's an issue with the xml generator. Just wanted to bring it to your attention in hopes that fixing this issue may fix other similar issues in the dictionaries that may have resulted from the same condition.

I also posted this to the quickfix-developers group.
0|i005qn:
QuickFIX/J QFJ-881

FieldType.MultipleValueString are not created from FIX5+ xml files

Bug Closed Default Fixed Christoph John exgorth exgorth 12/Mar/16 01:25   23/Sep/16 14:00 17/Mar/16 23:26 1.6.1 1.6.2 Metadata/Specs   0 2   Fields where 'type' attribute has value 'MULTIPLESTRINGVALUE' are referenced in all FIX5+.xml. They cannot be correctly identified when added to DataDictonary because corresponding definition quickfix.FieldType ( quickfix.FieldType#MultipleValueString) expects value 'MULTIPLEVALUESTRING'.

Quick workaround for 1.6.1 is to update values in your xml dictionary, or change type to STRING and validate within app (as suggested elsewhere https://github.com/connamara/quickfixn/issues/66).

Proper fix would probably involve correcting both xml files and quickfix.FieldType to refer to MultipleStringValue constant as defined in the the official fixmlschema doc:
{code}
<xs:simpleType name="MultipleStringValue">
<xs:annotation>
<xs:documentation>string field containing one or more space delimited multiple character values (e.g. |277=AV AN A| ).</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value=".+(\s.+)*"/>
</xs:restriction>
</xs:simpleType>
{code}
I would also suggest an engine to generate a warning (or allow some other strategy) when a DataDictionary parser encounters some 'unexpected' value (instead of just silently assuming type was Unknown)
0|i005qf:
QuickFIX/J QFJ-880

qfj doesn't send the next batch when ResendRequestChunkSize > 0

Other Open Default Unresolved Unassigned Xiaojun Zhang Xiaojun Zhang 26/Feb/16 20:45   01/Sep/16 06:34   1.6.0   Engine   0 3   FIX4.2 Quickfixj seems to send the 1st resend batch only after receiving a seq reset.

i.e.
ResendRequestChunkSize=10

15:28:37.142 [QFJ Message Processor] - fromAdmin PNPBBBN: 8=FIX.4.29=10735=134=44749=CME50=G52=20160225-20:28:37.22356=PNPBBBN57=DROPCOPY143=US,NY369=45621112=IDiky5miuo10=025

15:28:37.142 [QFJ Message Processor] - toAdmin PNPBBBN: 8=FIX.4.29=10735=034=4562249=PNPBBBN50=DropCopy52=20160225-20:28:37.14256=CME57=G142=US,NY143=CME112=IDiky5miuo10=004

I manually reduced the incoming seq no to 428
15:29:07.969 [Thread-30] - command: "fix PNPBBBN 428"

15:29:08.120 [QFJ Message Processor] - toAdmin PNPBBBN: 8=FIX.4.29=10535=234=4562449=PNPBBBN50=DropCopy52=20160225-20:29:08.12056=CME57=G142=US,NY143=CME7=42816=43710=188

15:29:08.148 [QFJ Message Processor] - fromAdmin PNPBBBN: 8=FIX.4.29=13635=434=42843=Y49=CME50=G52=20160225-20:29:08.25556=PNPBBBN57=DROPCOPY122=20160225-20:29:08.255143=US,NY369=4562436=449123=Y10=001

I expect quickfix to send the next batch (438-447) but it sent a normal heartbeat instead.

15:29:38.704 [QFJ Timer] - toAdmin PNPBBBN: 8=FIX.4.29=9235=034=4562549=PNPBBBN50=DropCopy52=20160225-20:29:38.70456=CME57=G142=US,NY143=CME10=069

CME, resend 0|i005q7:
QuickFIX/J QFJ-879

SystemTime currentTimeMillis is synchronized

Bug Closed Default Fixed Guido Medina Guido Medina Guido Medina 26/Feb/16 17:20   21/Apr/16 13:40 08/Mar/16 14:05 1.6.0, 1.6.1 1.6.2 Engine   0 2   The class SystemTime was created to wrap a system time source primarily for unit testing (according to its JavaDocs) but it ended up been used globally so many important classes are obtaining the current time in millis using a synchronized call for no reason.

Can you please check if such thing is needed? If so let me know so that I can send a PR via Git.
0|i005pz:
QuickFIX/J QFJ-878

Publish QuickFIX jars to Maven Central

Improvement Closed Minor Duplicate Unassigned Laplie Anderson Laplie Anderson 22/Feb/16 16:55   22/Feb/16 16:59 22/Feb/16 16:59     Build   0 2   It's industry standard that open source java projects publish their jars to "The Central Repository" (http://search.maven.org). This was brought up in http://www.quickfixj.org/jira/browse/QFJ-123 before the build was completely maven-ized and resolved using a third-party repo.

I see using marketcetera's repo as a workaround. Now that the build is fully built on maven, it should take minimal effort to publish artifacts to maven central.
0|i005pr:
QuickFIX/J QFJ-877

Multiple sessions with same dictionary

Bug Open Default Unresolved Unassigned Mevlüt Saim Doruklu Mevlüt Saim Doruklu 16/Feb/16 15:40   30/Apr/16 01:04           0 2   When multiple sessions are created with the same dictionary name, the last created session sets the value for checkUserDefinedFields in DataDictionary.java. This is because of the dictionary cache using the same object in DefaultSessionFactory. Is this a bug or is it expected behaviour? Dictionary 0|i005pb:
QuickFIX/J QFJ-876

Code Generator creates bad code for nested repeating groups

Bug Closed Major Fixed Scott Harrington Jeff Remillard Jeff Remillard 17/Feb/16 19:55   13/Dec/16 22:51 08/Nov/16 15:25 1.6.1 1.6.3 Build   0 3   When a component is a repeating group and the its first element is also a repeating group, the generated code is invalid. This occurred when using a custom FIX50SP2 dictionary derived from FIX 5.0 SP Expansion Pack 196.

An example is the following definition from the dictionary file:

<component name="PhysicalSettlTermGrp">
<group name="NoPhysicalSettlTerms" required="Y">
<component name="PhysicalSettlDeliverableObligationGrp" required="N"/>
<field name="PhysicalSettlCurrency" required="N"/>
<field name="PhysicalSettlBusinessDays" required="N"/>
<field name="PhysicalSettlMaximumBusinessDays" required="N"/>
<field name="PhysicalSettlTermXID" required="N"/>
</group>
</component>

Where the component PhysicalSettlDeliverableObligationGrp is defined as:

<component name="PhysicalSettlDeliverableObligationGrp">
<group name="NoPhysicalSettlDeliverableObligations" required="Y">
<field name="PhysicalSettlDeliverableObligationType" required="N"/>
<field name="PhysicalSettlDeliverableObligationValue" required="N"/>
</group>
</component>

This generates the source file PhysicalSettlTermGrp.java with the following extract:

public static class NoPhysicalSettlTerms extends Group {

static final long serialVersionUID = 20050617;

public NoPhysicalSettlTerms() {
super(40204, ,
new int[] {40209, 40205, 40206, 40207, 40208, 0 });
}

Looking through the source code, it appears that there may be an issue in codegenerator/Message.xsl where the group-delimiter is generated.

I can email (or upload if possible) the entire dictionary file I'm using. To recreate, replace FIX50SP2.modified.xml file and build.
0|i005pj:
QuickFIX/J QFJ-875

SendingTime accuracy problem

Other Closed Major Cannot Reproduce Unassigned Cedric Zeng Cedric Zeng 16/Feb/16 04:09   23/Aug/16 12:11 23/Aug/16 12:11 1.6.0   Engine   0 3   Use Eclipse to run QuickFIX/J Hi,

I'm running QuickFIX/J for 8 months and still cannot solve this issue.
I run only the initiator and have synchronized time with the third party FIX server.

The problem is that sometimes machine will have a time lag to receive the message. Once the time lag is over 30 seconds, our side will report a "SendingTime accuracy problem" issue to broker and asked log-out.

After I modified the code, the frequency drops a lot. But it still happens one time per day.

Do you have any idea why this problem keeps happening?
1. internet unstable?
We save the price from broker to our server.

---
Here is the sample log

8=FIX.4.3|9=69|35=0|49=BrokerQuote|56=Client123|34=670|57=FX|52=20160215-07:55:34.743|369=5|10=074|
8=FIX.4.3|9=230|35=S|49=BrokerQuote|56=Client123|34=683|57=FX|52=20160215-07:55:35.369|369=5|131=3072|117=Client123-USDSEK-2016-2-15:7.55.35:72-2000000|537=1|55=USD/SEK|460=4|132=8.43613|133=8.43913|134=2000000|135=2000000|60=20160215-07:55:35.369|64=20160217|10=051|
8=FIX.4.3|9=61|35=0|34=6|49=Client123|50=FX|52=20160215-07:55:56.108|56=BrokerQuote|10=190|
8=FIX.4.3|9=229|35=S|49=BrokerQuote|56=Client123|34=684|57=FX|52=20160215-07:55:35.470|369=5|131=3072|117=Client123-GBPUSD-2016-2-15:7.55.35:80-2000000|537=1|55=GBP/USD|460=4|132=1.4515|133=1.45166|134=2000000|135=2000000|60=20160215-07:55:35.470|64=20160217|10=219|
8=FIX.4.3|9=229|35=S|49=BrokerQuote|56=Client123|34=685|57=FX|52=20160215-07:55:35.470|369=5|131=3072|117=Client123-USDRUB-2016-2-15:7.55.35:80-2000000|537=1|55=USD/RUB|460=4|132=77.8389|133=77.934|134=2000000|135=2000000|60=20160215-07:55:35.470|64=20160216|10=028|
8=FIX.4.3|9=69|35=0|49=BrokerQuote|56=Client123|34=686|57=FX|52=20160215-07:55:35.619|369=5|10=084|
8=FIX.4.3|9=229|35=S|49=BrokerQuote|56=Client123|34=687|57=FX|52=20160215-07:55:35.696|369=5|131=3072|117=Client123-USDPLN-2016-2-15:7.55.35:98-2000000|537=1|55=USD/PLN|460=4|132=3.9205|133=3.92347|134=2000000|135=2000000|60=20160215-07:55:35.696|64=20160217|10=037|
8=FIX.4.3|9=113|35=3|34=7|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|45=684|58=SendingTime accuracy problem|372=S|373=10|10=033|
8=FIX.4.3|9=61|35=5|34=8|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|10=198|
8=FIX.4.3|9=113|35=3|34=9|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|45=685|58=SendingTime accuracy problem|372=S|373=10|10=036|
8=FIX.4.3|9=62|35=5|34=10|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|10=240|
8=FIX.4.3|9=114|35=3|34=11|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|45=686|58=SendingTime accuracy problem|372=0|373=10|10=044|
8=FIX.4.3|9=62|35=5|34=12|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|10=242|
8=FIX.4.3|9=114|35=3|34=13|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|45=687|58=SendingTime accuracy problem|372=S|373=10|10=082|
8=FIX.4.3|9=62|35=5|34=14|49=Client123|50=FX|52=20160215-07:56:07.607|56=BrokerQuote|10=244|
QuickfixJ 0|i005p3:
QuickFIX/J QFJ-874

Session Qualifier for acceptor sessions

Improvement Open Default Unresolved Unassigned Kou Jun Kou Jun 07/Jan/16 12:49   03/Apr/16 16:16   1.2.1       0 3   Hello,

i think, it would be a good idear, to have a session qualifier for acceptor sessions (ConnectionType=acceptor).
If you try to configure two acceptors in separate configuration files (Same fix-version, SenderCompId, TargetCompID) and the only difference is the port number, the configuration will not work if the Message store is in the same directory. They will both use the same message and eventlog files.

Regards
Thomas Hügel
0|hzzzzz:
QuickFIX/J QFJ-873

Support processing higher resolution timestamps

New Feature Resolved Major Fixed Christoph John Christoph John Christoph John 04/Jan/16 10:22   23/May/17 13:26 23/May/17 13:22   1.7.0 Engine, Message Generation, Metadata/Specs   1 2   h3. mail on quickfixj-users mailing list

{quote}
-------- Forwarded Message --------
Subject: [Quickfixj-users] QuickFIX/J time precisions
Date: Mon, 4 Jan 2016 09:16:55 +0000
From: Yuval Cohen <yuval.cohen@etradingsoftware.com>
Reply-To: quickfixj-users@lists.sourceforge.net
To: quickfixj-users@lists.sourceforge.net <quickfixj-users@lists.sourceforge.net>


QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



FIX Standards have recently proposed changes, that require some code change in QuickFix/J.
Specifically, FIX introduced a change to the time precision to support microseconds and higher resolution timestamp.
A gap analysis made by FIX can be found by following the links in: http://www.fixtradingcommunity.org/pg/discussions/topicpost/2893609/
Please fill free to contact me directly if you need any clarifications about the new standards.

I would appreciate if anyone who is working to make the required changes will please contact me.

Kind Regards
Yuval Cohen

Etrading Software Ltd
City Tower
40 Basinghall street
London EC2V 5DE

Tel: 020 3770 5808
Mobile: 07889 176368
SkypeMe: yuval_cohen.laptop
{quote}

h3. considerations
* Is this really required? One could argue that for normal trading applications millisecond granularity is sufficient. Probably no-one is using QFJ for high-frequency trading (which would require at least microsecond granularity).
* To accept timestamps with higher granularity the probably easiest thing to do is to alter the fields in the data dictionary from UTCTIMESTAMP to STRING. That way the messages would get accepted and users could parse the fields by themselves.
** However, a more sophisticated solution would be preferred.
* Supporting timestamps up to nanosecond precision could be implemented with reasonable effort. However, it might be required to use JDK 8 for this since nanosecond support is better.
* Picosecond granularity is totally out of scope and is also discouraged by FPL.
* We need a configuration option to decide which precision we want to send since not all counterparties might be able to deal with it, e.g. some destinations might only be ready to receive microseconds but not nanoseconds timestamps.


Also see QFJ-921 which will merely deal with accepting messages with timestamps in microseconds or nanoseconds but not with processing them.

h3. implementation

* added support for sending/processing UtcTimestamps with up to nanosecond precision
* added config TimeStampPrecision (used for (Orig)SendingTime)which can take a value of SECONDS, MILLIS, MICROS or NANOS.
* instead of java.util.Date we will now use java.time.LocalDate/Time classes
* extended/adapted unit tests
* extended converters
* added new fields UtcTimeField and UtcDateField
0|i00007:
QuickFIX/J QFJ-872

toString() Method Breaks Repeating Groups

Bug Closed Critical Not a bug Christoph John Mike Starkie Mike Starkie 23/Dec/15 02:49   23/Dec/15 23:51 23/Dec/15 23:50 1.6.0   Build   0 2   OS X 10.11.2
jdk1.8.0_65
Given a valid FIX 4.4 Execution Report FIX string containing a repeating group passed as the single argument to the constructor of the Message type, immediately calling the toString() method on the new instance results in the repeating group being mangled.

Below is the output of the sample program which demonstrates the bug. The first message has field 382[NoContraBrokers] in the correct place at the start of ContraGrp. The toString result has field 375[ContraBroker] coming before 382 which is incorrectly placed outside the group.

Fix String before creating Message instance:
8=FIX.4.4|9=173|35=8|34=3|49=BRKR|52=20121105-23:24:42|56=BANZAI|6=0|11=1352157882577|14=0|17=1|20=0|31=0|32=0|37=1|38=10000|39=0|54=1|55=MSFT|150=2|151=0|382=1|375=1|655=2|437=444|438=888|10=111|

Fix String after calling toString() on the new instance of Message:
8=FIX.4.4|9=173|35=8|34=3|49=BRKR|52=20121105-23:24:42|56=BANZAI|6=0|11=1352157882577|14=0|17=1|20=0|31=0|32=0|37=1|38=10000|39=0|54=1|55=MSFT|150=2|151=0|375=1|382=1|437=444|438=888|655=2|10=111|

----------------------- Sample Code -------------------------

package com.globalforge.infix;

import quickfix.InvalidMessage;
import quickfix.Message;

public class QuickFixGroupTest {
static String FIX_44_EXEC_REPORT =
"8=FIX.4.49=17335=834=349=BRKR52=20121105-23:24:4256=BANZAI6=011=135215788257714=017=120=031=032=037=138=1000039=054=155=MSFT150=2151=0382=1375=1655=2437=444438=88810=111";

public static String rs(String ins) {
return ins.replaceAll("\u0001", "|");
}

public static void main(String[] args) {
System.out.println("before: " + rs(FIX_44_EXEC_REPORT));
try {
Message quickFixMsg = new Message(FIX_44_EXEC_REPORT);
System.out.println("after : " + rs(quickFixMsg.toString()));
} catch (InvalidMessage e) {
e.printStackTrace();
}
}
}
QuickfixJ 0|i0000f:
QuickFIX/J QFJ-871

Print address for unsuccessful connection attempts

Improvement Closed Default Fixed Christoph John Kou Jun Kou Jun 03/Dec/15 14:19   21/Apr/16 13:40 23/Dec/15 00:23 1.6.1 1.6.2 Networking   0 2   If fail-over case, I config like below
SocketConnectHost=host1
SocketConnectPort=1111
SocketConnectHost1=host2
SocketConnectPort1=1111
,if the two accepter are not exist,the log will be like as below,

20151203-21:17:14.014 ERROR [QFJ Timer] errorEvent - FIX.4.2:XXX->YYY: java.net.ConnectException: java.net.ConnectException: Connection refused: no further information (Next retry in 15000 milliseconds)
20151203-21:17:29.037 ERROR [QFJ Timer] errorEvent - FIX.4.2:XXX->YYY: java.net.ConnectException: java.net.ConnectException: Connection refused: no further information (Next retry in 15000 milliseconds)
20151203-21:17:44.048 ERROR [QFJ Timer] errorEvent - FIX.4.2:XXX->YYY: java.net.ConnectException: java.net.ConnectException: Connection refused: no further information (Next retry in 15000 milliseconds)
20151203-21:17:59.065 ERROR [QFJ Timer] errorEvent - FIX.4.2:XXX->YYY: java.net.ConnectException: java.net.ConnectException: Connection refused: no further information (Next retry in 15000 milliseconds)

I could'nt know this connection is connect to which host and port is failed,
if print out the host and port,will be very useful!
0|i0000n:
QuickFIX/J QFJ-870

Don't Know Trade <Q> message

New Feature Closed Critical Not a bug Unassigned Anuradha Anuradha 20/Nov/15 06:37   20/Nov/15 10:18 20/Nov/15 07:47     Message Generation   0 3   Windows7(OS),QFJ(FIXimulator_0.41) and Client(initiator) in C#.net
Hardware 4GB ram
Hello,

As per my understanding, Don't Know Trade(Q) is the message which will be received to client from server end when a trade is rejected.

Can you please let me know whether my understanding is correct, if not please correct me.

I would like to know a sample Don't Know Trade(Q) generation messages.

Appreciate your response.

Thanks & Regards,
Anuradha
Message 0|i0000v:
QuickFIX/J QFJ-869

Getting Configuration Failed Error: Could not open body file while client (initiator) trying to logon after logout

Bug Closed Default Cannot Reproduce Unassigned parashuram parashuram 15/Nov/15 16:13   16/Nov/15 10:07 16/Nov/15 10:07     Engine   0 2   Windows7(OS),QFJ(FIXimulator_0.41) and Client(initiator) in C#.net
Hardware 4GB ram
Getting Configuration Failed Error: Could not open body file while client (initiator) trying to logon after logout

shows the error message as below:
Configuration failed: Could not open body file: c:\fixfiles\FIX.4.2-BANZAI-FIXIMULATOR.body

here c:\fixfiles\ path is take as FileStorePath where the FIX.4.2-BANZAI-FIXIMULATOR.body,FIX.4.2-BANZAI-FIXIMULATOR.header,FIX.4.2-BANZAI-FIXIMULATOR.seqnums,FIX.4.2-BANZAI-FIXIMULATOR.session file were stored.

But I couldn't figure out why initiator is showing this error message while trying for next logon after logout. I am thankful for any help on this issue.

Thanks & regads
Parashuram M
Reconnect, logon, session, settings 0|i00013:
QuickFIX/J QFJ-868

IoSessionInitiator can't reconnect the disconnected session

Bug Closed Critical Duplicate Guido Medina Shen liang Shen liang 13/Nov/15 03:18   17/Aug/16 07:00 17/Aug/16 07:00 1.6.1 1.6.3 Networking   3 7   The reconnection has a check shouldReconnect(). The function rely on the flag "!ioSession.isConnected()". But when the Session object disconnect its connection by

responder.disconnect();
setResponder(null);

The disconnect() itself will cause the close future set "closing = true". So there is a gap. Session object believe its connection is closed. While because of some reason the close isn't done, just be marked. So the background reconnection process will be fooled and won't be able to rebuild the connection. The Session timeout check routine will also just skip check since its responder is null by this check

// Return if we are not connected
if (!hasResponder()) {
return;
}

The effect is the connection won't be back after the following exception log

Disconnecting: Socket exception : java.io.IOException: Connection reset by peer
QuickfixJ, Reconnect, session 0|i0001b:
QuickFIX/J QFJ-867

Thread handling after exiting QuickFIX

Bug Open Default Unresolved Unassigned Martin Vrábel Martin Vrábel 06/Nov/15 12:46   16/Nov/15 13:24   1.6.1   Engine   0 2   Apache Tomcat 8 on Windows 10, Spring 4 web application Hi,

I stumbling over this thing over and over. When I stop my application I always get error messages in output about spawning a new thread during execution of application but failing to remove it when application stops:

```
06-Nov-2015 12:29:26.653 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@7f03e077]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@6b6c6237]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@2aca975d]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.654 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@2bebb3b3]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
06-Nov-2015 12:29:26.655 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@682d21a6]) and a value of type [quickfix.field.converter.UtcTimestampConverter] (value [quickfix.field.converter.UtcTimestampConverter@4b8bfee1]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
```

It has something to do with `UtcTimestampConverter` but I have no idea why is it happening. I correctly shutdown all threads I manually start.
QuickfixJ 0|i0001j:
QuickFIX/J QFJ-866

Initiator session timer with SSL enabled

Bug Closed Default Fixed Guido Medina Guido Medina Guido Medina 02/Nov/15 11:53   23/Jun/16 06:09 23/Dec/15 00:28 1.6.0, 1.6.1 1.6.2 Engine   0 2   Debian 7 It seems to be an issue where the weekly session for a QuickFixJ initiator is not starting properly, I have several connections as initiator with no SSL and they all start find, I disconnect my sessions every Friday at 22:00 and start them again every Sunday at 21:00, all of them show the "Session not current" message (a) in the log and all of them except the one with SSL show later the log information about the session being started (b)

Sample logs:
a) 01-11-15 21:00:00 INFO q.event - FIX.4.4:...->...: Session state is not current; resetting FIX.4.4:01-11-15 21:00:00 INFO q.event - ...->...: Session state is not current; resetting FIX.4.4:...->...->...
b) 01-11-15 21:00:00 INFO q.m.i.InitiatorIoHandler - MINA session created for ...->...: local=/...:..., class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/...:...

Log B is not happening for the connection with SSL so I'm not sure what's going on with the connection, it seems that for weekly sessions the SSL connection is not closing correctly making the timer hit a sort of a lock where it cannot get out? no other error is reporting.

Usually when a connection is down for a network issue it is retried except for this particular case of weekly reconnection.
0|i0001z:
QuickFIX/J QFJ-863

In the quickfix version that we use (1.5.3b), an invalid checksum error does not result in a session reject

Bug Open Default Unresolved Unassigned Saurabh Desai Saurabh Desai 12/Oct/15 08:50   12/Oct/15 11:22   1.5.3   Engine   0 2   The scenario:

The initiator parses the following message with quickfix.MessageUtils.parse(), and sends it to the acceptor.

8=FIX.4.4|9=238|35=AE|31=1.35|32=1000|48=EURUSD|22=6|55=EURUSD|64=20131106|194=1.35|15011=1.33|15012=1.33|461=RCSXXX|487=2|571=1105200000001234|829=0|572=M1006050412587|552=1|54=1|37=SYS1:4545556002|11=SYS2:1006050412587|526=SSP:BDID001|453=2|448=a123456|447=D|452=3|802=2|523=5730607|803=10|523=5730606|803=15|1=123456-789|

It is not a valid FIX message, as we have 453<NoPartyIDs>=2, but there is only one group in the message. We would expect the acceptor to return a validation error, but instead the following happens:

1) An error message is logged:

2013-12-07 15:47:30,919 [SocketAcceptorIoProcessor-0.0] ERROR [] q.mina.acceptor.AcceptorIoHandler - Invalid message: Expected CheckSum=29, Received CheckSum=28 in 8=FIX.4.4?9=367?35=AE?34=82?49=SIDE1?52=20131207-14:47:30.618?56=SIDE2?22=6?31=1.35?32=1000?48=EURUSD?55=EURUSD?64=20131106?194=1.35?461=RCSXXX?487=2?571=1105200000001234?572=M1006050412587?829=0?15011=1.33?15012=1.33?552=1?54=1?37=SYS1:4545556002?11=SYS2:1006050412587?526=SSP:BDID001?453=2?448=a123456?447=D?452=3?802=2?523=5730607?803=10?523=5730606?803=15?1=123456-789?10=028?

2) The acceptor does not send any response and does not increase the message sequence count, either.

The suspect:

The acceptor validates the fix message with the checksum(String s) method of Message class. It calculates 29. But the checksum calculated on the initiator side is 28. The initiator calculates the checksum with a different method, which is called by the toString() method of Message class. This is the method which does the calculation (in FieldMap class) - my comments added:

int calculateTotal() {

int result = 0;
// JK: fields variable contains tags which are not group tags
for (final Field<?> field2 : fields.values()) {
final Field<?> field = field2;
if (field.getField() == CheckSum.FIELD || isGroupField(field.getField())) {
continue;
}
result += field.getTotal();
}

// JK: groups variable contains the group tags, but only the tag number (the key is Integer, not Field - why?)
final Iterator<Map.Entry<Integer, List<Group>>> iterator = groups.entrySet().iterator();
while (iterator.hasNext()) {
final Map.Entry<Integer, List<Group>> entry = iterator.next();
final List<Group> groupList = entry.getValue();
if (!groupList.isEmpty()) {
final IntField groupField = new IntField((entry.getKey()).intValue());
// JK: at this point we have 453=0, as this is a new field, no value yet
groupField.setValue(groupList.size());
// JK: now it is 453=1, because we have only one group
result += groupField.getTotal();
for (int i = 0; i < groupList.size(); i++) {
final Group group = groupList.get(i);
result += group.calculateTotal();
}
}
}

return result;
}

So the checksum will be the checksum of a different message actually, where 453=1.
0|i00027:
QuickFIX/J QFJ-862

java.lang.RuntimeException: java.io.IOException: The filename, directory name, or volume label syntax is incorrect

Bug Closed Default Not a bug Unassigned gaviya gaviya 07/Oct/15 16:07   07/Oct/15 16:19 07/Oct/15 16:19         0 3   I am trying to import a fix message of type ExecutionReport Fix 4.2 and i get the error as "java.lang.RuntimeException: java.io.IOException: The filename, directory name, or volume label syntax is incorrect".
My session id is something like this( FIX.4.2:CXX/G->OXXXXXX/CME_NXXXXXXX)
The error is thrown at invoker.Invoke(message, sessionID); in the MessageCracker class.
0|i0002f:
QuickFIX/J QFJ-861

OutOfMemoryError with using DefaultMessageFactory and quickfixj-all-1.6.1.jar

Bug Closed Major Not a bug Unassigned Frantisek Hradil Frantisek Hradil 23/Sep/15 13:50   22/Dec/15 22:53 22/Dec/15 22:53 1.6.1       0 2   Hi,
after upgrade from 1.5.3 to 1.6.1 I got "OutOfMemoryError". I'm using "quickfixj-all-1.6.1.jar". Problem is that "quickfix.DefaultMessageFactory" trying to add all factories (fix40,fix41,..fix50sp2). Problem is during adding "fix50sp2".

I had to use "quickfixj-all-1.6.1.jar" instead of "quickfixj-core-1.6.1.jar" + "quickfixj-messages-fix44-1.6.1.jar" because of issue "QFJ-845".

Please, could you look at it? Is there a plan for release a new quickfixj version?

Thank you.


Error replication:
MessageFactory mf = new DefaultMessageFactory();

More exception details:
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at quickfix.DefaultMessageFactory.addFactory(DefaultMessageFactory.java:85)
at quickfix.DefaultMessageFactory.addFactory(DefaultMessageFactory.java:60)
at quickfix.DefaultMessageFactory.<init>(DefaultMessageFactory.java:54)
0|i0002v:
QuickFIX/J QFJ-860

Support newest EP (expansion pack) for FIX5.0SP2

Improvement Open Default Unresolved Unassigned John Khouri John Khouri 20/Aug/15 13:12   26/Aug/15 17:14   1.6.0   Message Generation   0 2   Java Some new messages were added in the EPs. E.g. PartyDetailsListRequest (35=CF). generation 0|i00033:
QuickFIX/J QFJ-859

Performance and latency improvements

Improvement Open Default Unresolved Christoph John Christoph John Christoph John 17/Aug/15 14:01   17/Aug/15 14:03     1.7.0 Engine   0 3   Charles Briquel submitted some performance related pull requests which should be integrated into the next version.

https://github.com/quickfix-j/quickfixj/pull/32
https://github.com/quickfix-j/quickfixj/pull/34
https://github.com/quickfix-j/quickfixj/pull/35
https://github.com/quickfix-j/quickfixj/pull/36
https://github.com/quickfix-j/quickfixj/pull/37
https://github.com/quickfix-j/quickfixj/pull/39
https://github.com/quickfix-j/quickfixj/pull/40
https://github.com/quickfix-j/quickfixj/pull/41
https://github.com/quickfix-j/quickfixj/pull/42
0|i0003b:
QuickFIX/J QFJ-858

logon problem with FIX41

Bug Closed Critical Duplicate Unassigned Praveen Praveen 05/Aug/15 14:43   10/Aug/15 22:21 10/Aug/15 22:21 1.6.0   Engine   0 4   3.0.80-0.7-default #1 SMP Tue Jun 25 18:32:49 UTC 2013 (25740f8) x86_64 x86_64 x86_64 GNU/Linux While starting engine in initator mode with FIX41 session configured , following error is received and engine fail to stablish FIX connection

Following is logs with excepiton
INFO: MINA session created for FIX.4.1:BLPFE->DSLFE: local=/10.245.150.28:56536, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=tokeqappu71/10.245.150.27:10000
Aug 5, 2015 9:27:18 PM quickfix.mina.SessionConnector$SessionTimerTask run
SEVERE: Error during timer processing
java.lang.VerifyError: (class: quickfix/fix41/Logon, method: set signature: (Lquickfix/field/ResetSeqNumFlag;)V) Incompatible argument to function
at quickfix.fix41.MessageFactory.create(MessageFactory.java:35)
at quickfix.DefaultMessageFactory.create(DefaultMessageFactory.java:133)
at quickfix.Session.generateLogon(Session.java:1872)
at quickfix.Session.next(Session.java:1799)
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:278)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)

Attached is config i am using
0|i0003j:
QuickFIX/J QFJ-857

quickfix.FieldNotFound: 555, index=1 while using TradeCaptureReport.fromString(fixMsg, dd, true)

Bug Closed Blocker Not a bug Unassigned balakrishna balakrishna 04/Aug/15 14:21   04/Aug/15 16:19 04/Aug/15 16:19         0 2   We are developing an utility which will take fix message string as input to the MessageUtils.parse method to create a TradeCaptureReport Object. This object intern pass it to the downstream to process further to create a Deal in our system.
Using below code, we are now able to process the fix messages for Normal Deals but the same is failing to process spread deals with the following error. while executing the
*message.getGroup(i, nolegs)* on TradeCaptureReport Object

*quickfix.FieldNotFound: 555, index=1*
but the 555 has two legs in the fix message below.

Java Code: We tried with the 2 methods the results into the same error.
1)message = (TradeCaptureReport)MessageUtils.parse(new quickfix.fix44.MessageFactory(), dd, fixMsg);
2) fixMsg is my String contains the below fix message.
TradeCaptureReport message = new TradeCaptureReport();
message.fromString(fixMsg, dd, true);

Error is coming because message.frromString()// method is not populating the group by filed map for 555 though it present in the

Fix messages:
8=FIX.4.49=94635=AE49=ICE34=352=20150804-07:38:17.86156=1574657=26571=180487=0856=0568=474be469-5eab-4207-845a-9cfa4f88f6e9828=017=500013139=2570=N55=14209048=GWM FMX0015-GWM FMZ001522=8461=FXXXXX207=IFEU9064=0916=20151101917=2015123132=531=-1.3309018=59022=3075=2015080460=20150804-07:37:10.1439413=0762=999028=666003552=154=237=500012711=707335134453=6448=tpoint_gui1447=D452=11448=Triple Point Technology, Inc.447=D452=13448=15577447=D452=56448=15577447=D452=35448=U447=D452=54448=144447=D452=55*555=2600=141989602=GWM FMX0015!603=8608=FXXXXX616=IFEU624=2637=46.570687=5654=50001329019=59023=309020=201511019021=20151130539=3524=U525=D538=54524=144525=D538=55524=15577525=D538=35600=141975602=GWM FMZ0015!603=8608=FXXXXX616=IFEU624=1637=47.900687=5654=50001339019=59023=319020=201512019021=20151231539=3524=U525=D538=54524=144525=D538=55524=15577525=D538=35*10=250
QuickfixJ 0|i0003r:
QuickFIX/J QFJ-856

Error Recieved Msg

Bug Closed Critical Not a bug Unassigned IJDAD Younes IJDAD Younes 31/Jul/15 18:08   31/Jul/15 18:16 31/Jul/15 18:16 1.6.0, 1.6.1   Message Generation   0 3   Hello,
I have a problem with receiving messages from our server FIX,

please find below the traceability of requests sent / received.

Thanks for your help.

<20150731-16:08:27, FIXT.1.1:YOUN->IJD, outgoing> (8=FIXT.1.19=12935=D34=90849=YOUN52=20150731-16:08:27.96856=IJD11=6098538=10040=244=5154=155=ADH59=060=20150731-16:08:27.967581=110=063)
<20150731-16:08:28, FIXT.1.1:YOUN->IJD, incoming> (8=FIXT.1.19=32235=849=IJD56=YOUN34=78152=20150731-16:06:23.6541128=917=E0NpIbOJ4ohk11=60985278=O0NpIgELeV8O37=O0NpIgELeV8O442=1150=039=0151=10014=055=ADH453=3448=YOUN447=D452=53448=MCP447=D452=1448=MaroClear447=D452=8340=259=054=138=1001138=10044=51528=A60=20150731-16:06:23.6511180=130001=1581=110=224)
<20150731-16:08:28, FIXT.1.1:YOUN->IJD, error> (Rejecting invalid message: quickfix.FieldException: Tag not defined for this message type, field=278: 8=FIXT.1.19=32235=834=78149=IJD52=20150731-16:06:23.65456=YOUN1128=911=6098514=017=E0NpIbOJ4ohk37=O0NpIgELeV8O38=10039=040=244=5154=155=ADH59=060=20150731-16:06:23.651150=0151=100278=O0NpIgELeV8O442=1528=A581=11138=1001180=130001=1453=3448=YOUN447=D452=53448=MCP447=D452=1448=MaroClear447=D452=8310=224)
<20150731-16:08:28, FIXT.1.1:YOUN->IJD, error> (Reject sent for Message 781: Tag not defined for this message type:278)
QuickfixJ 0|i0003z:
QuickFIX/J QFJ-855

Change packaging strategy for quickfixj-messages-fix[40|41|42|43|44|50|50sp1|50sp2|t11] modules to prevent VerifyError

Bug Closed Default Fixed ManuReno ManuReno ManuReno 17/Jul/15 15:20   21/Apr/16 13:40 22/Mar/16 17:51 1.6.0 1.6.2     2 7   Classes generated & compiled from single FIXxx dictionaries may conflict with classes used to compile the core module resulting in VerifyError at runtime.

The aim of this ticket is to package the quickfixj-messages-fix99 jars out of the messages-all compilation result to ensure the same .class files are used between all modules.
This should allow to use these jars without facing VerifyError with the following limitations :
* The new jar will be different from what could be obtained by generating out of a single dictionary
* The **/field/** package contain the fields from all the fix dictionaries documented in QuickFixJ

This packaging strategy is a bit unusual and has some limitations but may temporary solve the VerifyError issue for someone who doesn't want to use the messages-all jar.
0|i00047:
QuickFIX/J QFJ-854

Race discovered in SingleThreadedEventHandlingStrategyTest

Bug Closed Default Fixed Marcin L Nathan Tippy Nathan Tippy 09/Jul/15 16:24   21/Apr/16 13:40 23/Dec/15 00:32 1.6.0 1.6.2 Engine   1 5   I have run into a problem with the unit tests on my quad core haswell i7. It looks like a race condition.

Failed tests:
SingleThreadedEventHandlingStrategyTest.testDoubleStart:55->checkThreads:94 Exactly one 'QFJ Message Processor' thread expected expected:<1> but was:<2>

Tests run: 1294, Failures: 1, Errors: 0, Skipped: 0

I can fix the problem by adding this sleep on line 54 of SingleThreadedEventHandlingStrategyTest. However this is not the right solution but it works.

ehs.blockInThread();
Thread.sleep(200); //need delay
ehs.blockInThread();
checkThreads(bean);
0|i0004f:
QuickFIX/J QFJ-853

Add ability to modify the Proxool JDBC connection pool via session settings

New Feature Closed Minor Fixed Jose Elias Chavez Jose Elias Chavez Jose Elias Chavez 06/Jul/15 20:26   13/Dec/16 22:51 23/Aug/16 10:51   1.6.3 Engine   0 2   In file JdbcUtil.java, the proxool data source is created using hard coded settings. There is even a TODO comment for making these configurable.

It would be good if these hard coded settings could be configurable via the settings file.
jdbc, settings 0|i0004n:
QuickFIX/J QFJ-852

Missing synchronized blocks discovered in code review.

Bug Open Default Unresolved Unassigned Nathan Tippy Nathan Tippy 01/Jul/15 19:13   04/Jul/15 06:06   1.6.0   Engine   0 2   In the class Session in the following method

private boolean verify(Message msg, boolean checkTooHigh, boolean checkTooLow)

we find that synchronized (state.getLock()) is used to ensure atomic updates to the multiple fields in the state object. If this is needed then we must also check to ensure partial or dirty reads are avoided. This would happen any place that we call for more than one field of the state and assume the fields remain consistent with one another until we make a second or third request for other fields.

Directly after this same block the usage of isChunkedResendRequest, getCurrentEndSeqNo and getEndSeqNo run the risk of partial (dirty) reads because they are out side the sync.

This same problem also exists here where it may be the cause of other more serious issues.
private void nextSequenceReset(Message sequenceReset)

And to a a lesser degree in
private void doTargetTooHigh(Message msg)


sequnece 0|i0004v:
QuickFIX/J QFJ-851

Include proxool-cglib in the lib/ folder of the binary (.zip) distribution

Improvement Closed Default Fixed Christoph John Attila-Mihaly Balazs Attila-Mihaly Balazs 30/Jun/15 05:41   13/Dec/16 22:51 23/Aug/16 11:57 1.6.0 1.6.3     0 2   proxool-cglib-0.9.1.jar is needed by proxool-0.9.1.jar (which is already included) - otherwise the later throws ClassDefNotFound errors (for example when tryint to use JdbcStoreFactory).

PS. This wouldn't be a problem if QF/J would be available on Maven since the dependency would be transparently pulled in :-)
0|i00053:
QuickFIX/J QFJ-850

QuickFix/J stop to reconnect

Bug Closed Blocker Duplicate Unassigned Andrei Marchanka Andrei Marchanka 11/Jun/15 10:36   27/Nov/15 09:07 27/Nov/15 09:07 1.6.0   Engine   1 4   Ubuntu Linux With SSL filter quickfix stop to reconect after IOException.
100% case is using tcpkill. Just kill connection and initiator won't try to reconnect.
NioSocketSession has closing == true and DefaultCloseFuture has ready == false.
QuickfixJ 0|i0005b:
QuickFIX/J QFJ-849

SocketInitiator does not stop properly

Bug Closed Critical Fixed Christoph John Or Ming Chun Or Ming Chun 10/Jun/15 16:19   21/Apr/16 13:40 22/Mar/16 18:13 1.6.0 1.6.2 Engine   4 8   Tested on Mac & Ubuntu When creating a simple Quickfixj Initiator app and after the session has successfully been created and Logon, I called initiator.stop() and exit the program. But the JVM hang and cannot exit after ~60s QuickfixJ, session 0|i0005j:
QuickFIX/J QFJ-848

Not able to connect to fix5.0sp2 server

Bug Closed Blocker Not a bug Unassigned arvind patil arvind patil 29/May/15 06:22   29/May/15 07:45 29/May/15 07:45         0 2   0|i0006f:
QuickFIX/J QFJ-847

Transport Data Dict vs App Data Dict - settings not passed to App Data Dict

Bug Open Default Unresolved Unassigned Chris Chris 19/May/15 15:24   19/May/15 15:25   1.6.0   Engine   0 2   N/a its in the java code The Quickfixj settings are not being passed to the ApplicationDataDictionary.

This seems to be because the transport dictionary is created via
DefaultSessionFactory.createDataDictionary.

Whereas the app DataDictionary is created in Default Data Dictionary
Provider, which does not seem to know about settings and so cannot pass them on.


0|i0006n:
QuickFIX/J QFJ-846

Upload release to Maven or Sonatype central

Improvement Closed Default Fixed Luca Burgazzoli Christoph John Christoph John 15/May/15 22:57   05/Jul/16 16:35 24/Mar/16 16:21 1.6.0 1.6.2     3 6   0|i00073:
QuickFIX/J QFJ-845

Change packaging strategy of quickfixj-messages-all to prevent VerifyError

Bug Closed Major Fixed ManuReno ManuReno ManuReno 14/May/15 17:06   10/Aug/15 22:21 20/Jul/15 17:39 1.6.0 1.6.1 Build   4 6   In version 1.6.0, the message-all jar is made by merging the jar each individual FIX version.
An issue arises since the type of some fields may be change between FIX versions.

For instance, the field 43 ("PossDupFlag") is a String from Fix 4.0 to Fix 4.2 and becomes a Boolean in FIX 4.3.
So classes from the jar messages-fix42 and below expect to see a StringField for field 43, whereas classes from messages-fix43 and over expect a BooleanField.
When jars are merged, only one version of the PossDupFlag is kept, resulting in a VerifyError either in fix42 and below or fix43 and over classes (depending on whioch version of PossDup has been kept).
This also happens on several other fields.

This ticket aims at changing the packaging strategy by first merging the generated source code from all FIX specs, and then compiling instead of merging classes compiled individually for each FIX spec.
The new message-all is then consistent and compatible with the quickfixj-core module which uses the same approach.

An issue remains though as only one single version of the fields that change type (field 43 for example) is compiled.
By default, the most recent version of the field is kept
It seems that this conflict was handled the same before, it thus must not be that a big issue (to be confirmed)
0|i0007b:
QuickFIX/J QFJ-844

Upgrade maven-compiler plugin and add more memory to the compiler

Other Closed Minor Fixed ManuReno ManuReno ManuReno 11/May/15 21:15   21/Jul/15 15:02 14/May/15 00:37   1.6.1 Build   0 2   apache-maven-3.2.2 jdk1.7.0_65 windows7 quickfixj-core module compilation run out of memory and doesn't complete on my environment.
Adding more memory to the compiler at th pom level seems to solve the issue :

<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<fork>true</fork>
<meminitial>128m</meminitial>
<maxmem>512m</maxmem>
<source>${jdkLevel}</source>
<target>${jdkLevel}</target>
</configuration>
</plugin>

0|i0007j:
QuickFIX/J QFJ-843

Some times QuickFix Message received on Fix session is processed first by Application thread and later by socket connection Processor Thread causing sequence error by later processing

Bug Open Default Unresolved Unassigned anurag jain anurag jain 04/May/15 05:42   07/May/15 10:17   1.5.3   Engine   0 2   Message on Fix session received by both Application thread (ProcessQ) and socket connection Processor Thread.
In below example Our Application Thread ProcessQ got the message with 34=158757 and later quickfix thread ScoketConnectionProcessor-0.0 Thread process the same message this happen only 4 time in a whole day.
But Due to this when quickfix's socketConnectionThread thread process the message and give it to QFJMessageProcessor thread to process further it encounters sequence rest error as a result session logged out triggers. In all the other scenarios ScoketConnectionProcessor process the message first and delegate the responsibility to QFJ Message Processor thread and later to application Thread i.e. ProcessQ

Please FInd application logs as below ..
2015-04-28 14:16:03,856 [ProcessQ] INFO quickfixj.msg.incoming - FIX.4.2:MDAQ_DEV2_SANDPIT_MD->ANZD_SANDPIT_MD: 8=FIX.4.2^A9=1500^A35=X^A34=158757^A49=ANZD_SANDPIT_MD^A52=20150428-06:16:03.814^A56=MDAQ_DEV2_SANDPIT_MD^A262=9^A268=26^A279=2^A269=0^A278=7usB0^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA0^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB1^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA1^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB2^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA2^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB3^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA3^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB4^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA4^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB5^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA5^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB6^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA6^A55=USD/CHF^A15=USD^A279=0^A269=0^A278=7utB0^A55=USD/CHF^A270=0.95388^A15=USD^A271=1000000^A346=1^A279=0^A269=1^A278=7utA0^A55=USD/CHF^A270=0.95413^A15=USD^A271=1000000^A346=1^A279=0^A269=0^A278=7utB1^A55=USD/CHF^A270=0.95385^A15=USD^A271=2000000^A346=1^A279=0^A269=1^A278=7utA1^A55=USD/CHF^A270=0.95416^A15=USD^A271=2000000^A346=1^A279=0^A269=0^A278=7utB2^A55=USD/CHF^A270=0.95382^A15=USD^A271=2000000^A346=1^A279=0^A269=1^A278=7utA2^A55=USD/CHF^A270=0.95419^A15=USD^A271=2000000^A346=1^A279=0^A269=0^A278=7utB3^A55=USD/CHF^A270=0.95380^A15=USD^A271=5000000^A346=1^A279=0^A269=1^A278=7utA3^A55=USD/CHF^A270=0.95421^A15=USD^A271=5000000^A346=1^A279=0^A269=0^A278=7utB4^A55=USD/CHF^A270=0.95377^A15=USD^A271=10000000^A346=1^A279=0^A269=1^A278=7utA4^A55=USD/CHF^A270=0.95424^A15=USD^A271=10000000^A346=1^A279=0^A269=0^A278=7utB5^A55=USD/CHF^A270=0.95374^A15=USD^A271=10000000^A346=1^A279=0^A269=1^A278=7utA5^A55=USD/CHF^A270=0.95427^A15=USD^A271=10000000^A346=1^A10=041^A
2015-04-28 14:16:03,856 [SocketConnectorIoProcessor-0.0] INFO quickfixj.msg.incoming - FIX.4.2:MDAQ_DEV2_SANDPIT_MD->ANZD_SANDPIT_MD: 8=FIX.4.2^A9=1500^A35=X^A34=158757^A49=ANZD_SANDPIT_MD^A52=20150428-06:16:03.814^A56=MDAQ_DEV2_SANDPIT_MD^A262=9^A268=26^A279=2^A269=0^A278=7usB0^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA0^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB1^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA1^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB2^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA2^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB3^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA3^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB4^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA4^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB5^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA5^A55=USD/CHF^A15=USD^A279=2^A269=0^A278=7usB6^A55=USD/CHF^A15=USD^A279=2^A269=1^A278=7usA6^A55=USD/CHF^A15=USD^A279=0^A269=0^A278=7utB0^A55=USD/CHF^A270=0.95388^A15=USD^A271=1000000^A346=1^A279=0^A269=1^A278=7utA0^A55=USD/CHF^A270=0.95413^A15=USD^A271=1000000^A346=1^A279=0^A269=0^A278=7utB1^A55=USD/CHF^A270=0.95385^A15=USD^A271=2000000^A346=1^A279=0^A269=1
^A278=7utA1^A55=USD/CHF^A270=0.95416^A15=USD^A271=2000000^A346=1^A279=0^A269=0^A278=7utB2^A55=USD/CHF^A270=0.95382^A15=USD^A271=2000000^A346=1^A279=0^A269=1^A278=7utA2^A55=USD/CHF^A270=0.95419^A15=USD^A271=2000000^A346=1^A279=0^A269=0^A278=7utB3^A55=USD/CHF^A270=0.95380^A15=USD^A271=5000000^A346=1^A279=0^A269=1^A278=7utA3^A55=USD/CHF^A270=0.95421^A15=USD^A271=5000000^A346=1^A279=0^A269=0^A278=7utB4^A55=USD/CHF^A270=0.95377^A15=USD^A271=10000000^A346=1^A279=0^A269=1^A278=7utA4^A55=USD/CHF^A270=0.95424^A15=USD^A271=10000000^A346=1^A279=0^A269=0^A278=7utB5^A55=USD/CHF^A270=0.95374^A15=USD^A271=10000000^A346=1^A279=0^A269=1^A278=7utA5^A55=USD/CHF^A270=0.95427^A15=USD^A271=10000000^A346=1^A10=041^A
sequnece, session 0|i0007r:
QuickFIX/J QFJ-842

ClassCastException

Bug Closed Major Incomplete Unassigned Dotun Kola-Olaleye Dotun Kola-Olaleye 30/Apr/15 13:14   10/Oct/16 12:00 10/Oct/16 12:00 1.6.0   Engine   0 3   Windows Server 2012 64 bit I may be missing something, but I'm having to refactor my code that was written based on QuickFIXJJ-1.5.3. Previously, I would cast incoming quickfix.Message to specific message types e.g. quickfix.fix50.SecurityList or quickfix.fix50.ExecutionReport.

But since I switched jar files to 1.6.0, attempts to cast to message types like quickfix.fix50sp1.SecurityList or quickfix.fix50sp1.ExecutionReport results in a ClassCastException. Now, I'm having to work directly with quickfix.Message.

Any pointer is appreciated.

Dotun.
1.6.0, ClassCastException, QuickfixJ, Upgrade 0|i0007z:
QuickFIX/J QFJ-841

Unable to access Bamboo server

Other Closed Default Not a bug Unassigned Sam Ratcliff Sam Ratcliff 29/Apr/15 13:43   25/Dec/15 01:04 25/Dec/15 01:04         0 2   The address http://www.quickfixj.org:8085/browse/QFJ-CORE given in the developer resources is not reachable. 0|i00087:
QuickFIX/J QFJ-840

1.6.0 has not been uploaded to marketcetera repository

Bug Closed Default Duplicate Unassigned Sam Ratcliff Sam Ratcliff 29/Apr/15 13:26   18/May/15 10:43 18/May/15 10:43 1.6.0       1 3   The installation document references the marketcetera repository for people depending on QuickFix/J through Maven but the latest (1.6.0) version has not been uploaded. 0|i0008f:
QuickFIX/J QFJ-839

Modify the proxool connection pool properties using the settings file

Improvement Closed Minor Duplicate Unassigned Jose Elias Chavez Jose Elias Chavez 21/Apr/15 23:24   25/Dec/15 01:06 25/Dec/15 01:06     Engine   0 2   Currently the JdbcUtil class has the ProxoolDataSource's maximumConnectionCount hard-coded to 10.

I propose making changes so that the proxool datasource's properties can be modified via the settings file. If not specified, then the settings will default to the current values.
datasource 0|i0008n:
QuickFIX/J QFJ-838

Tests on jdk 1.7 failed

Bug Closed Default Fixed Marcin L Slawomir Pawlewicz Slawomir Pawlewicz 15/Apr/15 10:19   21/Apr/16 13:40 23/Dec/15 00:32 1.6.0 1.6.2 Engine   1 3   jdk 1.7.0_45 on Win7 x64 Tests passed on jdk 1.6. On jdk 1.7 they failed
-------------------------------------------------------------------------------
Test set: quickfix.SessionTest
-------------------------------------------------------------------------------
Tests run: 47, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 1.197 sec <<< FAILURE! - in quickfix.SessionTest
testResendRequestMsgSeqNum(quickfix.SessionTest) Time elapsed: 0.006 sec <<< FAILURE!
java.lang.AssertionError: Session should be logged out since seqnum too low!
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at quickfix.SessionTest.testResendRequestMsgSeqNum(SessionTest.java:1172)

testAcceptorRelogon(quickfix.SessionTest) Time elapsed: 0.002 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at quickfix.SessionTest.testAcceptorRelogon(SessionTest.java:1632)

testLogoutMsgSeqNumTooHighOrLow(quickfix.SessionTest) Time elapsed: 0.001 sec <<< FAILURE!
java.lang.AssertionError: expected:<3> but was:<4>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at quickfix.SessionTest.testLogoutMsgSeqNumTooHighOrLow(SessionTest.java:418)
session 0|i0008v:
QuickFIX/J QFJ-837

Tests on jdk1.8 fail

Bug Closed Default Duplicate Unassigned Slawomir Pawlewicz Slawomir Pawlewicz 15/Apr/15 10:05   25/Dec/15 00:50 25/Dec/15 00:50 1.6.0   Engine   0 3   jdk 1.8.0_40 Windows 7 x64 I executed quickifix test on jdk 1.6. All went fine. On jdk 1.8 failed:

-------------------------------------------------------------------------------
Test set: quickfix.SessionTest
-------------------------------------------------------------------------------
Tests run: 47, Failures: 6, Errors: 0, Skipped: 0, Time elapsed: 1.514 sec <<< FAILURE! - in quickfix.SessionTest
testSequenceResetStackOverflow(quickfix.SessionTest) Time elapsed: 0.012 sec <<< FAILURE!
java.lang.AssertionError: expected:<51> but was:<50>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at quickfix.SessionTest.testSequenceResetStackOverflow(SessionTest.java:1044)

testResendRequestMsgSeqNum(quickfix.SessionTest) Time elapsed: 0.011 sec <<< FAILURE!
java.lang.AssertionError: Session should be logged out since seqnum too low!
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at quickfix.SessionTest.testResendRequestMsgSeqNum(SessionTest.java:1172)

testSimultaneousResendRequests(quickfix.SessionTest) Time elapsed: 0 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at quickfix.SessionTest.testSimultaneousResendRequests(SessionTest.java:1225)

testDontCatchErrorsFromCallback(quickfix.SessionTest) Time elapsed: 0.003 sec <<< FAILURE!
org.junit.ComparisonFailure: expected:<[java.lang.Error: TEST]> but was:<[No error thrown]>
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at quickfix.SessionTest.testDontCatchErrorsFromCallback(SessionTest.java:1462)

testAcceptorRelogon(quickfix.SessionTest) Time elapsed: 0 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at quickfix.SessionTest.testAcceptorRelogon(SessionTest.java:1632)

testStateFlagsAreResetOnLogout(quickfix.SessionTest) Time elapsed: 0.001 sec <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at quickfix.SessionTest.testStateFlagsAreResetOnLogout(SessionTest.java:1670)
session 0|i00093:
QuickFIX/J QFJ-836

new quickfix.fix44.NewOrderSingle fail

Bug Closed Critical Duplicate Unassigned Cédric Jeanroy Cédric Jeanroy 13/Apr/15 14:42   14/Apr/15 11:47 14/Apr/15 11:46 1.6.0   Engine   1 3   JRE 1.7 and 1.8 With quickfixj 1.6.0 when I do :
{code}
quickfix.fix44.NewOrderSingle o = new quickfix.fix44.NewOrderSingle();
{code}

I get the following error :
{quote}
Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
Exception Details:
Location:
quickfix/fix44/NewOrderSingle.get(Lquickfix/field/SettlType;)Lquickfix/field/SettlType; @2: invokevirtual
Reason:
Type 'quickfix/field/SettlType' (current frame, stack[1]) is not assignable to 'quickfix/CharField'
Current Frame:
bci: @2
flags: { }
locals: { 'quickfix/fix44/NewOrderSingle', 'quickfix/field/SettlType' }
stack: { 'quickfix/fix44/NewOrderSingle', 'quickfix/field/SettlType' }
Bytecode:
0000000: 2a2b b600 3057 2bb0
{quote}

I foundd that there is two quickfix.field.SettlType class :
One in quickfixj-core which extends StringField
One in quickfixj-messages-fix44 which extends CharField
0|i0009b:
QuickFIX/J QFJ-835

Required tag missing, field=447

Bug Closed Critical Not a bug Unassigned Anevale Anevale 10/Apr/15 13:47   13/Apr/15 16:15 10/Apr/15 16:09 1.5.3   Message Generation   0 3   CentOS release 6.5 (Final), Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode) Scenario:

The raw message received at AbstractIoHandler shows that the tag 447 is there

8=FIXT.1.1 9=X 35=8 ... 453=2 448=X 447=D 452=75 448=Y 447=D 452=1 ...10=X

However, at next step, the DataDictionary.validate() invoke from Session produces the below FieldException

Rejecting invalid message: quickfix.FieldException: Required tag missing, field=447:
8=FIXT.1.1 9=X 35=8 ... 453=2 447=D 448=X 452=75 447=D 448=Y 452=1 10=X

As shown from the exception log, the printed message still has the tag of 447, but the ordering of field 448 and 447 inside Parties(453) are reversed.

Is this a known issue of QuickFixJ 1.5.3?

we are using oracle jdk1.7.0_u51 (64bit)
0|i0009j:
QuickFIX/J QFJ-834

messages.log and event.log file are not created using SLF4JLogFactory

Bug Closed Default Not a bug Unassigned garima gangwar garima gangwar 10/Apr/15 09:42   25/Dec/15 01:09 25/Dec/15 01:09         0 2   I have quickfixj setup in my application and store messages.log and event.log at a location. I have configured RollingFileAppender for these logs but it is not working for quickfix logs and logs are not not rolling over.

<appender name="FIXMESSAGE" class="org.apache.log4j.RollingFileAppender">
<param name="Threshold" value="INFO"/>
<param name="File" value="../log/fixlog/FIX.4.2-sendercompID-targetCompID.event.log" />
<param name="Append" value="true" />
<param name="MaxFileSize" value="25KB"/>
<param name="MaxBackupIndex" value="15"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="[%d{dd MMM yyyy HH:mm:ss,SSS}][%t][%-5p][%c{2}]-%m%n"/>
</layout>
</appender>
<appender name="FIXEVENT" class="org.apache.log4j.RollingFileAppender">
<param name="Threshold" value="INFO"/>
<param name="File" value="../log/fixlog/FIX.4.2-sendercompID-targetCompID.messages.log" />
<param name="Append" value="true" />
<param name="MaxFileSize" value="25KB"/>
<param name="MaxBackupIndex" value="15"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="[%d{dd MMM yyyy HH:mm:ss,SSS}][%t][%-5p][%c{2}]-%m%n"/>
</layout>
</appender>

<root>
<priority value ="INFO" />
<appender-ref ref="CONSOLE" />
<appender-ref ref="FIXMESSAGE" />
<appender-ref ref="FIXEVENT" />
</root>


Just to add, I have also defined below fix configuration as follows:

SLF4JLogEventCategory=${fix.connection.config.senderCompID}.${fix.connection.config.targetCompID}.events
SLF4JLogIncomingMessageCategory=${fix.connection.config.senderCompID}.${fix.connection.config.targetCompID}.incoming
SLF4JLogOutgoingMessageCategory=${fix.connection.config.senderCompID}.${fix.connection.config.targetCompID}.outgoing


Can anyone suggest something here?
0|i0009r:
QuickFIX/J QFJ-833

Add Slow Consumer Protection

New Feature Closed Default Fixed James Olsen James Olsen James Olsen 08/Apr/15 16:13   13/Dec/16 22:51 28/Dec/15 23:41 1.6.0 1.6.3 Engine   0 2   OOMs are possible where downstream consumers do not process messages fast enough. It is useful to be able to detect and prevent this, especially for MD/Quote streams. 0|i0009z:
QuickFIX/J QFJ-832

Multi-Version support is busted in 1.6.0

Bug Closed Blocker Duplicate ManuReno James Olsen James Olsen 08/Apr/15 11:15   24/Jul/15 11:07 24/Jul/15 11:06 1.6.0 1.6.1     6 11   The issue discussed in http://sourceforge.net/p/quickfixj/mailman/message/32791285/ has not been resolved.

It is impossible to have a system that works with multiple FIX versions due to these VerifyErrors.

Even pre 1.6.0 systems that currently work and use only a single version may now fail depending on their classpath ordering as 'core' contains one variant of the Fields and may conflict with the desired 'messages' project.

This was not an issue in 1.5.3 and earlier where there was only one copy of the Fields.
0|i000a7:
QuickFIX/J QFJ-831

35=2 after 35=4 failed because "MsgSeqNum too low"

Bug Closed Default Not a bug Unassigned Shi Lei Shi Lei 06/Apr/15 06:56   13/Apr/15 13:07 13/Apr/15 11:19 1.5.3   Engine   0 2   AIX This scenario happened in a poor network environment where some messages are missing but heartbeat still working, no logout before issue happened:

1. My app is client side using quickfixj-all-1.5.3.jar.
2. When network has problem, some messages are missing (both sides)
3. Sometimes server side send 35=4 request to increase seq_no by 1 while there's no missing seq_no from server side. E.g.
34=100, 35=8......
34=101, 35=8......
34=102, 35=4, 36=103, 123=Y...
I don't know why server side send this 35=4 asking to reset seq_no to 103 (seq_no 100 and 101 received successfully and 102 is reset request itself)
4. If next message from server side is 34=103, 35=8, it's OK
if next message from server side is 35=103, 35=2, client side FIX engine will return "MsgSeqNum too low, expecting 103 but received 102"

The question is
1) why 35=2 after 35=4 fail while 35=8 after 35=4 OK
2) the seq_no of failed 35=4 after 35=2, I double checked it's 103, why response is "MsgSeqNum too low, expecting 103 but received 102"

0|i000af:
QuickFIX/J QFJ-830

[QFJ Timer] ERROR quickfix.ThreadedSocketAcceptor 289 - Error during timer processing

Bug Closed Default Not a bug Unassigned wangsheng wangsheng 27/Mar/15 13:13   27/Mar/15 13:19 27/Mar/15 13:19         0 2   2015-02-25 01:58:48,906 [QFJ Timer] ERROR quickfix.ThreadedSocketAcceptor 289 - Error during timer processing
quickfix.RuntimeError: java.io.FileNotFoundException: C:\croot\Rootnet\JavaCllientFixGateWay\store\FIX.4.2-CROOT-JETPAC.session (Access is denied)
at quickfix.SessionState.reset(SessionState.java:379)
at quickfix.Session.resetState(Session.java:2325)
at quickfix.Session.reset(Session.java:798)
at quickfix.Session.next(Session.java:1773)
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:283)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.FileNotFoundException: C:\croot\Rootnet\JavaCllientFixGateWay\store\FIX.4.2-CROOT-JETPAC.session (Access is denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:116)
at quickfix.FileStore.storeSessionTimeStamp(FileStore.java:143)
at quickfix.FileStore.initializeSessionCreateTime(FileStore.java:138)
at quickfix.FileStore.initializeCache(FileStore.java:119)
at quickfix.FileStore.initialize(FileStore.java:112)
at quickfix.FileStore.reset(FileStore.java:447)
at quickfix.SessionState.reset(SessionState.java:377)
... 13 more
0|i000an:
QuickFIX/J QFJ-829

QuickMessage: Invalid message: Expected BodyLength=454, Recieved BodyLength=469

Bug Closed Major Won't Fix Unassigned Shuaib Kaniyar Shuaib Kaniyar 25/Mar/15 05:05   26/Mar/15 13:12 26/Mar/15 13:12     Engine   0 2   Windows 2008 R2 Server When receiving a ExecutionReport (35=n) i receive the below error

QuickMessage: Invalid message: Expected BodyLength=454, Recieved BodyLength=469

Sample Vendor Message

8=FIX.4.29=46935=n34=13208369=1952=20150324-08:07:58.91943=Y49=CME50=7056=UAT12357=P122=20150324-07:57:04.201212=350213=<RTRF>8=FIX.4.29=31435=834=15294369=775852=20150324-07:57:04.19949=CME50=7056=AZT000N57=DUMMY143=US,IL1=003316=011=ACP142718382415514=017=70477:206612220=037=7029490619138=1039=040=241=044=50448=806054=155=HW59=060=20150324-07:57:04.198107=HWJ5150=0151=10167=FUT432=201503241028=Y9717=ACP142718382415510=039</RTRF>10=097

Attach is DataDictionary FIX42.xml
0|i000av:
QuickFIX/J QFJ-828

Messages Log Contains Another Session's Messages

Bug Open Default Unresolved Unassigned Rupert Webb Rupert Webb 19/Feb/15 23:59   20/Feb/15 23:28   1.5.3       0 2   Linux Server I had two quick fix sessions configured: CLIENT and CLIENT2. Our CLIENT2 session connected while no one connected to the CLIENT session. You can see this from the event logs:

::::::::::::::
FIX.4.2-LIME-CLIENT2.event.log
::::::::::::::
20150219-08:20:41: Session FIX.4.2:LIME->CLIENT schedule is daily, 05:00:00-UTC - 00:59:00-UTC
20150219-08:20:41: Created session: FIX.4.2:LIME->CLIENT

::::::::::::::
FIX.4.2-LIME-CLIENT2.event.log
::::::::::::::
20150219-08:20:41: Session FIX.4.2:LIME->CLIENT2 schedule is daily, 05:00:00-UTC - 00:59:00-UTC
20150219-08:20:41: Created session: FIX.4.2:LIME->CLIENT2
20150219-12:03:04: Accepting session FIX.4.2:LIME->CLIENT2 from /10.22.75.167:52406
20150219-12:03:04: Acceptor heartbeat set to 45 seconds
20150219-12:03:04: Received logon
20150219-12:03:04: Responding to Logon request
20150219-12:03:04: Received ResendRequest FROM: 1 TO: infinity
...

However, all the messages in CLIENT2's message log begin appearing in CLIENT's messages log:

::::::::::::::
FIX.4.2-LIME-CLIENT.messages.log
::::::::::::::
8=FIX.4.2|9=103|35=A|34=1|49=CLIENT2|52=20150219-12:03:04.175|56=LIME|98=0|108=45|553=USER2|554=DROPCOPY|10=165|
8=FIX.4.2|9=71|35=A|34=5998|49=LIME|52=20150219-12:03:04.185|56=CLIENT2|98=0|108=45|10=117|
8=FIX.4.2|9=65|35=2|34=2|49=CLIENT2|52=20150219-12:03:04.697|56=LIME|7=1|16=0|10=032|


::::::::::::::
FIX.4.2-LIME-CLIENT2.messages.log
::::::::::::::
8=FIX.4.2|9=103|35=A|34=1|49=CLIENT2|52=20150219-12:03:04.175|56=LIME|98=0|108=45|553=USER2|554=DROPCOPY|10=165|
8=FIX.4.2|9=71|35=A|34=5998|49=LIME|52=20150219-12:03:04.185|56=CLIENT2|98=0|108=45|10=117|
8=FIX.4.2|9=65|35=2|34=2|49=CLIENT2|52=20150219-12:03:04.697|56=LIME|7=1|16=0|10=032|

This only begin happening today. Here is the configuration:
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=60
SenderCompID=LIME
FileStorePath=fixstore-[4]-2015-02-19/
FileLogPath=fixlogs-[4]-2015-02-19/
ValidateFieldsOutOfOrder=N
ValidateFieldsHaveValues=N
ValidateIncomingMessage=N
AllowUnknownMsgFields=Y
UseDataDictionary=Y
StartTime=05:00:00
EndTime=00:59:00
BeginString=FIX.4.2
SocketAcceptPort=9003
SocketReuseAddress=Y
ValidateUserDefinedFields=N
PersistMessages=Y
CheckLatency= Y

[SESSION]
TargetCompID=CLIENT2
CheckPassword=Y
Password=PASS

[SESSION]
TargetCompID=CLIENT
CheckPassword=Y
Password=PASS
QuickfixJ 0|i000bb:
QuickFIX/J QFJ-827

quickfixj-core build failure when generating javadocs on JDK8

Bug Closed Default Fixed Christoph John kammo kammo 07/Feb/15 06:46   02/Apr/15 23:22 09/Feb/15 13:07 1.5.3 1.6.0 Build   0 2   It is throwing error while executing java-doc build. Below is trimmed snippet of the error log.

[ERROR] * @throws ConfigError
[ERROR] ^
[ERROR] C:\Users\Moliya\Documents\quickfixj-master\quickfixj-core\src\main\java\
quickfix\SessionSettings.java:564: error: block element not allowed within inlin
e element <code>: pre
[ERROR] * <code><pre>
[ERROR] ^
[ERROR]
[ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_31\jre\..\bin\javadoc.
exe" -J-Xmx1536m @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 'C:\Users\Moliya\Documents\quick
fixj-master\quickfixj-distribution\target\site\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
0|i000bj:
QuickFIX/J QFJ-826

Maven build is failing on test cases for quickfixj-core when compiling with JDK8

Bug Closed Minor Fixed Christoph John kammo kammo 07/Feb/15 06:21   02/Apr/15 23:22 11/Mar/15 14:53 1.5.3 1.6.0 Build   0 2   Below test cases are failing and hence whole build is failing.
SessionTest.testStateFlagsAreResetOnLogout
SessionTest.testAcceptorRelogon
SessionTest.testDontCatchErrorsFromCallback
SessionTest.testSimultaneousResendRequests
SessionTest.testResendRequestMsgSeqNum
SessionTest.testSequenceResetStackOverflow
0|i000br:
QuickFIX/J QFJ-825

Restart of SessionConnector might lead to creation of additional message processor threads

Bug Closed Major Fixed Christoph John Christoph John Christoph John 06/Feb/15 12:07   02/Apr/15 23:22 15/Mar/15 01:11 1.5.3 1.6.0 Engine   0 1   When using a SingleThreadedEventHandlingStrategy it is expected that there is only one "QFJ Message Processor" thread. However, when starting a connector multiple times in a row or when quickly restarting it, there might be several message processor threads. This situation might lead to unforeseen effects, e.g. race conditions or sequence number issues.

The reason for this seems to be that the message processor thread is polling the event queue and does not get stopped correctly when waiting for the next message in the queue.
Workaround for the time being: make sure that you sleep at least 1000ms (polling interval on event queue) before (re)starting a connector after stopping it. This will give the message processor thread enough time to shutdown orderly.

todo
* prevent concurrent startups of Initiator/Acceptor
* prevent creation of multiple message processor threads
* add some info logging that the message processor thread has been started/stopped
0|i000bz:
QuickFIX/J QFJ-824

QuickFIXJ stops sending and processing heartbeats

Bug Open Major Unresolved Unassigned Wongsakorn Chantrapornsyl Wongsakorn Chantrapornsyl 02/Feb/15 10:25   04/Feb/15 08:49   1.5.3   Engine   1 4   Microsoft Windows Server 2008 I have a problem that QuickFIXJ stops sending the heartbeat. Please see the QuickFIXJ log below.

The heartbeat interval is set to 4.

20150127-01:01:34: 8=FIXT.1.19=7535=034=318541128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:34.78910=197
20150127-01:01:36: 8=FIXT.1.19=9535=034=3237749=TMSQ03226252=20150127-01:01:36.80256=TR MATCHING57=FXM142=TRFXMJP53776xxx10=130
20150127-01:01:38: 8=FIXT.1.19=7535=034=318551128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:38.89910=204
20150127-01:01:41: 8=FIXT.1.19=9535=034=3237849=TMSQ03226252=20150127-01:01:41.73956=TR MATCHING57=FXM142=TRFXMJP53776xxx10=136
----- After this time FIXQuickJ stops sending the heartbeart ---- only receive the heartbeat from other side. ----
20150127-01:01:42: 8=FIXT.1.19=7535=034=318561128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:42.96410=193
20150127-01:01:50: 8=FIXT.1.19=7535=034=318571128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:47.03910=192
20150127-01:01:51: 8=FIXT.1.19=9035=134=318581128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:48.063112=HBTO-3185810=242
20150127-01:01:52: 8=FIXT.1.19=7535=034=318591128=949=TR MATCHING56=TMSQ03226252=20150127-01:01:52.12910=190
------ It seems that FIXQuickJ received heartbeat and testrequest but FIXQuickJ does not process them as QuickFIXJ send the testrequest to other side. -----
20150127-01:01:51: 8=FIXT.1.19=10435=134=3237949=TMSQ03226252=20150127-01:01:51.89656=TR MATCHING57=FXM142=TRFXMJP53776xxx112=TEST10=200
------ The other side disconnect because it does not receive heartbeat -------

Do you have any idea why QuickFIXJ stops sending the heartbeat and also does not process the message from other side.
QuickfixJ, timeout 0|i000c7:
QuickFIX/J QFJ-823

Problem with concurrent access to UtcTimestampConverter#dateCache

Bug Closed Default Fixed Alexander Troshanin Alexander Troshanin Alexander Troshanin 19/Jan/15 17:57   02/Apr/15 23:22 22/Jan/15 11:27 1.5.3 1.6.0     0 2 _thumb_10575.png   In quickfix library there is class
UtcTimestampConverter
in last version 1.5.3 there is static varaible
{code}
private static HashMap<String, Long> dateCache
{code}

As I see, this varaible is used as cache:
{code}
private static Long getMillisForDay(String value) {
String dateString = value.substring(0, 8);
Long millis = dateCache.get(dateString);
if (millis == null) {
Calendar c = new GregorianCalendar(1970, 0, 1, 0, 0, 0);
c.setTimeZone(SystemTime.UTC_TIMEZONE);
int year = Integer.parseInt(value.substring(0, 4));
int month = Integer.parseInt(value.substring(4, 6));
int day = Integer.parseInt(value.substring(6, 8));
c.set(year, month - 1, day);
millis = c.getTimeInMillis();
dateCache.put(dateString, c.getTimeInMillis());
}
return millis;
}
{code}

But if this code will be invoked from different threads(in my case it is so), then HashMap my become broken, => cuncurrent access and modification of hashmap.
Under high load I can reproduce this on my dev server.

I would suggest to replace HashMap with ConcurrentHashMap
{code}
private static ConcurrentHashMap<String, Long> dateCache = new ConcurrentHashMap<String, Long>();
{code}
0|i000cf:
QuickFIX/J QFJ-822

DNS change prevents reconnection

Improvement Closed Default Fixed Dale Wilson Dale Wilson Dale Wilson 08/Jan/15 22:21   21/Apr/16 13:40 19/Dec/15 23:53 1.5.3 1.6.2 Networking   0 2   All If a connection is lost and a DNS change is made before an attempt is made to reconnect, the reconnection attempt will fail, because the previous resolution information was cached by the initiator and will be re-used.

I'll be submitting a GitHub pull request for a change that invalidates the cached connection information when a connection attempt fails. This will have no impact on normal operations. The first reconnect attempt will use the cached information, but if it fails, the host name will be resolved again before the next attempt.
Reconnect 0|i000cn:
QuickFIX/J QFJ-821

Quickfix/J Server should validate SSL client certificates

Improvement Closed Major Fixed Marcin L harnit harnit 29/Dec/14 02:40   13/Dec/16 22:51 26/Dec/15 00:09 1.5.2 1.6.3 Engine   1 5   O/S: Windows 8
Java: JDK 1.8.0_25
In quickfix.mina.acceptor.AbstractSocketAcceptor we have sslFilter.setUseClientMode(false);

What we found is this means that the Quickfix/J server never validates the client certificates.

Can we please provide a configuration for this to enable needClientAuth?
0|i000cv:
QuickFIX/J QFJ-820

quickfixj ignores the first message on sequence reset

Bug Closed Major Not a bug Unassigned Emma Wansbrough Emma Wansbrough 15/Dec/14 18:49   19/Dec/14 11:45 19/Dec/14 11:44 1.5.3, 1.6.0   Build   0 3   this happens on window and linux Hi,
I am experiencing the following serious fix issue. This could be config but I am not convinced.


I have used both quickfixj 1.5.3 and the newer 1.6.0 (snapshot)

I get the following issue

I connect to the fix server periodically there is a message that comes in out of sequence


From the event log we get the following issue

20141215-00:01:02: Received logon
20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:

Execution Report

Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474

20141215-14:41:57: Enqueued at pos 474: Field
Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474

20141215-14:41:57: Sent ResendRequest FROM: 473 TO: 473
20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474



and at this point we get a general repeat of this deadlock

From mesages log you can see that a resend request got sent
Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 68
35 MsgType Resend Request (2)
34 MsgSeqNum 441
49 SenderCompID NOMXFIXPTM
52 SendingTime 20141215-14:41:57.405
56 TargetCompID MA
7 BeginSeqNo 473
16 EndSeqNo 0

the next message from MA is




Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 1095
35 MsgType Execution Report (8)
34 MsgSeqNum 473
43 PossDupFlag Y
49 SenderCompID MA
52 SendingTime 20141215-14:41:57.415
56 TargetCompID NOMXFIXPTM
122 OrigSendingTime 20141215-14:41:43
37 OrderID 1240469
527 SecondaryExecID 8534860-0

And MA keep sending trades with the next sequence up but our client is having none of it.

20141215-14:41:57: Already sent ResendRequest FROM: 473 TO: 473. Not sending another.

The thing that seems to be wrong is the first message sent over after the resend request gets ignored, instead it sees the message after that.
Restarting can put this back to the correct sequencing and thus out of the deadlock

I am hoping someone might have some insight into this issue.
0|i000d3:
QuickFIX/J QFJ-819

Create XSD Schema for FIX dictionary files

Improvement In Progress Default Unresolved Stephen Flynn Stephen Flynn Stephen Flynn 19/Nov/14 13:49   19/Nov/14 14:15     2.0-BETA Engine, Message Generation   0 2   Fix xml dictionary documents (FIX44.xml etc) should have a defined schema (XSD).
The schema can be used for...
(i) authoring customer fix data dictionaries.
(ii) validating documents at both build and runtime.
(iii) configuring the DataDictionary (via JAXB).

At the moment the DataDictionary.load() method pulls in an org.w3c.dom.Document instance and then iterates through it using hardwired node names doing some adhoc validation along the way. It would be much better to load a validated document as a type safe object and iterate through that.

The schema should fit the existing doc layout with as few changes as possible (probably a namespace declaration will be required).
0|i000db:
QuickFIX/J QFJ-818

SSL3 “POODLE” Vulnerability impact QuickFIXJ (bundle Apache MINA) ?

Other Closed Critical Incomplete Unassigned surachai chatsomsiri surachai chatsomsiri 03/Nov/14 09:30   22/Dec/15 22:51 22/Dec/15 22:51 1.5.3   Networking   0 2   quickfixj-all-1.5.3.jar
mina-core-1.1.7.jar
mina-filter-ssl-1.1.7.jar
JRE 6.0.2
Hi Support.
I am developer implemented QuickFIXJ(Client side) got feed from QuickFIXJ(Feed Server side), It using SSL protocol, for my understand QuickFIXJ using Apache MINA for establish SSL protocol.

According to the links below, seems that any SSL v3 got impact from the POODLE vulnerability..
the "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is aprotocol flaw,
http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability

Could you help me provide information please?
1. What's SSL protocol version using in Apache MINA? <= I try to find information unfortunate i not found it.

2. The “POODLE” Vulnerability will impact with QuickFIXJ (using Apache MINA) if Yes, Can you provide solution to prevent it?

Thank you very much
Surachai C.
QuickfixJ, ssl 0|i000dr:
QuickFIX/J QFJ-817

quickfix.Message parseGroup throws NumberFormatException

Bug Open Major Unresolved Unassigned Christian Asmussen Christian Asmussen 31/Oct/14 10:42   06/Feb/15 11:55   1.5.3   Engine   0 3   I fixed it with the following snippet:

{code}
private void parseGroup(String msgType, StringField field, DataDictionary dd, FieldMap parent)
throws InvalidMessage {
final DataDictionary.GroupInfo rg = dd.getGroup(msgType, field.getField());
final DataDictionary groupDataDictionary = rg.getDataDictionary();
final int[] fieldOrder = groupDataDictionary.getOrderedFields();
int previousOffset = -1;
final int groupCountTag = field.getField();
final int declaredGroupCount;
try {
declaredGroupCount = Integer.parseInt(field.getValue());
} catch(NumberFormatException nfe){
throw new FieldException(SessionRejectReason.INCORRECT_NUMINGROUP_COUNT_FOR_REPEATING_GROUP, "The group " + field.getTag() + " must have an integer delimiter field [value=" + field.getValue() + "]", field.getTag());
}
{code}

This allows the parsing to continue.
0|i000dz:
QuickFIX/J QFJ-816

Put milliseconds in OrigSendingTime if SendingTime has them

Improvement Closed Default Fixed Christoph John Horia Muntean Horia Muntean 29/Oct/14 14:19   02/Apr/15 23:22 29/Oct/14 15:52 1.5.3 1.6.0     0 2   OrigSendingTime is set without milliseconds even if the SendingTime has them. This seems rather trivial to implement based on the logic used for SendingTime i.e. MillisecondsInTimeStamp config and version >= 4.2.

I can do this if requested.
0|i000e7:
QuickFIX/J QFJ-815

Originalsending (tag 122) is getting deleted by initiator.

Other Closed Major Not a bug Unassigned raghuram potluri raghuram potluri 21/Oct/14 19:48   22/Oct/14 09:55 22/Oct/14 09:52 1.5.3   Engine   0 2   windows when invoking sendtotarget, initiator removing origsendingtime field in below code snipped.


public boolean send(Message message) {
message.getHeader().removeField(PossDupFlag.FIELD);
message.getHeader().removeField(OrigSendingTime.FIELD);
return sendRaw(message, 0);
}
0|i000ef:
QuickFIX/J QFJ-814

Sequence Reset Fails

Other Open Default Unresolved Unassigned Rahul Gaur Rahul Gaur 16/Oct/14 13:30   27/Nov/14 16:29   1.5.0   Engine   0 2   Hi All,

Here are the steps:

1. Our FIX engine receives an out of sequence messages with MsgSeqNum(s) => 200938 -> 200941 -> 200939 (No 200940 received).

2. It complains => "MsgSeqNum too high, expecting 200939 but received 200941" and sends a 'ResendRequest(35=2)' with 'BeginSeqNo=200939'.

3. Before receiving the reset message it receives two more messages with MsgSeqNum(s) => 200942 -> 200943.

4. It then receives the 'SequenceReset(35=4)' with:
a) NewSeqNo = 200944
b) MsgSeqNum = 200939
c) PossDupFlag = Y
d) GapFillFlag = Y

5. No trace in the logs as to whether the 'SequenceReset' is handled or not.

6. It then receives a message with MsgSeqNum = 200944 and complains => 'MsgSeqNum too high, expecting 200940 but received 200944'. This error message persists for all subsequent messages and our engine is not able to recover from it as the MsgSeqNum = 200940 is never received.

At step 6, shouldn't the engine ignore all messages from 200939-200943 and start afresh from 200944.

Thanks
Rahul
sequence, 0|i000en:
QuickFIX/J QFJ-813

SessionConnector:waitForLogout()'s InterruptedException handling.

Improvement Open Default Unresolved Unassigned Francesco Lo Conte Francesco Lo Conte 11/Oct/14 05:45   15/Dec/14 10:29   1.5.3 2.0-BETA Engine   0 2   When the executing thread is interrupted the waitForLogout() method catches it and prints and error to log.

I would like to suggest that the exception is either thrown or at least re-asserted so that higher level application code can handle it. Also I would like to suggest that nothing is printed to the log file.

This would:
- Let higher level application code realize that an interruption has occurred.
- Stop the engine as requested (if it's thrown).
- Let higher level application code handler the interruption properly.
- Let higher level application code decide what to print in the log file.

Currently after the interruption is requested there is no way to know whether the engine actually stopped.
Also the log file is polluted (in my opinion) with a stack dump whereas this is not an actual error condition.

I supposed a similar behavior would be desirable in all other equivalent places in the code.

I would be interested to hearing your opinion about it.

Many thanks.
Francesco Lo Conte
0|i000ev:
QuickFIX/J QFJ-812

Non-Logon message received before Logon should result in disconnection

Bug Closed Default Fixed Christoph John Thom Shutt Thom Shutt 07/Oct/14 17:10   02/Apr/15 23:22 08/Oct/14 17:50   1.6.0     0 2   According to Fix protocol, if a message is sent before Logon, an error should be logged and the user should be disconnected.

Currently, an error is logged but no disconnection happens.

Edit: this is outlined in the "Sellside-oriented (session acceptor) Logon and session initiation test case" 1S.
0|i000f3:
QuickFIX/J QFJ-811

Tag 989 is hard coded wrongly in version 1.5.3

Bug Open Default Unresolved Unassigned Chaitanya N Chaitanya N 06/Oct/14 16:55   06/Oct/14 16:58   1.5.3       0 2   Tag 989 should come after tag 81, which comes under the repeating group tag of tag 79.

public NoAllocs() {
super(78, 79,
new int[] {
79, 661, 573, 366, 80, 467, 81, 539, 208, 209, 161, 360, 361,
12, 13, 479, 497, 153, 154, 119, 737, 120, 736, 155, 156,
742, 741, 136, 576, 780, 172, 169, 170, 171, 85, 989, 1002,
993, 992, 1047, 635, 0
});
}
Check the FIX community link for more information

http://www.fixtradingcommunity.org/FIXimate/FIXimate3.0/en/FIX.5.0SP2/body_50484851.html?find=SecondaryIndividualAllocID

I know there is a work around ValidateUnorderedGroupFields='N' to ignore validation of repeating groups, But can we have a proper fix to cater to people who doesn't want to use this work around?
0|i000fb:
QuickFIX/J QFJ-810

Messages get lost during logon process with sequence gap

Bug Open Major Unresolved Unassigned Heribert Steuer Heribert Steuer 06/Oct/14 13:47   16/Oct/14 13:41       Engine   0 2   When a sequence gap exists, all subsequent messages sent by the counterparty are lost when the logon message contains a out-of-sync sequence number.

Scenario: Counterparty A is initiating a logon, counterparty B responds to the logon and immediately sends 10 more messages. A now detects the sequence problem in the login message and closes the session. The 10 messages are lost (meaning they are logged as received but never appear in the callback)

The problem seems to be that the verify() function detects the gap in the logon messages, creates a logout and a disconnect. This leads to the fact that the ThreadPerSessionEventHandlingStrategy.run method is left and its local queue gets destroyed - still containing the messages that have been received after the logon.

Whatever the correct behaviour would be - the current one is a problem because of the messages are received but never processed. It might be better to leave ThreadPerSessionEventHandlingStrategy.run() only if the queue is empty.


condition, gap, logon, race 0|i000fj:
QuickFIX/J QFJ-809

Provide sensible default for property FileStoreMaxCachedMsg

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 29/Sep/14 09:25   02/Apr/15 23:22 30/Sep/14 09:22 1.5.3 1.6.0 Engine   0 1   We should take 10000 as default and not Integer.MAX_VALUE which might lead to OutOfMemory issues.
0|i000fr:
QuickFIX/J QFJ-808

Prevent setting illegal double values to FIX messages in order to avoid checksum errors

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 26/Sep/14 18:08   02/Apr/15 23:22 30/Sep/14 11:08 1.5.3 1.6.0     0 2   See discussion in comments on QFJ-626.
We should throw an Exception when trying to set a non-double value on DoubleFields.
0|i000fz:
QuickFIX/J QFJ-807

On a NonStopSession there is no use to check the session time each second

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 26/Sep/14 17:20   02/Apr/15 23:22 26/Sep/14 18:06 1.5.3 1.6.0     0 1   0|i000g7:
QuickFIX/J QFJ-806

Tag appears more than once

Bug Closed Default Not a bug Unassigned Victor Rosenberg Victor Rosenberg 11/Aug/14 09:36   11/Aug/14 09:53 11/Aug/14 09:52 1.5.3       0 2   The following exception is created when parsing the message: quickfix.FieldException: Tag appears more than once, field=279

The code:
String strMessage =
"8=FIX.4.2|9=196|35=X|49=A|56=B|34=12|52=20100318-03:21:11.364|262=A|268=2|279=0|269=0|278=BID|55=EUR/USD|270=1.37215|15=EUR|271=2500000|346=1|279=0|269=1|278=OFFER|55=EUR/USD|270=1.37224|15=EUR|271=2503200|346=1|10=171|"
.replace('|', (char)1);

Message message = MessageUtils.parse(new DefaultMessageFactory(), null, strMessage);

Also see http://stackoverflow.com/questions/24573883/quickfixj-rejecting-incoming-message-with-tag-appears-more-than-once-where-the
0|i000gf:
QuickFIX/J QFJ-805

Set GBK charset will silently drop message

Bug Closed Default Duplicate Unassigned Jiang Hailong Jiang Hailong 07/Aug/14 17:00   08/Aug/14 07:28 08/Aug/14 07:28 1.5.3   Engine   0 2   0|i000gn:
QuickFIX/J QFJ-804

Race condition between sessionClosed and processing logout message received

Bug Closed Default Duplicate Christoph John Glyn Walters Glyn Walters 31/Jul/14 16:12   27/Oct/14 20:50 27/Oct/14 20:45 1.5.3 1.6.0 Build   0 2   sessionClosed() called by AbstractIoHandler can call disconnect() on Session before a logout message has been processed by the EventHandlingSession. (This was witnessed with a SingleThreadedEventHandlingStrategy).

The disconnect() call on Session results in logonSent being set to false in SessionState. If this happens before SingleThreadedEventHandlingStrategy calls next(Message) on the Session object, the logout message will subsequently throw a SessionException in validLogonState() (as logonSent is now false). And the message will not reach the application.

This is problematic in the scenario where an ECN is informing us in a logout message of an issue with sequence numbers. The message is not received and the appropriate action can't take place,

This is an example of the occurrence from our logs with Reuters:

20140731-10:44:42.662 INFO [SocketConnectorIoProcessor-1.0] quickfix.Session - [XXX/YYY->TR MATCHING/FXM] Disconnecting: IO Session closed
20140731-10:44:42.663 ERROR [QFJ Message Processor] quickfixj.errorEvent - XXX/YYY->TR MATCHING/FXM: quickfix.SessionException Logon state is not valid for message (MsgType=5)

One possible suggestion would be to check the EventHandlingStrategy queue size and delay the sessionClosed call if there are outstanding events.

E.g. in InitiatorIoHandler

@Override
public void sessionClosed(IoSession ioSession) throws Exception {
while (eventHandlingStrategy.getQueueSize() > 0) {
log.info("Delaying sessionClosed while " + eventHandlingStrategy.getQueueSize() + " event(s) "
+ "are processed");
try {
Thread.sleep(500);
} catch (InterruptedException e) {
log.warn("sessionClosed dealy was interrupted");
}
}
super.sessionClosed(ioSession);
}

Perhaps there are better approaches. Is this a known race condition?
QuickfixJ 0|i000gv:
QuickFIX/J QFJ-803

Case spelling inconsistency among FIX dictionaries

Improvement Closed Minor Fixed ManuReno ManuReno ManuReno 26/Jul/14 17:58   21/Jul/15 15:21 21/Jul/15 15:21   1.6.1 Build   0 2   Mismatch in case spelling among fix dictionaries result in duplicates in messages-all.jar :

quickfix/field/IOIID.class
quickfix/field/IOIid.class

quickfix/field/LegUnitOfMeasure.class
quickfix/field/LegUnitofMeasure.class

quickfix/field/UnderlyingUnitOfMeasure.class
quickfix/field/UnderlyingUnitofMeasure.class

quickfix/field/UnitofMeasure.java
quickfix/field/UnitOfMeasure.java
0|i000h3:
QuickFIX/J QFJ-802

mvn message module : cut circular dependancy w/ core + merge sub-modules

Improvement Open Minor Unresolved ManuReno ManuReno ManuReno 16/Jul/14 22:13   12/Aug/14 12:29       Build   0 3   Core module currently depends on resources located in the messages modules (hidden dependancy), while messages module depend on core module (explicit dependancy).
This prevent from importing in Eclipse IDE without manual operations.

The object of the ticket is to check if :
* Dependancy can be declared such as core depends on messages, while cutting dependancy from messages to core
* Make one single message mvn module
0|i000hb:
QuickFIX/J QFJ-801

Validation fail on ClassCastException if using XML

Bug Open Default Unresolved Unassigned Benoit Xhenseval Benoit Xhenseval 14/Jul/14 10:56   14/Jul/14 16:08   1.5.3   Engine   0 2   Mac OSX It appears that the Message validation fails on a ClassCastException if the message contains the XmlDataLen tag.

Example:
https://gist.github.com/benoitx/e7da15dba9da133ac7b9

It seems that the validation code only expects StringField but the XmlDataLen is an IntField.

The output is:
{code}
Testing WITHOUT XML
8=FIXT.1.19=7935=649=Sender56=Target15=USD22=523=IOD-127=M28=N48=IBM.N54=255=IBM.N10=079
Testing WITH XML
8=FIXT.1.19=10335=649=Sender56=Target212=12213=<a>Hello</a>15=USD22=523=IOD-127=M28=N48=IBM.N54=255=IBM.N10=086
Exception in thread "main" java.lang.ClassCastException: quickfix.field.XmlDataLen cannot be cast to quickfix.StringField
at quickfix.DataDictionary.iterate(DataDictionary.java:668)
at quickfix.DataDictionary.validate(DataDictionary.java:653)
at quickfix.DataDictionary.validate(DataDictionary.java:624)
at quickfix.DataDictionary.validate(DataDictionary.java:606)
at fixfun.IOIValidation.validateIoi(IOIValidation.java:45)
at fixfun.IOIValidation.validateIoiWithXml(IOIValidation.java:37)
at fixfun.IOIValidation.main(IOIValidation.java:78)
{code}
validation 0|i000hj:
QuickFIX/J QFJ-800

jar signing issue with quickfixj-all-1.5.3.jar

Bug Closed Default Fixed Unassigned Hemlata Singh Hemlata Singh 10/Jul/14 09:52   02/Apr/15 23:22 11/Jul/14 12:15   1.6.0     0 2 _thumb_10568.png   windows and linux getting error while signing the jar.
command used:
jarsigner -keystore calypsoJAWS.key -storepass calypso quickfixj-all-1.5.3.jar calypso

ERROR :
jarsigner: unable to sign jar: java.util.zip.ZipException: duplicate entry: FIX40.xml

Tactical fix : Resolved by removing duplicate xml files.
0|i000hr:
QuickFIX/J QFJ-799

SessionTest : Assertion failure as a side effect of previous sessions not being closed

Other Closed Default Fixed ManuReno ManuReno ManuReno 05/Jul/14 15:31   02/Apr/15 23:22 08/Jul/14 14:13   1.6.0 Build   0 2   Windows 7-SP1, JDK 1.6.0_45, Eclipse Luna, Maven 3.2.2 SessionTest test cases fail in my environment (assertion failure on sequence number not being as expected)
This looks like the consequence of previous session file store not being deleted prior to running the test case. These file store can't be deleted unless the previous session used for test has been closed.
Since the session is a Closeable, I guess it should be closed at the end of each test case: by doing so tests run successfully every time.
0|i000hz:
QuickFIX/J QFJ-798

Refactor Session construction in test code

Improvement Open Default Unresolved Unassigned Andrzej Hajderek Andrzej Hajderek 13/Jun/14 16:47   13/Jun/14 16:47   1.5.3   Engine   0 2   Currently to create some of the Session related test cases it is necessary to use constructs like this:

Session session = new Session(new UnitTestApplication(), new MemoryStoreFactory(),
sessionID, null, null, new ScreenLogFactory(true, true, true),
new DefaultMessageFactory(), isInitiator ? 30 : 0, false, 30, true, resetOnLogon,
false, false, false, false, false, true, false, 1.5, null, validateSequenceNumbers,
new int[] { 5 }, false, disconnectOnError, false, true, false, true, false, null,
true, 0, false, false);

This kind of code turns from an asset into a liability pretty quickly, so the sooner it is rationalised the better. The Session constructor itself isn't very pretty either with its 30+ parameters.
0|i000i7:
QuickFIX/J QFJ-797

Add a clean and safe mechanism to disconnect a session from within a call-back

Improvement Open Default Unresolved Unassigned Andrzej Hajderek Andrzej Hajderek 13/Jun/14 15:33   13/Jun/14 15:33   1.5.3   Engine   0 2   Hi,

There is currently no clean and safe mechanism to completely stop and disconnect a session from within a call-back (e.g. when processing an incoming message inside fromApp()) with the effect that the session is immediately disconnected, no reject messages are sent back to the counter-party and no change to the session store is made.

Such a mechanism is useful for implementing failure handling scenarios, e.g. when a target database becomes suddenly unavailable, or the application needs to be shutdown in emergency. In such cases it's best to close the TCP socket immediately and keep the session state unchanged.

One could try to use something like SocketInitiatior.stop(true), but it's not generic (does not work for acceptors) and it results in a call to Session.disconnect(). Then, if Session.disconnect() is called from fromApp(), we get an immediate call to the onLogout() callback - a call is made from within the fromApp() call-back into the onLogout() call-back. This isn't a particularly safe scenario, especially when in most cases the onLogout() call is made by from QuickFIX/J threads.

Another solution is to throw a RuntimeException within the call-back method, but it's not reliable right now (QFJ-793, QFJ-795) and makes QuickFIX/J send an error message and the stack trace into the log.

I propose to add a special a subclass of RuntimeException, e.g. DisconnectSessionExcepion, which when thrown from a call-back method would notify QuickFIX/J that the session should be disconnected immediately. In such case only an informational message would be send to the log instead of error with a stack trace.

Regards,
Andrzej Hajderek
0|i000if:
QuickFIX/J QFJ-796

There is no mechanism to clear or update the data dictionary cache

Bug Open Default Unresolved Unassigned Andrzej Hajderek Andrzej Hajderek 13/Jun/14 14:57   13/Jun/14 16:22   1.5.3   Engine   0 2   A data dictionary file loaded into memory is cached without any option to reload the file after its contents has been updated. Worse - it's not even possible to clear the cache. This means that in order to use an updated data dictionary it is necessary to restart the application.

See: quickfix.DefaultSessionFactory.dictionaryCache
0|i000in:
QuickFIX/J QFJ-795

"MsgSeqNum too high" should not be an error

Bug Closed Default Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 13/Jun/14 14:18   02/Apr/15 23:22 18/Jun/14 16:08 1.5.3 1.6.0 Engine   0 2   Hi,

When QuickFIX/J receives a message with sequence number higher than expected it treats is as an error. For example:

<20140613-11:59:37, FIX.4.4:SENDER->TARGET, error> (MsgSeqNum too high, expecting 1 but received 101: 8=FIX.4.49=6635=B34=10149=TARGET52=20140613-11:59:3756=SENDER148=Headline10=005)

Not only an error message is logged, but also the internal logic will disconnect the counter-party, if DisconnectOnError=Y.

I believe this logic needs to be reviewed. According to the FIX protocol it is not an error to send/receive a message with too high sequence number. A too high sequence number should simply trigger a ResendRequest in order to retrieve the missing messages, which of course QuickFIX/J does.

There is a significant difference between receiving a message with too low sequence number and too high sequence number. While the first type of event is an error according to the FIX protocol, the second one isn't.

The "MsgSeqNum too high" should be an informational message, or arguably, a warning message - not an error message.

Regards,
Andrzej Hajderek
0|i000iv:
QuickFIX/J QFJ-794

Misleading message logged when RuntimeException thrown within a call-back: "Rejecting message: ..."

Bug Open Default Unresolved Unassigned Andrzej Hajderek Andrzej Hajderek 12/Jun/14 18:41   23/Aug/16 10:52   1.5.3   Engine   0 2   This is in relation to QFJ-793.

When both settings RejectMessageOnUnhandledException and DisconnectOnError are set to Y and a RuntimeException is thrown within a call-back, QuickFIX/J will write to the log output messages like below:

<20140612-16:25:06, FIX.4.4:SENDER->TARGET, error> (Rejecting message: java.lang.RuntimeException: ... (with more details and the message)

2014-06-12 18:25:06 quickfix.Session disconnect

INFO: [FIX.4.4:SENDER->TARGET] Disconnecting: Auto disconnect

This is misleading because nothing is actually rejected (no reject message is sent back to the sender). The session is simply disconnected. I believe a slightly different wording should be used for this scenario, e.g "Failed to process message" instead of "Rejecting message".
0|i000j3:
QuickFIX/J QFJ-793

When RuntimeException is thrown within a call-back and DisconnectOnError=Y the session does not get disconnected automatically

Bug Open Default Unresolved Unassigned Andrzej Hajderek Andrzej Hajderek 12/Jun/14 18:12   23/Aug/16 10:52   1.5.3   Engine   0 2   Hi,

When a RuntimeException is thrown within a call-back and the "DisconnectOnError" parameter is set to "Y" the session does not get disconnected automatically unless the "RejectMessageOnUnhandledException" parameter is also set to "Y". This dependency is not documented, but even if it was, it wouldn’t make too much sense.

It seems to be logical to understand an occurrence of a RuntimeException within a call-back as an error condition on its own, which should be sufficient to trigger the disconnection logic dictated by the "DisconnectOnError" parameter (regardless of any other settings).

Currently, if RejectMessageOnUnhandledException=N, the engine simply ignores the message for which the exception was thrown even though DisconnectOnError=Y (although it reports the exception as an “error” in the log).

Test code attached.

Please note that probably all call-backs exhibit the same behaviour, not just the fromApp() call-back used in the TestApp class. It is also possible that the “ResetOnError” parameter is treated in a similar manner.

Regards,
Andrzej Hajderek
0|i000jb:
QuickFIX/J QFJ-792

Wrong order of fields in a repeating group makes the group ignored

Bug Resolved Default Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 10/Jun/14 19:00   13/Apr/17 12:33 13/Apr/17 12:33 1.5.3 1.6.4 Engine   0 3   Hi,

Another issue related to repeating groups in the message parsing logic. If two fields within a repeating group are in different order than expected the entire repeating group is ignored. The parsed message does not contain the ignored repeating group.

The better approach would be to process the repeating group regardless of the order of fields or to report and error in order to signal the wrong order (assuming ValidateUnorderedGroupFields=Y).

Regards,
Andrzej Hajderek
0|i000jj:
QuickFIX/J QFJ-791

An unexpected field in a repeating group makes QuickFIX/J fail to detect the number of repeating groups correctly

Bug Resolved Default Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 10/Jun/14 17:32   05/Apr/17 09:08 05/Apr/17 09:07 1.5.3 1.6.4 Engine   0 2   Hi,

When an unexpected tag (a tag not defined in the data dictionary) is present in a repeating group QuickFIX/J fails to detect the number of repeating groups correctly. For example in the following message the unexpected tag 58 is present at the end of the first leg (600, 687, 654, 566, [58]):

8=FIX.4.4 9=233 35=AE 34=1 49=SENDER 52=20140610-15:04:53.377 56=TARGET 31=5.6789 32=1000 60=20140610-15:04:53.367 75=20140101 570=N 571=ABC1234 555=2 600=L1-XYZ 687=333 654=ABC1234-L1 566=1.2345 58=TXT1 600=L2-XYZ 687=777 654=ABC1234-L2 566=2.3456 10=017

With tag 58 in the first leg, the number of repeating groups detected by QuickFIX/J message parser will be 1 (incorrect)!
Remove tag 58 from the first leg and QuickFIX/J will sees the number of repeating groups for as 2 (correct).

This is very dangerous because it makes a QuickFIX/J applications very sensitive to changes in repeating groups. For example, when a trading platform decides to add a new tag to the repeating group, an existing application will fail completely because of the incorrect number of repeating groups detected. Instead the application should simply ignore the new tag, especially when AllowUnknownMsgFields=Y.

Of course when the new tag is added to the data dictionary this problem will not occur, however, the current behaviour of the repeating group parsing logic is inconsistent with the message body parsing logic, inconsistent with the configuration (AllowUnknownMsgFields=Y) and generally counter-intuitive.

Regards,
Andrzej Hajderek
0|i000jr:
QuickFIX/J QFJ-790

Logout message not propagated to the fromAdmin() callback

Bug Closed Default Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 09/Jun/14 17:15   22/May/15 16:30 07/Dec/14 02:15 1.5.3 1.6.0 Engine   0 3   Hi,

A QuickFIX/J based application may miss a Logout request message, if the sender closes the socket shortly after sending the Logout request message. As result the application may lose important information about the reason of disconnection.

Most likely the reason of such behaviour of QuickFIX/J is such that the QFJ Message Processor stops processing queued messages as soon as it detects hasResponder() == false, which may happen even, if the input queue contains messages (or merely the Logout message). Basically the more loaded the receiver's machine is (in terms of CPU/IO) the more likely it is that it misses the Logout message.

Please note that even though the fromAdmin() callback is not called in such cases, the onLogout() is always called (because of the the closed socket). However, multiple occurrences of the same sender-side series of events (Logout + socket close) will lead to two different receiver-side behaviours on a random basis. In some cases the receiver will see the proper fromAdmin() callback and the onLogout() callback, while in some cases it will see only the onLogout() callback (triggered by socket close rather than by the incoming Logout message).

This has been an issue since 1.0.x, but only now I found some time to write a proper test.

Test code attached.

Regards,
Andrzej Hajderek
0|i000jz:
QuickFIX/J QFJ-789

Fully support alternate encodings (charsets)

Bug Open Default Unresolved Unassigned amichair amichair 09/Jun/14 16:49   09/Jun/14 17:14   1.6.0       0 2   QuickFIX/J currently has limited support for alternate encodings (charsets). While it is 'good enough' for some cases, it still has drawbacks - it is limited to charsets that are a superset of ASCII (in particular, double-byte encodings are not supported), the encoding can only be set globally via CharsetSupport and applies to all fields (which can generate non-compliant messages), the engine still uses Strings for the most part with some awkward and inefficient handling to make it properly support encoded bytes, etc.

It would be better to have proper encoding support all around - with ASCII used for all standard fields, the MessageEncoding field used per-message to specify the encoding used in its Encoded* fields (e.g. EncodedText), using bytes array (or ByteBuffer) instead of Strings for more efficient and direct manipulation, supporting arbitrary charsets (not only ASCII supersets), etc.

Suggestions, additional related requirements and protocol-compliance corrections are welcome.
0|i000k7:
QuickFIX/J QFJ-788

StackOverflowError still an issue when processing larger queues

Bug Closed Major Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 06/Jun/14 20:23   02/Apr/15 23:22 06/Feb/15 11:57 1.5.3 1.6.0 Engine   0 2   Hi,

QuickFIX/J fails regularly with the StackOverfloError when processing large queues (around 1000 messages or more - depending on Java stack size).

A typical scenario:
- Client sends a ResendRequest to server
- Server is slow in delivering old messages, but keeps sending real-time messages quickly
- The queue builds up quickly
- After the last old message is resent by server the client starts processing the queue using recursion and it fails with the StackOverflowError.

This is reproducible with trunk revision #1187. Test code attached.

Regards,
Andrzej Hajderek
0|i000kf:
QuickFIX/J QFJ-787

OrderMassActionRequest (CA), OrderMassActionReport (BZ)

Bug Closed Critical Duplicate Unassigned Muhammad Rashad Irshad Khan Muhammad Rashad Irshad Khan 05/Jun/14 07:28   05/Jun/14 12:05 05/Jun/14 10:17 1.5.3   Engine, Message Generation   0 2   Do we have OrderMassActionRequest.java as I cannot use it in my FIX client for FIX5 SP1.
Please help me in this matter.
0|i000kn:
QuickFIX/J QFJ-786

First three fields getting truncated when converting from string to message using Message constructor

Bug Closed Critical Fixed Christoph John raghuram potluri raghuram potluri 03/Jun/14 19:31   02/Apr/15 23:22 12/Jun/14 13:22 1.5.3 1.6.0 Engine   0 2   windows when using below code sinppet either first or second or third tag getting truncated.

scenario 1:
public class TestMessage {

public static void main(String[] args) {
String st = "35=D12=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000";

quickfix.Message msg;
try {
msg = new Message(st,false);

System.out.println("original message"+st);
System.out.println("quickfixj message"+msg);
} catch (InvalidMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
}



}

}
Output =
original message 35=D12=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000
quickfixj message 9=13612=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.00010=232
First tag 35=D which was present in original string is missing after converting to message.

Scenario 2:
public class TestMessage {

public static void main(String[] args) {
String st = "8=FIX4.29=11012=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000";

quickfix.Message msg;
try {
msg = new Message(st,false);

System.out.println("original message "+st);
System.out.println("quickfixj message "+msg);
} catch (InvalidMessage e) {
// TODO Auto-generated catch block
e.printStackTrace();
}



}

}
Output:
original message 8=FIX4.29=11012=0.00000113=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.000
quickfixj message 8=FIX4.29=12413=215=HKD21=222=538=300040=148=2318.HK54=255=2318.HK58=<AP9211WDAM><USU><CHK> namke59=060=20140507-11:10:02.00010=182

Now you can see third tag which is 12=0.000001 is truncated.
0|i000kv:
QuickFIX/J QFJ-785

Test jira jrjc issue

Bug Closed Minor Not a bug Unassigned Siva Tharun Siva Tharun 27/May/14 07:09   27/May/14 10:14 27/May/14 10:14 1.5.2   Documentation   0 2   0|i000lb:
QuickFIX/J QFJ-784

quickfix.field package contains mix of various FIX versions

Bug Open Default Unresolved Unassigned amichair amichair 26/May/14 13:20   09/Jun/14 16:31   1.5.3       1 4   The FIX fields and messages classes are auto-generated from FIX spec xml files. Each FIX spec version has a corresponding jar created with its respective classes. The message package names contain the fix version (e.g. quickfix.fix44 package), so that a specific target version's messages can be used.

However, all field packages from all versions are simply named quickfix.field, so they cannot be targeted individually by code that needs them.

Worse, when all of these versioned packages are merged together into a single 'all' messages jar, the field classes overwrite each other in the quickfix.field package, which becomes a mix of classes from all versions. Seeing that the fields of newer versions are not entirely backwards-compatible with earlier versions (e.g. some field values/constants are renamed or removed), this package becomes compliant neither with the new versions or the old versions, and breaks existing client code when a new version is added (e.g. 5.0sp1/sp2) even if said code is intended to work only with and older spec version.

Worse still, the quickfix.field package is bundled not only in the quickfix-all jar but also in the quickfix-core jar, so they are not easily decoupled for users who want to select a specific target version jar to be used explicitly, or maintain a stable build unaffected by newer spec releases.

All these versions should ideally be decoupled from each other (and from core) in such a way that they can coexist in an application that must support multiple versions, and still remain compliant with each one of them independently.

These changes require additional research and have backward-compaibility implications. Currently the combined quickfix.field pakcage has the 5.0 spec classes trump all others (i.e. its classes take precedence when there are duplicates), to remain compatible with the previous release (even though new sp1/sp2 fields are added to the package as well).
0|i000lj:
QuickFIX/J QFJ-783

Update documentation and website to reflect new project setup

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 26/May/14 10:52   02/Apr/15 23:22 02/Apr/15 23:17   1.6.0 Documentation   0 1   Changes due to
* Maven
* github

* update the documentation on how to run the examples (Banzai, Executor)
* update the web site to point to the correct location for binary releases
0|i000lr:
QuickFIX/J QFJ-782

Get rid of cyclic package dependencies

Improvement Open Default Unresolved Unassigned Christoph John Christoph John 15/May/14 13:25   22/Jan/15 11:32     2.0-BETA     0 2   0|i000lz:
QuickFIX/J QFJ-781

Fix code generation for SP1/2 .

New Feature Closed Default Fixed amichair Carlos Carlos 07/May/14 19:09   02/Apr/15 23:22 09/Jun/14 16:31 1.5.3 1.6.0     0 3   Get the the generated code to have the new tags introduced by SP1 and SP2. 0|i000m7:
QuickFIX/J QFJ-780

QuickFixJ behavior for Acceptance test fix42/1a_ValidLogonMsgSeqNumTooHigh.def looks incorrect

Bug Open Default Unresolved Unassigned Tarun Bahadur Tarun Bahadur 01/May/14 21:02   23/Aug/16 10:52   1.5.3   Engine   0 2   QuickFixJ behavior for Acceptance test fix42/1a_ValidLogonMsgSeqNumTooHigh.def looks incorrect

After a resend request is received from server subsequent messages should be ignored unless SequenceReset is received or messages replayed. In below test case the logout message is sent with sequence number 6, this should actually be ignored by the server and the test case should fail. This would require fixing both QuickFixJ behavior and the test case(probably logout should have MsgSeqNum=1).

from fix42/1a_ValidLogonMsgSeqNumTooHigh.def
...
E8=FIX.4.29=5835=234=249=ISLD52=00000000-00:00:00.00056=TW7=116=410=0
I8=FIX.4.235=534=649=TW52=<TIME>56=ISLD
...

0|i000mf:
QuickFIX/J QFJ-779

Standardize line endings

Bug Closed Default Fixed Christoph John amichair amichair 01/May/14 14:58   02/Apr/15 23:22 05/May/14 14:16   1.6.0     0 2   Currently the source files (including xml files) have inconsistent line endings - some have LF and some CRLF. This makes it difficult to work with diffs/patches/merges/git-svn etc.

It would be best if you standardize on either LF or CRLF for everything (most source control systems standardize on LF in mixed environments, but it's up to you).

Among other solutions, you can use the 'file' utility to check the current state of files, and 'dos2unix' and 'unix2dos' to convert them.
0|i000mn:
QuickFIX/J QFJ-778

Multi broker quickfix initiator side

Other Closed Major Not a bug Unassigned Cristian Manuel Vertiz Fernandez Cristian Manuel Vertiz Fernandez 30/Apr/14 16:12   05/May/14 08:30 30/Apr/14 16:20 1.5.3   Build, Engine   0 2   I need to implement a multi broker (x, y ,z) quickfix initiator side session with different dictionary specification.
The quickfix engine is built respect to xml fix dictionary and some fields are required for "x" and "y" broker an not for "z" broker, and so on.
Suggest me, what I can do?
QuickfixJ, session 0|i000mv:
QuickFIX/J QFJ-777

Determine session's IP address

Improvement Closed Default Fixed Christoph John Daniil S Daniil S 15/Apr/14 17:31   02/Apr/15 23:22 17/Apr/14 17:02   1.6.0 Networking   0 2   Really need a way of determining IP address for the session. This is especially useful for incoming sessions. 0|i000n3:
QuickFIX/J QFJ-776

QuickFix/J Initiator fails to process messages without TargetCompID tag

Bug Closed Default Fixed Christoph John exgorth exgorth 25/Feb/14 14:16   02/Apr/15 23:22 27/Feb/14 13:56 1.5.3 1.6.0 Engine   0 1   ASXTrade24 (SFE) gateways don't use TargetCompID in the messaging (they are always one-to-one connections) as described in http://www.asx.com.au/documents/trading_services/asx-trade24-developer-guide-fix-spec.pdf.
Therefore QuickFix/J initator rejects response from the gateway, even though TargetCompID was set not to be mandatory field on the message header in xml DataDictionary
0|i000nb:
QuickFIX/J QFJ-775

FileStore: exception thrown when more than one : is used in SessionID

Bug Closed Default Fixed Christoph John Kosta Panousis Kosta Panousis 15/Feb/14 05:11   02/Apr/15 23:22 06/May/14 13:56 1.5.3 1.6.0 Engine   0 1   Windows When only the SenderSubId or TargetSubId contain a : the engine starts fine. However, when both SendSubId and TargetSubId contain colons : an exception is thrown and teh engine does not start.

For example:
SenderSubID=ABC:ABC
TargetSubID=TEST

OR

SenderSubID=ABC
TargetSubID=TEST:TEST

start fine but the following fails with (The filename, directory name, or volume label syntax is incorrect):

SenderSubID=ABC:ABC
TargetSubID=TEST:TEST

It looks like a windows problem with the : in the file names but I was hoping that something could be done to the engine to replace the : internally or another work around. Unfortunately, exchanges like the CBOE require colons in both those fields.
QuickfixJ, session 0|i000nj:
QuickFIX/J QFJ-774

SendRedundantResendRequests seems to be ignored

Bug Closed Default Not a bug Unassigned Bill Igoe Bill Igoe 13/Feb/14 17:06   14/Feb/14 16:11 14/Feb/14 16:11 1.5.3   Engine   0 1   Linux.. Fedora 19
Testing with the CME
Not sure if this is the right forum...but any help is appreciated as I have completed all the iLink test with the CME except for the handling if Resend Request.

below is my config


ConnectionType=initiator
ReconnectInterval=30
FileStorePath=/home/wigoe/FIX/messages
FileLogPath=/home/wigoe/FIX/logs
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
ValidateUserDefinedFields=N
ValidateFieldsHaveValues=N
ValidateIncomingMessage=N
DataDictionary=/home/wigoe/quickfixj/etc/cme/FIX42.xml


# standard config elements



[SESSION]

# inherit ConnectionType, ReconnectInterval and SenderCompID from default
BeginString=FIX.4.2
SenderCompID=9E8008N
SenderLocationID=US,IL
SenderSubID=Archi
TargetCompID=CME
TargetSubID=G
SocketConnectHost****************
SocketConnectPort=22101
HeartBtInt=30
SendRedundantResendRequests=N
#PersistMessages=Y
#SocketUseSSL=Y

Thest test proceeds as follows. I enter in one Limit order...works
I enter in a second order ....works
MY QF receives a resend request and responds with the resend the two orders....that is correct..

The CME ( being tricky) sends another Resend order
Even tho the the SendRedundantResendRequests=N

AND THE Event log say NOT sending another
QF sends a repeat...thus I fail the test.

here is the log

8=FIX.4.29=21135=D34=135149=9E8008N50=Archi52=20140213-15:05:25.94356=CME57=G142=US,IL1=TESTMA11=CME28721=138=1040=244=32157554=155=9159=060=20140213-15:05:25.898107=1NQM4167=FUT204=11028=Y1031=W9702=110=073
8=FIX.4.29=21135=D34=135249=9E8008N50=Archi52=20140213-15:05:33.96156=CME57=G142=US,IL1=TESTMA11=CME28821=138=1040=244=32157554=155=9159=060=20140213-15:05:33.960107=1NQM4167=FUT204=11028=Y1031=W9702=110=063
8=FIX.4.29=10235=234=69247369=135052=20140213-15:05:25.95949=CME50=G56=9E8008N57=ARCHI143=US,IL7=135116=010=072
8=FIX.4.29=23835=D34=135143=Y49=9E8008N50=Archi52=20140213-15:05:34.00656=CME57=G122=20140213-15:05:25142=US,IL1=TESTMA11=CME28721=138=1040=244=32157554=155=9159=060=20140213-15:05:25.898107=1NQM4167=FUT204=11028=Y1031=W9702=110=121
8=FIX.4.29=23835=D34=135243=Y49=9E8008N50=Archi52=20140213-15:05:34.00656=CME57=G122=20140213-15:05:33142=US,IL1=TESTMA11=CME28821=138=1040=244=32157554=155=9159=060=20140213-15:05:33.960107=1NQM4167=FUT204=11028=Y1031=W9702=110=111
8=FIX.4.29=10235=234=69248369=135052=20140213-15:05:33.98849=CME50=G56=9E8008N57=ARCHI143=US,IL7=135116=010=074
8=FIX.4.29=23835=D34=135143=Y49=9E8008N50=Archi52=20140213-15:05:34.10756=CME57=G122=20140213-15:05:25142=US,IL1=TESTMA11=CME28721=138=1040=244=32157554=155=9159=060=20140213-15:05:25.898107=1NQM4167=FUT204=11028=Y1031=W9702=110=123
8=FIX.4.29=23835=D34=135243=Y49=9E8008N50=Archi52=20140213-15:05:34.10756=CME57=G122=20140213-15:05:33142=US,IL1=TESTMA11=CME28821=138=1040=244=32157554=155=9159=060=20140213-15:05:33.960107=1NQM4167=FUT204=11028=Y1031=W9702=110=113
8=FIX.4.29=29535=834=69249369=135152=20140213-15:05:34.02349=CME50=G56=9E8008N57=ARCHI143=US,IL1=TESTMA6=011=CME28714=017=68279:117016620=037=6818357623338=1039=040=241=044=32157548=99816154=155=9159=060=20140213-15:05:34.022107=1NQM4150=0151=10167=FUT432=201402131028=Y1031=W10=064
8=FIX.4.29=29535=834=69250369=135252=20140213-15:05:34.03149=CME50=G56=9E8008N57=ARCHI143=US,IL1=TESTMA6=011=CME28814=017=68279:117016720=037=6818357623438=1039=040=241=044=32157548=99816154=155=9159=060=20140213-15:05:34.029107=1NQM4150=0151=10167=FUT432=201402131028=Y1031=W10=066
8=FIX.4.29=8035=034=135349=9E8008N50=Archi52=20140213-15:06:04.54856=CME57=G142=US,IL10=149
8=FIX.4.29=10535=134=69251369=135252=20140213-15:06:04.51049=CME50=G56=9E8008N57=ARCHI143=US,IL112=IDhrgedu9310=106
8=FIX.4.29=10535=134=69252369=135352=20140213-15:06:35.51449=CME50=G56=9E8008N57=ARCHI143=US,IL112=IDhrgedu9410=117

Any ideas?

Bill
0|i000nr:
QuickFIX/J QFJ-773

'MessageStore.reset()' called extraneously outside session time window

Improvement Closed Default Fixed Christoph John Tommy Hannon Tommy Hannon 12/Feb/14 16:02   02/Apr/15 23:22 16/Apr/14 16:41 1.5.3 1.6.0 Engine   0 2   The 'MessageStore.reset()' method is being called every second when beyond the session time window.

After reviewing the QF/J source code, the problem seems to be originating from the "QFJ Timer" thread calling 'Session.next()'. The following code appears at line 1748 of the 'quickfix/Session.java' class in QuickFIX/J 1.5.3 source code directory...

if (!checkSessionTime()) {
reset();
return;
}

Due to the timer thread, this occurs every second for every session and can be quite resource intensive... especially if there is a substantial number of sessions defined that are not within the configured session start/end times.
MessageStore, Session 0|i000nz:
QuickFIX/J QFJ-772

NPE in DataDictionary::isTrailerField

Bug Closed Default Fixed Christoph John Krzysztof Szalast Krzysztof Szalast 06/Feb/14 16:04   02/Apr/15 23:22 19/Mar/14 16:43 1.5.3 1.6.0     0 1   All In class DataDictionary: if expression "messageFields.get(TRAILER_ID)" returns null - NPE will be thrown.

I suggest to write this method just like isHeaderField method.

public boolean isTrailerField(int field) {
if (messageFields.get(TRAILER_ID) == null) {
return false;
}
return messageFields.get(TRAILER_ID).contains(field);
}
NullPointerException 0|i000o7:
QuickFIX/J QFJ-771

Session and Settings JMX beans cannot be registered more than once.

Bug Open Default Unresolved Unassigned Vladimir Tsanev Vladimir Tsanev 24/Jan/14 19:56   23/Aug/16 10:52   1.5.3       1 6   I need to register, unregister and then register again a Connector - but then the session and settings beans do not appear.

I looked at the source and the problem seems that the SessionJmxExporter's cache with registered sessionId's is not cleared.
ConnectorAdmin registers sessions only if they are not cached by sessionExporter - so the second time session do not show up.
jmx 0|i000on:
QuickFIX/J QFJ-770

Message fromString don't report about REPEATING_GROUP_FIELDS_OUT_OF_ORDER

Improvement Resolved Minor Fixed Christoph John Andrey Alekov Andrey Alekov 23/Jan/14 15:14   13/Apr/17 12:33 13/Apr/17 12:33 1.5.3 1.6.4 Engine   0 1   Windows 7.
Version: 6.1
Build: 7606 SP1

Eclipse.
Version: Juno Service Release 2
Build id: 20130225-0426
When I tried to parse message from String I faced with not expected behavior of method Message.fromString()

Source message in Repeating group have unordered tags and values. Example are below.
SOH replaced to pipe (|)
String test = new String("8=FIX.4.4|9=16858|35=d|49=1|34=2|52=20140117-18:20:26.629|56=3|57=21|322=388721|323=4|320=1|393=42|82=1|67=1|711=1|311=780508|309=text|305=8|463=FXXXXX|307=text|542=20140716|436=10.0|9013=1.0|9014=1.0|9017=10|9022=1|9024=1.0|9025=Y|916=20140701|917=20150731|9201=23974|9200=17|9202=text|9300=727|9301=text|9302=text|9303=text|998=text|9100=text|9101=text|9085=text|9083=0|9084=0|9061=579|9062=text|9063=text|9032=10.0|9002=F|9004=780415|9005=780503|10=128|");

When call fromString I see parsed message without any error.
8=FIX.4.4|9=100|35=d|34=2|49=1|52=20140117-18:20:26.629|56=3|57=21|67=1|82=1|320=1|322=388721|323=4|393=42|711=42|10=156|

I checked Message.Exception and found next "Out of order repeating group members, field=916"


Well, I found what in Message.parse method (line Message.java:485) written exception but not raised.

} catch (final FieldException e) {
exception = e;
}

Please fix to raise InvalidMessage instead filling this.exception to case below.
Message 0|i000ov:
QuickFIX/J QFJ-769

Use both FileLogFactory and ScreenLogFactory

Improvement Closed Default Won't Fix Unassigned Cristian Manuel Vertiz Fernandez Cristian Manuel Vertiz Fernandez 17/Jan/14 18:00   19/Jan/14 17:03 19/Jan/14 17:03 1.5.3       0 1   Allow to SocketInitiator and SocketAcceptor use both log ways, FileLogFactory and ScreenLogFactory to major control. QuickfixJ, session 0|i000p3:
QuickFIX/J QFJ-768

Improve FileLog.java so that Quickfix/j would produce different event&message log files.

Improvement Closed Default Won't Fix Unassigned macemers macemers 13/Jan/14 03:01   13/Jan/14 12:53 13/Jan/14 12:53 1.5.3   Message Generation   0 1   For now Quickfix/j create event&message log files for each session, such as FIX.4.2-xxx_xxx-xxx.event.log & FIX.4.2-xxx_xxx-xxx.messages.log But it would be helpful if it create these log files on daily basis, like FIX.4.2-xxx_xxx-xxx.event-yyyyMMdd.log & FIX.4.2-xxx_xxx-xxx.messages-yyyyMMdd.log 0|i000pb:
QuickFIX/J QFJ-767

StartTime/EndTime should be optional when NonStopSession=Y

Bug Closed Default Fixed Christoph John Nikitas Leogas Nikitas Leogas 03/Jan/14 23:57   02/Apr/15 23:22 06/Jan/14 12:50 1.5.3 1.6.0 Engine   0 1   Currently, the StartTime and EndTime parameters are expected to exist even if NonStopSession is set to Y. This should not be, since in that case these two parameters do not apply.

0|i000pj:
QuickFIX/J QFJ-766

FIX Resend Issue

Bug Closed Default Duplicate Christoph John Li,Wei Li,Wei 27/Dec/13 10:56   30/Dec/13 14:28 30/Dec/13 14:28 1.5.2   Engine   0 1   windows server 2008 r2 standard sp1 Currently our prod env occur an issue about FIX Resend.
1) Before 03:31:16.621, our quickfixj was disconnected by upstream fix engine.
2) On 03:31:16.621, we re-connected.
3) On 03:31:16.839, we(CT) send Resend Request with tag7=23152 and tag16=0.
4) On 03:31:17.541, our customer returned from 23152 to 23974, then they send us 34=23977 and 34=23978, but SKIPPED 23975 and 23976.
5) I found our quickfix found 23974 and 23975 from its own memory queue at the same time, but not found 23976. So our sides occur 'MsgSeqNum too high, expecting 23976 but received 23977', cannot receive subsequent orders.

<fix event log>
------------------------------------------------------------------
20131120-03:25:57.913: Disconnecting: Socket exception (/14.129.28.13:35416): java.io.IOException: An existing connection was forcibly closed by the remote host
20131120-03:25:57.991: Already disconnected: Socket exception (/14.129.28.13:35416): java.io.IOException: An existing connection was forcibly closed by the remote host
20131120-03:31:16.621: Accepting session FIX.4.2:CT->S_MHK from /14.129.28.13:36040

<fix message log>
------------------------------------------------------------------
20131120-03:31:16.621: 8=FIX.4.29=011435=A49=S_MHK56=CT34=2397450=desk143=N97=N122=20131120-03:31:1752=20131120-03:31:17108=6698=010=205
20131120-03:31:16.839: 8=FIX.4.29=76 35=A34=5219849=CT52=20131120-03:31:16.83956=S_MHK98=0108=6610=000
20131120-03:31:16.839: 8=FIX.4.29=77 35=234=5219949=CT52=20131120-03:31:16.83956=S_MHK7=2315216=010=024
20131120-03:31:16.917: 8=FIX.4.29=010235=049=S_MHK56=CT34=2397550=desk143=N97=N122=20131120-03:31:1752=20131120-03:31:1710=152
20131120-03:31:16.917: 8=FIX.4.29=011535=249=S_MHK56=CT34=2397650=desk143=N97=N122=20131120-03:31:1752=20131120-03:31:177=5212916=010=236

20131120-03:31:16.980: 8=FIX.4.29=025235=D49=S_MHK56=CT34=2315250=desk143=Y97=Y122=20131120-03:25:4052=20131120-03:31:1711=00000000000276593764-00000115=CNY38=190040=244=000000003.3500000047=P54=155=60166859=060=20131120-03:25:40100=SS526=MHK0127658108421=110=070
20131120-03:31:16.980: 8=FIX.4.29=025235=D49=S_MHK56=CT34=2315350=desk143=Y97=Y122=20131120-03:25:4052=20131120-03:31:1711=00000000000276593765-00000115=CNY38=250040=244=000000004.9800000047=P54=155=60002859=060=20131120-03:25:40100=SS526=MHK0127658105921=110=070
.............................
.............................
.............................
.............................
.............................
20131120-03:31:17.541: 8=FIX.4.29=025135=D49=S_MHK56=CT34=2397150=desk143=Y97=Y122=20131120-03:29:5452=20131120-03:31:1811=00000000000276597970-00000115=CNY38=20040=244=000000005.3000000047=P54=155=60189859=060=20131120-03:29:54100=SS526=MHK0127658108921=110=051
20131120-03:31:17.541: 8=FIX.4.29=025135=D49=S_MHK56=CT34=2397250=desk143=Y97=Y122=20131120-03:29:5452=20131120-03:31:1811=00000000000276597971-00000115=CNY38=10040=244=000000004.2100000047=P54=155=60001959=060=20131120-03:29:54100=SS526=MHK0127658105821=110=031
20131120-03:31:17.541: 8=FIX.4.29=025235=D49=S_MHK56=CT34=2397350=desk143=Y97=Y122=20131120-03:29:5752=20131120-03:31:1811=00000000000276597995-00000115=CNY38=270040=244=000000004.2700000047=P54=155=60180059=060=20131120-03:29:57100=SS526=MHK0127658108521=110=106
20131120-03:31:17.541: 8=FIX.4.29=010735=449=S_MHK56=CT34=23974 43=Y97=Y122=20131120-03:31:1852=20131120-03:31:1836=23977123=Y10=111
20131120-03:31:17.541: 8=FIX.4.29=025335=D49=S_MHK56=CT34=2397750=desk243=N97=N122=20131120-03:31:1852=20131120-03:31:1811=00000000000276599095-00000115=CNY38=70040=244=000000005.7000000047=P54=255=60037759=060=20131120-03:31:17100=SS526=MHK0127647435721=110=238
20131120-03:31:17.541: 8=FIX.4.29=011135=149=S_MHK56=CT34=2397850=desk243=N97=N122=20131120-03:31:1852=20131120-03:31:18112=R110=203

20131120-03:31:17.541: 8=FIX.4.29=7735=234=5224649=CT52=20131120-03:31:17.54156=S_MHK7=2397616=010=022



<fix event log>
------------------------------------------------------------------
20131120-03:31:17.339: Received SequenceReset FROM: 23466 TO: 23467
20131120-03:31:17.417: Received SequenceReset FROM: 23665 TO: 23666
20131120-03:31:17.479: Received SequenceReset FROM: 23887 TO: 23889
20131120-03:31:17.541: ResendRequest for messages FROM 23152 TO 23973 has been satisfied.
20131120-03:31:17.541: Processing queued message: 23974
20131120-03:31:17.541: Processing queued message: 23975

20131120-03:31:17.541: MsgSeqNum too high, expecting 23976 but received 23977: 8=FIX.4.29=25335=D34=2397743=N49=S_MHK50=kerridhu52=20131120-03:31:1856=CT97=N122=20131120-03:31:1811=00000000000276599095-00000115=CNY21=138=70040=244=000000005.7000000047=P54=255=60037759=060=20131120-03:31:17100=SS526=MHK0127647435710=190
20131120-03:31:17.541: Enqueued at pos 23977: 8=FIX.4.29=25335=D34=2397743=N49=S_MHK50=desk252=20131120-03:31:1856=CT97=N122=20131120-03:31:1811=00000000000276599095-00000115=CNY21=138=70040=244=000000005.7000000047=P54=255=60037759=060=20131120-03:31:17100=SS526=MHK0127647435710=190
20131120-03:31:17.541: Sent ResendRequest FROM: 23976 TO: 23976
20131120-03:31:17.541: MsgSeqNum too high, expecting 23976 but received 23978: 8=FIX.4.29=11135=134=2397843=N49=S_MHK50=kerridhu52=20131120-03:31:1856=CT97=N122=20131120-03:31:18112=R110=155
20131120-03:31:17.541: Enqueued at pos 23978: 8=FIX.4.29=11135=134=2397843=N49=S_MHK50=desk252=20131120-03:31:1856=CT97=N122=20131120-03:31:18112=R110=155
20131120-03:31:17.541: Already sent ResendRequest FROM: 23976 TO: 23976. Not sending another.
sequence, 0|i000pr:
QuickFIX/J QFJ-765

CheckSum error if the declared number of groups does not match the actual number of groups

Bug Closed Default Not a bug Christoph John Judit Kapinya Judit Kapinya 12/Dec/13 11:00   07/Jan/14 15:43 07/Jan/14 15:43 1.5.3   Engine   0 1   The scenario:

The initiator parses the following message with quickfix.MessageUtils.parse(), and sends it to the acceptor.

8=FIX.4.4|9=238|35=AE|31=1.35|32=1000|48=EURUSD|22=6|55=EURUSD|64=20131106|194=1.35|15011=1.33|15012=1.33|461=RCSXXX|487=2|571=1105200000001234|829=0|572=M1006050412587|552=1|54=1|37=SYS1:4545556002|11=SYS2:1006050412587|526=SSP:BDID001|453=2|448=a123456|447=D|452=3|802=2|523=5730607|803=10|523=5730606|803=15|1=123456-789|

It is not a valid FIX message, as we have 453<NoPartyIDs>=2, but there is only one group in the message. We would expect the acceptor to return a validation error, but instead the following happens:

1) An error message is logged:

2013-12-07 15:47:30,919 [SocketAcceptorIoProcessor-0.0] ERROR [] q.mina.acceptor.AcceptorIoHandler - Invalid message: Expected CheckSum=29, Received CheckSum=28 in 8=FIX.4.4?9=367?35=AE?34=82?49=SIDE1?52=20131207-14:47:30.618?56=SIDE2?22=6?31=1.35?32=1000?48=EURUSD?55=EURUSD?64=20131106?194=1.35?461=RCSXXX?487=2?571=1105200000001234?572=M1006050412587?829=0?15011=1.33?15012=1.33?552=1?54=1?37=SYS1:4545556002?11=SYS2:1006050412587?526=SSP:BDID001?453=2?448=a123456?447=D?452=3?802=2?523=5730607?803=10?523=5730606?803=15?1=123456-789?10=028?

2) The acceptor does not send any response and does not increase the message sequence count, either.

The suspect:

The acceptor validates the fix message with the checksum(String s) method of Message class. It calculates 29. But the checksum calculated on the initiator side is 28. The initiator calculates the checksum with a different method, which is called by the toString() method of Message class. This is the method which does the calculation (in FieldMap class) - my comments added:

int calculateTotal() {

int result = 0;
// JK: fields variable contains tags which are not group tags
for (final Field<?> field2 : fields.values()) {
final Field<?> field = field2;
if (field.getField() == CheckSum.FIELD || isGroupField(field.getField())) {
continue;
}
result += field.getTotal();
}

// JK: groups variable contains the group tags, but only the tag number (the key is Integer, not Field - why?)
final Iterator<Map.Entry<Integer, List<Group>>> iterator = groups.entrySet().iterator();
while (iterator.hasNext()) {
final Map.Entry<Integer, List<Group>> entry = iterator.next();
final List<Group> groupList = entry.getValue();
if (!groupList.isEmpty()) {
final IntField groupField = new IntField((entry.getKey()).intValue());
// JK: at this point we have 453=0, as this is a new field, no value yet
groupField.setValue(groupList.size());
// JK: now it is 453=1, because we have only one group
result += groupField.getTotal();
for (int i = 0; i < groupList.size(); i++) {
final Group group = groupList.get(i);
result += group.calculateTotal();
}
}
}

return result;
}

So the checksum will be the checksum of a different message actually, where 453=1.
0|i000pz:
QuickFIX/J QFJ-764

Create message class for XmlMessage (MsgType = 'n')

New Feature Open Default Unresolved Unassigned Isaac Levin Isaac Levin 11/Dec/13 21:18   12/Dec/13 14:13           0 1   Fix 4.4 defines XML Message (message type = 'n') that contains XmlData. There are XmlData and XmlDataLen classes in QuickFIX/J, but there is no actual class for XmlMessage. As a result calling MessageFactory.create(BEGIN_STRING, 'n') returns null 0|i000q7:
QuickFIX/J QFJ-763

Wrong constant values in NoSides

Bug Closed Default Fixed Christoph John Isaac Levin Isaac Levin 11/Dec/13 20:58   02/Apr/15 23:22 12/Dec/13 12:18 1.5.3 1.6.0 Message Generation   0 1   NoSides extends IntField, but constants for ONE_SIDE and BOTH_SIDES are defined as char.

public class NoSides extends IntField {
static final long serialVersionUID = 20050617;
public static final int FIELD = 552;
public static final char ONE_SIDE = '1';
public static final char BOTH_SIDES = '2';
...


When you call:
message.set(new NoSides(NoSides.ONE_SIDE));
Then the wrong value 49 (Ascii code of '1') instead of 1 is sent.

0|i000qf:
QuickFIX/J QFJ-762

Message stores can become corrupted on acceptor/initiator shutdown

Bug Open Default Unresolved Unassigned Alexey Ermakov Alexey Ermakov 09/Dec/13 17:00   21/Apr/17 21:52       Engine   1 3   Since MessageStore implementations aren't thread safe, all operations on them should be performed from the session thread only. However, all 4 acceptor and initiator implementations perform shutdown (and thus call Session.unregisterSessions) in the calling thread. Since that calls MessageStore.close(), it can easily lead to store corruption if, for example, FileStore.close() gets called while the session thread is in the middle of persisting a Logout response. 0|i000qn:
QuickFIX/J QFJ-761

Remove conversion from Message to String in Session.nextQueued()

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 09/Dec/13 11:34   02/Apr/15 23:22 09/Dec/13 12:26   1.6.0     0 1   Unnecessary conversion from Message to String in Session.nextQueued():

// TODO SESSION Is it really necessary to convert the queued message to a string?
next(msg.toString());


In method next(String msg) the message is parsed back to a Message, so the conversion is not only inefficient but also pointless.
0|i000qv:
QuickFIX/J QFJ-760

NullPointerException in Message.parseGroup

Bug Closed Default Fixed Christoph John Christoph John Christoph John 22/Nov/13 11:24   02/Apr/15 23:22 29/Nov/13 14:09 1.5.3 1.6.0 Engine   0 1   problem

java.lang.NullPointerException
at quickfix.Message.parseGroup(Message.java:600)
at quickfix.Message.parseBody(Message.java:569)
at quickfix.Message.parse(Message.java:480)
at quickfix.MessageUtils.parse(MessageUtils.java:148)

At that position in the code the result of extractField is NULL. This happens on parsing the message because the position counter is greater than the length of the message. Line 758 in Message.java:

if (position >= messageData.length()) {
return null;
}

This is expected in some cases when parsing groups.
However in this current problem it happened because there were problems with the message length and checksum which went undetected by the FixMessageDecoder.
The FixMessageDecoder checks if the message ends with a checksum, i.e. tag 10=xxx. The message in question ended with that information but the SOH delimiter before tag 10 was missing.
0|i000r3:
QuickFIX/J QFJ-759

"Timed out waiting for heartbeat" after receiving and sending TestRequest message

Bug Closed Major Cannot Reproduce Unassigned Wongsakorn Chantrapornsyl Wongsakorn Chantrapornsyl 13/Nov/13 10:30   04/Nov/16 08:02 13/Feb/14 12:24 1.5.0   Engine   0 2   Microsoft Windows Server The FIX application received the disconnection event from the FIX QuickJ after received and sent the TestRequest message so that the FIX application cannot reply the TestRequest message back to the FIX Server. Then the connection was disconnected.

From the FIX application log, it seems that FIX QuickJ received the HeartBeat message at sequence number 31934 (HeartBeat is not diaplayed in the log) but somehow FIX QuickJ does not reply the HeartBeat message back to the FIX Server.

Message log
----------------------------------------------------------------------------------------------
nformation 2013/11/12 10:04:12 Event Initiated logon request
Information 2013/11/12 10:04:11 Event Disconnecting
Warning 2013/11/12 10:04:11 Event Disconnecting: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=AE)
Warning 2013/11/12 10:04:11 Event quickfix.SessionException Logon state is not valid for message (MsgType=AE)
Information 2013/11/12 10:04:11 Event Sent test request TEST
Information 2013/11/12 10:04:11 Message <outgoing> (8=FIXT.1.19=15435=A34=3240849=TMSQ03226252=20131112-01:04:11.61456=TR MATCHING57=FXM142=TRFXMJP53776xxx98=0108=4553=DCUA554=*****789=319331137=91407=10010=055)
Information 2013/11/12 10:04:11 Event No responder, not sending message: 8=FIXT.1.19=10435=134=3240749=TMSQ03226252=20131112-01:04:11.11456=TR MATCHING57=FXM142=TRFXMJP53776xxx112=TEST10=167
Information 2013/11/12 10:04:11 Event Disconnecting
Warning 2013/11/12 10:04:11 Event Disconnecting: Timed out waiting for heartbeat
Information 2013/11/12 10:04:11 Message <outgoing> (8=FIXT.1.19=10435=134=3240749=TMSQ03226252=20131112-01:04:11.11456=TR MATCHING57=FXM142=TRFXMJP53776xxx112=TEST10=167)
Information 2013/11/12 10:04:10 Message <incoming> (8=FIXT.1.19=9035=134=319351128=949=TR MATCHING56=TMSQ03226252=20131112-01:04:10.409112=HBTO-3193510=223)
Information 2013/11/12 10:04:04 Message <incoming> (8=FIXT.1.19=65635=AE57=efx50=FXM34=319331128=949=TR MATCHING56=TMSQ03226252=20131112-01:04:04.6411003=267623544487=0573=0856=2325=Y828=54150=F880=29102046217=52d16b65-2909-0000-0000-0014c23f2fa5423=2075=2013111255=aud/usd167=FXSPOT60=20131112-01:04:04.51364=2013111415=AUD120=USD231=100000032=1854=131=0.9351056=9350001116=21117=BTMU TOKYO1118=C1119=131120=21121=TMSQ1122=251121=FTUA1122=21117=CITIBANK LONDON.1118=C1119=561120=11121=CITV1122=25552=154=21630=11631=01632=11633=5761634=USD1158=21164=5781=1782=SETTLEMENT THROUGH CLS783=C784=271164=4781=1782=CLS783=C784=271057=N37=10708811=1:298:1816938=110=117)
----------------------------------------------------------------------------------------------

We need to check with the FIX QuickJ why the FIX QuickJ does not response the HeartBeat message and notify the disconnection event improperly.
QuickfixJ, testRequest, timeout 0|i000rb:
QuickFIX/J QFJ-758

Improve log output on incoming connection

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 07/Nov/13 16:09   02/Apr/15 23:22 08/Nov/13 11:14 1.5.3 1.6.0 Engine   0 1   To ease the analysis of connection problems when working with multiple sessions/ports/log files it would be handy if there was a little more information given in one log line. This is especially necessary when grepping over multiple log files.

On an incoming connection the output is currently:
MINA session created: /10.0.173.12:12345
(this is the remote address)

But should be something like:
MINA session created: local=/10.0.173.12:23456, class org.apache.mina.transport.socket.nio.SocketSessionImp, remote=/10.0.173.12:12345
(this is more similar to the InitiatorIoHandler class)



0|i000rj:
QuickFIX/J QFJ-757

Data dictionary file 'FIX44.xml' field number 234 'StipulationValue' should allow "other" values

Bug Open Minor Unresolved Unassigned Tommy Hannon Tommy Hannon 05/Nov/13 22:35   05/Nov/13 22:35   1.5.3       0 2   The provided data dictionary file 'FIX44.xml' field number 234 'StipulationValue' should allow "other" values as described in FIX 4.4 specification (p. 86 of FIX 4.4 with Errata 20030618- Volume 6).

<field number="234" name="StipulationValue" type="STRING" allowOtherValues="true">
0|i000rr:
QuickFIX/J QFJ-756

Data dictionary file 'FIX44.xml' field number 233 'StipulationType' should allow "other" values

Bug Open Minor Unresolved Unassigned Tommy Hannon Tommy Hannon 05/Nov/13 22:32   05/Nov/13 22:32   1.5.3       0 2   The provided data dictionary file 'FIX44.xml' field number 233 'StipulationType' should allow "other" values as described in FIX 4.4 specification (p. 84 of FIX 4.4 with Errata 20030618- Volume 6).

<field number="233" name="StipulationType" type="STRING" allowOtherValues="true">
0|i000rz:
QuickFIX/J QFJ-755

FIX44.xml field number 139 'MiscFeeType' should be of type 'STRING'

Bug Closed Minor Duplicate Unassigned Tommy Hannon Tommy Hannon 05/Nov/13 22:08   31/Mar/14 21:50 31/Mar/14 21:50 1.5.3       0 2   FIX specification 4.4 added three values to the MiscFeeType (139) field that exceed the length of type 'CHAR'. This necessitates the type to be 'STRING' due to two-character values even though the FIX 4.4 specification still defines it as data type 'char'.

<!--field number="139" name="MiscFeeType" type="CHAR"-->
<field number="139" name="MiscFeeType" type="STRING">
0|i000s7:
QuickFIX/J QFJ-754

Session.logon() does not attempt to manually logon.

Bug Open Major Unresolved Unassigned Ming Liu Ming Liu 04/Nov/13 18:14   04/Nov/13 18:14   1.5.3       0 1   Session.logon does not attempt to manually logon. Logon message is sent only when reconnectInterval is up. 0|i000sf:
QuickFIX/J QFJ-753

Banzai example wrong handling of replaced orders

Bug Open Default Unresolved Unassigned Marin Bonacci Marin Bonacci 29/Aug/13 16:59   29/Aug/13 16:59   1.5.3   Examples   0 0   After sending Cancel/Replace request with modified quantity, the target sends PENDING_REPLACE ExecutionReport, then REPLACE ExecutionReport with new quantity. The application does't update order quantity, and interprets first ExecutionReport as a fill. 0|i000sn:
QuickFIX/J QFJ-752

Instrument component dont show the instrumentParties repeating group

Bug Open Major Unresolved Unassigned Christian Avalos Christian Avalos 30/Jul/13 20:26   31/Jul/13 08:58   1.5.3   Engine, Message Generation   0 1   the noInstrumentParties(1018) component is in the componentFields int array, and not in componentGroup, so, when it added a instrumentParties ,the generated message has the field 1018, but not the other possibles fields of instrumentParties (1019, 1050, 1051, 1052) QuickfixJ 0|i000sv:
QuickFIX/J QFJ-751

Incorrect handling of SequenceReset-GapFill messages when using ResendRequestChunkSize > 0

Bug Closed Default Fixed Christoph John Andrzej Hajderek Andrzej Hajderek 18/Jul/13 13:37   02/Apr/15 23:22 28/Mar/14 16:27 1.5.3 1.6.0 Engine   0 3   FIX 4.4, Initiator, ResendRequestChunkSize = 100 While performing a large session-layer recovery operation (around 1 million of messages) in chunks of 100 the QuickFIX/J engine got stuck, as it ignored a valid GapFill message:

18-07-13 08:56:50.673|QFJ Message Processor|INFO|quickfix: Received SequenceReset FROM: 1000102 TO: 1000103

18-07-13 08:56:50.673|QFJ Message Processor|ERROR|quickfix: MsgSeqNum too high, expecting 1000102 but received 1000103: 8=FIX.4.29=45135=834=100010343=Y49=ABFX52=20130718-08:56:50.66356=TEST_CLIENT122=20130718-00:09:001=B2BUSER60.STP6=0.816711=B2BCLIENT60-1374106069-1000102:014=4000015=EUR17=1374106069-100010220=021=131=0.816732=4000037=B2BCLIENT60-1374106069-1000102:038=4000039=240=D54=155=EUR/GBP60=20130718-00:08:54.57564=20140221109=B2BCLIENT60150=2151=0167=FOR194=0.82195=-0.003285544=GBP5549=AcmecoFXTest6054=32668.00999999=137413781066310=200

After analysis of the Session.nextSequenceReset() method it's clear that the incoming SequenceReset-GapFill message is handled differently when using non-zero ResendRequestChunkSize. Also, it looks like in this particular scenario the target sequence number has not been set (from 1000102) to newSequence (1000103) in the Session.nextSequenceReset() method, because:

1) range[2] was > 0 (which means using non-zero ResendRequestChunkSize)

AND

2) newSequence (1000103) was NOT >= range[1] (1084290)

AND

3) newSequence (1000103) was NOT >= range[2] (1000200)

[All values in the log below.]

It looks like the following logic needs to be reviewed because in the discussed scenario the newSequence value was completely ignored:


if (range[2] > 0) {
if (newSequence >= range[1]) {
state.setNextTargetMsgSeqNum(newSequence);
} else if (newSequence >= range[2]) {
state.setNextTargetMsgSeqNum(newSequence + 1);
final String beginString = sequenceReset.getHeader().getString(
BeginString.FIELD);
sendResendRequest(beginString, range[1] + 1, newSequence + 1, range[1]);
}
} else {
state.setNextTargetMsgSeqNum(newSequence);
}


The log is attached.
ResendRequest,, sequence, 0|i000t3:
QuickFIX/J QFJ-750

Receiving Logout with too high or too low sequence causes messages to be lost

Bug Closed Default Fixed Christoph John Niall Niall 11/Jul/13 20:20   02/Apr/15 23:22 18/Dec/13 15:15 1.5.3 1.6.0 Engine   0 1   For Loogout messages the "Too High" check is not done on the sequence number. If a Logout message with a sequence number that is too high is received, the NextTargetMsgSeqNum is still incremented anyway. This causes a message to be lost.

For example say the NextTargetMsgSeqNum=500 and a Logout message with MsgSeqNum=550 is received NextTargetMsgSeqNum gets incremented to 501. Then a Logon message is received with MsgSeqNum=551 a ResendRequest is sent for 501 to 550 and MsgSeqNum 500 is lost/never received.

In the nextLogout(Message) method I think modifying the increment statement to guard against this should avoid this situation:

{code}
int msgSeqNum = message.getInt(MsgSeqNum.FIELD);
if (!isTargetTooHigh(msgSeqNum)) {
state.incrNextTargetMsgSeqNum();
}
{code}
0|i000tb:
QuickFIX/J QFJ-749

Syntax error in SessionSettings.java/line 572 leading exception from java.util.regex

Bug Open Major Unresolved Unassigned Pavel Sagulenko Pavel Sagulenko 17/Jun/13 21:03   08/Jul/13 09:57   1.5.3   Engine   0 2   Eclipse 22 on Debian GNU/Linux 7.0 There is a syntax error in SessionSettings.java class, line 572.
original line: private final Pattern variablePattern = Pattern.compile("\\$\\{(.+?)}");
Should be: private final Pattern variablePattern = Pattern.compile("\\$\\{(.+?)\\}");

(with double slash before closing parenthesis).
This causes the failure in creating a SessionSettings instance.

I tried to recompile myself the corrected version, but I got the following exception:

java.lang.NoClassDefFoundError: quickfix.SessionSettings

Probably, you can suggest the possible solution.
Thank you!
QuickfixJ 0|i000tj:
QuickFIX/J QFJ-748

Configuration related issue for explicit setting of " StartDay and Endday " for "ConnectionType=initiator " in the qfixsessions.config file.

Other Closed Critical Not a bug Unassigned Shree Niwas Shree Niwas 13/Jun/13 09:58   13/Jun/13 11:15 13/Jun/13 10:03     Engine   0 2   I am trying to configure " StartDay" and "Endday " for "ConnectionType=initiator ". I need to configure the different setting for starting and ending Fix handler for different days of the week.
For Monday to Friday i want to have StartTime=21:35:00 and EndTime=21:32:00.
For Saturday and sunday i want to have StartTime=22:35:00 and EndTime=22:32:00..

How can i configure this explicity in the qfixsessions.config file.


QuickfixJ 0|i000tr:
QuickFIX/J QFJ-747

performance issue about fromApp() and toApp()

Other Closed Critical Not a bug Unassigned Li,Wei Li,Wei 05/Jun/13 08:00   11/Jun/13 09:23 11/Jun/13 09:23 1.5.2   Engine   2 2   win2008 r2 64bit, memory 32G, cpu 3.0GHz In our prod environment, using quick fix 1.5.2. Recently our upstream set up an algo trading system, it sends lots of DMA orders to our system. When concurrent pressures become high, we found high latency in incoming step and outgoing step.

We add some logs in fromApp() method to record callback timestamp, found between this timestamp and the timestamp of tag35=D have an average of 400ms delay, max delay is 2500ms. At outgoing step, toApp() method have same issue.

In our system, connection 9 sessions, two of them are doing algo trading by DMA, others do manual order trading.
performance 0|i000tz:
QuickFIX/J QFJ-746

Repeating Custom Tags Causes Parsing Error of Message

Bug Closed Default Not a bug Unassigned Talayeh Nili Talayeh Nili 31/May/13 01:50   03/Jun/13 11:22 03/Jun/13 11:22 1.5.2   Message Generation   0 2   software We are using QuicFIX J custom built functionality for parsing messages that we receive. We have custom tags with tag id in the 9000 ranges. These are allocation report messages and they can have a lot of these optional fields that we do not process, and some of them are nested and repeating. What I am seeing tis that when these tags are repeating, the QuickFIXJ is unable to read any fields after those set of tags.
Is this a known expected behaviour?

Example Message:
8=FIX.4.49=108635=AS34=183649=FCI-TNS56=CAPGROUP52=20130529-19:02:51453=2448=CPILGB2L447=B452=13802=1523=Capital Group Companies803=5448=BAMLPSWDCTM447=B452=1802=1523=Bank of America - BAMLPSWDCTM803=571=0794=3755=CPILGB2L136985417107987=09052=10137269169053=Y9057=MAGR857=054=2167=CORP6=98.86753=12460000381=12318828.2231=100.060=20130529-00:00:0075=2013052964=20130603157=166541=20180201223=1.570=27573200122=448=US828807CM76107=SIMON PROPERTY GROUP 144A LIFE SR UNSEC 1.5% 02-01-189061=49062=US828807CM769859=86181.679858=USD9874=29873=FLAT9865=EXEC9869=USD9866=09873=FLAT9865=TCOM9869=USD9866=078=379=000031467=7732620019047=2511221.880=2540000172=0169=285=1165=1781=1782=DTCYUS33783=B784=10801=0154=2528790.13742=17568.3312=013=379=000008467=7732820019047=6080320.580=6150000172=0169=285=1165=1781=1782=DTCYUS33783=B784=10801=0154=6122858742=42537.512=013=379=000078467=7732720019047=3727285.980=3770000172=0169=285=1165=1781=1782=DTCYUS33783=B784=10801=0154=3753361.73742=26075.8312=013=310=020


In this case, the allocations are not read. They start at tag 78. Right before tag 78, we see repeating tags 9865, 9869, 9866.
We have seen examples of this behaviour with other tags as well.
QuickfixJ 0|i000u7:
QuickFIX/J QFJ-745

"MsgSeqNum too high" error as result of "QFJ Message Processor" could parse income messages on SSL Connections

Bug Open Default Unresolved Unassigned Andrey Nalitkin Andrey Nalitkin 23/May/13 15:31   11/Jun/13 14:26   1.5.3   Networking   0 2   CentOS release 5.9 (Final)
Linux dev99 2.6.18-348.6.1.el5 #1 SMP Tue May 21 15:29:55 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)
QFJ Message Processor thread could parse income message queue and


Name: QFJ Message Processor
State: RUNNABLE
Total blocked: 1 Total waited: 8,038

Stack trace:
quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:104)
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:180)
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
org.apache.mina.filter.support.SSLHandler.flushScheduledEvents(SSLHandler.java:275)
org.apache.mina.filter.SSLFilter.filterWrite(SSLFilter.java:512)
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:361)
org.apache.mina.common.support.AbstractIoFilterChain.access$1300(AbstractIoFilterChain.java:53)
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:659)
org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolEncoderOutputImpl.doFlush(ProtocolCodecFilter.java:369)
org.apache.mina.filter.codec.support.SimpleProtocolEncoderOutput.flush(SimpleProtocolEncoderOutput.java:97)
org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:215)
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:361)
org.apache.mina.common.support.AbstractIoFilterChain.access$1300(AbstractIoFilterChain.java:53)
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:659)
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterWrite(AbstractIoFilterChain.java:587)
org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:361)
org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIoFilterChain.java:355)
org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketSessionImpl.java:166)
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:177)
org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:168)
quickfix.mina.IoSessionResponder.send(IoSessionResponder.java:47)
quickfix.Session.send(Session.java:2483)
- locked java.lang.String@73013e68
quickfix.Session.sendRaw(Session.java:2414)
quickfix.Session.generateHeartbeat(Session.java:1827)
quickfix.Session.next(Session.java:1800)
quickfix.Session.next(Session.java:1101)
quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
java.lang.Thread.run(Thread.java:662)
sequnece, ssl, testRequest 0|i000uf:
QuickFIX/J QFJ-744

FIX44.xml is missing fields 201 and 315 (PutOrCall and UnderlyingPutOrCall)

Bug Closed Default Fixed Grant Birchmeier Grant Birchmeier Grant Birchmeier 20/May/13 18:54   02/Apr/15 23:22 20/May/13 21:49 1.5.3 1.6.0 Metadata/Specs   0 1   Originally found this in QF/n specs. QF/j also has the bug, which makes sense, since I think QF/n stole its specs from QF/j.

For needed changes, see what we did to QF/n:
https://github.com/connamara/quickfixn/commit/e3fd7aeb47709d97faa594ec57cd16567147e006

It's a pretty easy fix.
0|i000un:
QuickFIX/J QFJ-743

JdbcLog doesn't take into consideration the sessionID to verify if a parameter is set like JdbcMessage does

Bug Open Default Unresolved Unassigned Leandro Garcia Herrera Leandro Garcia Herrera 13/May/13 22:20   06/Nov/15 20:22   1.5.3   Engine   1 4   Windows 7, using JBoss and camel-quickfix I'm trying to configure JdbcLogFactory dynamically passing a SessionSettings object as argument to constructor. All my configurations are under an especific session ID and I have no configurations under default session.

Looking at the source code of JdbcLog I was able to confirm that only the default session configurations are taken into consideration instead of checking first in session ID configurations informed via constructor, wich I was expecting.

The JdbcStore class does this verification by session ID and I think JdbcLog should work in the same way.
JdbcLog, QuickfixJ, jdbc 0|i000v3:
QuickFIX/J QFJ-742

If the first field of a type is a group - it will not build the group

Bug Closed Default Fixed Christoph John Peter Metcalf Peter Metcalf 09/May/13 19:23   02/Apr/15 23:22 19/Mar/14 17:52 1.5.3 1.6.0 Engine   0 2   in parseGroup method in Message.java - it checks if it's parsing the first field and sets it. But if this is a group groupDataDictionary.isGroup(msgType, field.getField()), the group parsing never happens. Adding the following code after "previousOffset = -1;" resolves the issue:
if (groupDataDictionary.isGroup(msgType, field.getField())) {
parseGroup(msgType, field, groupDataDictionary, group);
}
0|i000vb:
QuickFIX/J QFJ-741

Missing value 99 for Tag 796 in FIX44.xml

Bug Open Default Unresolved Unassigned Po Fong Po Fong 08/May/13 22:15   08/May/13 22:15   1.5.3   Metadata/Specs   0 1   Linux Quickfix J will always reject a J cancel/replace messge with tag 796=99 due to missing <value enum="99" description="OTHER"/> in FIX44.xml. QuickfixJ 0|i000vj:
QuickFIX/J QFJ-740

Replace StringBuffer with StringBuilder

Improvement Closed Default Fixed Christoph John Peter Lawrey Peter Lawrey 24/Apr/13 15:48   02/Apr/15 23:22 18/Mar/14 16:19 1.5.3 1.6.0 Engine   0 2   In 2004 Java 5.0 was released with a note in StringBuffer's Javadoc

> As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

Perhaps its is time to use StringBuilder as it is a drop in replacement. esp as this class is used heavily.
0|i000vr:
QuickFIX/J QFJ-739

How can stop file logging in quickfixj??

Other Closed Critical Not a bug Unassigned Mansoor Haider Mansoor Haider 17/Apr/13 03:32   17/Apr/13 10:25 17/Apr/13 10:25 1.5.2   Engine   0 1   Windows I want to stop logging to make the application more faster. Is there any way to stop logging in quickfixj?? QuickfixJ 0|i000vz:
QuickFIX/J QFJ-738

Deadlock on disconnect

Bug Closed Major Fixed Christoph John Alexander Kormushin Alexander Kormushin 15/Apr/13 16:12   02/Apr/15 23:22 13/Feb/14 12:52 1.5.1 1.6.0 Engine   0 2   Windows 7, Java SE 1.6.0_30 I'm starting quickfixj acceptor and initiator in the same thread. For test purposes only. Don't know whether it is a valid use case. Will appreciate any thoughts on this.

From time to time following deadlock occurs:
{code}
Found one Java-level deadlock:
=============================
"QFJ Message Processor":
waiting to lock monitor 0x000000000702f0b0 (object 0x00000007c39b1230, a java.lang.Object),
which is held by "QFJ Timer"
"QFJ Timer":
waiting to lock monitor 0x00000000070323e0 (object 0x00000007c39f11d0, a java.lang.String),
which is held by "QFJ Message Processor"

Java stack information for the threads listed above:
===================================================
"QFJ Message Processor":
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.doWrite(VmPipeFilterChain.java:192)
- waiting to lock <0x00000007c39b1230> (a java.lang.Object)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.filterWrite(AbstractIoFilterChain.java:631)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:445)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1400(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:824)
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolEncoderOutputImpl.doFlush(ProtocolCodecFilter.java:436)
at org.apache.mina.filter.codec.support.SimpleProtocolEncoderOutput.flush(SimpleProtocolEncoderOutput.java:112)
at org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:237)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:445)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1400(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:824)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterWrite(AbstractIoFilterChain.java:727)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:445)
at org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIoFilterChain.java:436)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireEvent(VmPipeFilterChain.java:100)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.flushEvents(VmPipeFilterChain.java:65)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.pushEvent(VmPipeFilterChain.java:56)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireFilterWrite(VmPipeFilterChain.java:141)
at org.apache.mina.transport.vmpipe.support.VmPipeSessionImpl.write0(VmPipeSessionImpl.java:146)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:149)
at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:135)
at quickfix.mina.IoSessionResponder.send(IoSessionResponder.java:47)
at quickfix.Session.send(Session.java:2322)
- locked <0x00000007c39f11d0> (a java.lang.String)
at quickfix.Session.sendRaw(Session.java:2253)
at quickfix.Session.generateLogon(Session.java:2196)
at quickfix.Session.nextLogon(Session.java:2001)
at quickfix.Session.next(Session.java:958)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:662)
"QFJ Timer":
at quickfix.Session.getResponder(Session.java:508)
- waiting to lock <0x00000007c39f11d0> (a java.lang.String)
at quickfix.Session.hasResponder(Session.java:518)
at quickfix.mina.AbstractIoHandler.sessionClosed(AbstractIoHandler.java:95)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.sessionClosed(AbstractIoFilterChain.java:677)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:321)
at org.apache.mina.common.support.AbstractIoFilterChain.access$800(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionClosed(AbstractIoFilterChain.java:781)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:321)
at org.apache.mina.common.support.AbstractIoFilterChain.access$800(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionClosed(AbstractIoFilterChain.java:781)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.sessionClosed(AbstractIoFilterChain.java:599)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:321)
at org.apache.mina.common.support.AbstractIoFilterChain.fireSessionClosed(AbstractIoFilterChain.java:313)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireEvent(VmPipeFilterChain.java:124)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.flushEvents(VmPipeFilterChain.java:65)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.pushEvent(VmPipeFilterChain.java:56)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireSessionClosed(VmPipeFilterChain.java:159)
at org.apache.mina.common.support.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:233)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.doClose(VmPipeFilterChain.java:240)
- locked <0x00000007c39b1230> (a java.lang.Object)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.filterClose(AbstractIoFilterChain.java:644)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1500(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterClose(AbstractIoFilterChain.java:830)
at org.apache.mina.common.IoFilterAdapter.filterClose(IoFilterAdapter.java:98)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1500(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterClose(AbstractIoFilterChain.java:830)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterClose(AbstractIoFilterChain.java:732)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.fireFilterClose(AbstractIoFilterChain.java:456)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireEvent(VmPipeFilterChain.java:128)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.flushEvents(VmPipeFilterChain.java:65)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.pushEvent(VmPipeFilterChain.java:56)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireFilterClose(VmPipeFilterChain.java:135)
at org.apache.mina.transport.vmpipe.support.VmPipeSessionImpl.close0(VmPipeSessionImpl.java:140)
at org.apache.mina.common.support.BaseIoSession.close(BaseIoSession.java:119)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.doClose(VmPipeFilterChain.java:241)
- locked <0x00000007c39b1230> (a java.lang.Object)
at org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.filterClose(AbstractIoFilterChain.java:644)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1500(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterClose(AbstractIoFilterChain.java:830)
at org.apache.mina.common.IoFilterAdapter.filterClose(IoFilterAdapter.java:98)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1500(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterClose(AbstractIoFilterChain.java:830)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterClose(AbstractIoFilterChain.java:732)
at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterClose(AbstractIoFilterChain.java:464)
at org.apache.mina.common.support.AbstractIoFilterChain.fireFilterClose(AbstractIoFilterChain.java:456)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireEvent(VmPipeFilterChain.java:128)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.flushEvents(VmPipeFilterChain.java:65)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.pushEvent(VmPipeFilterChain.java:56)
at org.apache.mina.transport.vmpipe.support.VmPipeFilterChain.fireFilterClose(VmPipeFilterChain.java:135)
at org.apache.mina.transport.vmpipe.support.VmPipeSessionImpl.close0(VmPipeSessionImpl.java:140)
at org.apache.mina.common.support.BaseIoSession.close(BaseIoSession.java:119)
at quickfix.mina.IoSessionResponder.disconnect(IoSessionResponder.java:69)
at quickfix.Session.disconnect(Session.java:1918)
- locked <0x00000007c39a3358> (a java.lang.String)
at quickfix.Session.next(Session.java:1790)
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:283)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Found 1 deadlock.
{code}
0|i000w7:
QuickFIX/J QFJ-737

Use current JDK for compilation of QuickFIX/J and discontinue JDK 1.4 compatibility

Improvement Closed Default Fixed Christoph John Christoph John Christoph John 21/Mar/13 10:04   02/Apr/15 23:22 02/Dec/13 09:48   1.6.0 Build, Engine   2 3   We need to discuss which JDK to use. Either JDK6 or JDK7 with JDK6-compatibility switch (since JDK7 compiled code is not backwards binary-compatible). Since we are not using any JDK7 language features yet, the JDK6 compilation should be sufficient.


steps
* removed retrotranslator usage from build
* removed Java4 libs from source tree
* re-enabled tests which were ignored due to JDK1.4 usage on release build
0|i000wf:
QuickFIX/J QFJ-736

performance improvement: Modify the code to use StringBuilder instead of StringBuffer in calculateString method of FieldMap

Improvement Closed Default Fixed Christoph John Srinivas Kirti Teja Rao Srinivas Kirti Teja Rao 18/Mar/13 19:26   02/Apr/15 23:22 14/Mar/14 18:25 1.5.2 1.6.0 Engine   0 2   The calculate string method expects a StringBuffer and does all the concatenation on this object. This can be changed to StringBuilder to improve performance. All most of the applications want to log an incoming or outgoing messages and improvement in this calculate string can help them.

protected void calculateString(StringBuffer buffer, int[] preFields, int[] postFields)
0|i000wn:
QuickFIX/J QFJ-735

in quickfixj-v1.5.3, I cannot find 'Order Mass Action Request' with MsgType="CA"

Bug Closed Default Duplicate Unassigned Roger Deng Roger Deng 14/Mar/13 07:12   05/Jun/14 10:26 05/Jun/14 10:26 1.5.3 1.6.0 Message Generation   0 2   Windows/Linux in quickfixj-v1.5.3, I cannot find 'Order Mass Action Request' with MsgType="CA" :
Do we have OrderMassActionRequest.java file?
FIX.5.0SP1 Message
OrderMassActionRequest [type 'CA']
<OrdMassActReq>
QuickfixJ 0|i000wv:
QuickFIX/J QFJ-734

Properties for configuring Proxool vs. not incremented outgoing sequence number

Improvement Open Major Unresolved Unassigned Krzysztof Szalast Krzysztof Szalast 13/Mar/13 13:41   13/Mar/13 14:03   1.5.3   Engine   0 3   All I want to remind about comment in quickfix.JdbcUtil in method "static synchronized DataSource getDataSource(String jdbcDriver, String connectionURL, String user, String password, boolean cache)":
// TODO JDBC Make these configurable
setMaximumActiveTime(ds, 5000);
ds.setMaximumConnectionLifetime(28800000);
ds.setMaximumConnectionCount(10);
ds.setSimultaneousBuildThrottle(10);

If "messages" table are locked longer than 5 seconds, connection is aborted by Proxool:
[13.03.2013|12:42:07:875] [HouseKeeper] [DEBUG] [proxool.quickfixj-1] [org.logicalcobwebs.proxool.ConnectionPool] [removeProxyConnection] [441] : 000026 (01/02/00) - #0001 removed because it has been active for too long.
[13.03.2013|12:42:07:875] [HouseKeeper] [WARN ] [proxool.quickfixj-1] [org.logicalcobwebs.proxool.HouseKeeper] [sweep] [149] : #0001 was active for 98688 milliseconds and has been removed automaticaly. The Thread responsible was named 'QFJ Timer', but the last SQL it performed is unknown because the trace property is not enabled.
[13.03.2013|12:42:07:906] [QFJ Timer] [ERROR] [quickfixj.errorEvent] [quickfix.SLF4JLog] [logError] [147] : Error Reading/Writing in MessageStore
java.io.IOException: Couldn't perform the operation prepareStatement: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs).
at quickfix.JdbcStore.set(JdbcStore.java:252)
at quickfix.SessionState.set(SessionState.java:308)
at quickfix.Session.sendRaw(Session.java:2313)
at quickfix.Session.generateHeartbeat(Session.java:1861)
at quickfix.Session.next(Session.java:1834)
at quickfix.mina.SessionConnector$SessionTimerTask.run(SessionConnector.java:283)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: Couldn't perform the operation prepareStatement: You can't perform any operations on this connection. It has been automatically closed by Proxool for some reason (see logs).
at org.logicalcobwebs.proxool.WrappedConnection.invoke(WrappedConnection.java:207)
at org.logicalcobwebs.proxool.WrappedConnection.intercept(WrappedConnection.java:87)
at $java.sql.Wrapper$$EnhancerByProxool$$a5ac9e8b.prepareStatement(<generated>)
at quickfix.JdbcStore.set(JdbcStore.java:245)
... 14 more

and outgoing sequence number is not incremented! Next outgoing message has the same sequence number (sic!).

Scenario:
1. Send NOS message.
2. Lock "messages" table (on Postgres: LOCK TABLE messages IN ACCESS EXCLUSIVE MODE)
3. Send NOS message - message will be sent, but stacktrace from above will be happen. For example message has t34=666
4. Send NOS message - message will be sent with t34=666 (!)
0|i000x3:
QuickFIX/J QFJ-733

Provide customisable hooks into the core QuickFIX/J workflow

Improvement Open Default Unresolved Unassigned Ryan Lea Ryan Lea 11/Mar/13 01:34   21/Mar/13 00:13   1.5.3   Engine   0 1   Background:
I have been using QuickFIX for some time and found it a great library. As my usage has increased, I have become more aware that it's not necessarily GC-friendly. As such I'm in the process of extending the Message object to become more GC-friendly, but really a step away from the message type-safety that is currently present within QuickFIX/J.

In order to achieve my goal, I have made (what I consider) minor modifications to the core codebase to provide locatable service lookups where need be,

Improvement:
It would be great if QuickFIX/J was more customisable in the services that were able to be overriden/extended or generally customised. I've currently created a (very simple - based on http://martinfowler.com/articles/injection.html) ServiceLocator that prepares services with defaults (current 1.5.3 behaviour) that can be overriden with custom services on startup (if required).

The services that I have currently customised are:
# Message validation with the Data Dictionary
# Message creation from String (the FIXMessageDecoderFactory)
# Handling of FIX Messages within the abstract IoHandler (as it depends upon MINA passing it a String)


This approach seemed less intrusive than a DI framework, and perhaps a simpler fit into QuickFIX core. It provides the benefits of maintaining a library that can be used out of the box, whilst providing the capability of customisation where required or necessary.

I'd be mostly interested to know whether this (or something like it) would be considered as part of the roadmap with QuickFIX/J and how or whether I would be able to contribute.
QuickfixJ, modules, performance 0|i000xb:
QuickFIX/J QFJ-732

Unable to parse messages when the first tag inside the group is another group

Bug Closed Critical Duplicate Unassigned Srinivas Kirti Teja Rao Srinivas Kirti Teja Rao 05/Mar/13 02:45   13/May/13 12:38 13/May/13 12:38 1.5.2   Engine   0 3   java 6, windows The function parseGroup(String msgType, StringField field, DataDictionary dd, FieldMap parent) in quickfix.Message.java does not consider a case where the first tag in the group is another group.
The code to parse the inner group is in else for a condition to check is that is a first field. Becuase the inner group is the first element, it does not prase the inner group anymore.

if (field.getTag() == firstField) {
if (group != null) {
parent.addGroupRef(group);
}
group = new Group(groupCountTag, firstField, groupDataDictionary.getOrderedFields());
group.setField(field);
firstFieldFound = true;
previousOffset = -1;
} else{
//there is code here to handle prasing the inner group.
}
I looked at the fix specification to see if that is a valid message, having a group as first tag in another group, I think it is allowed. I am using FIX 4.2 spec for this.

The simple but not the best fix is to pull the code out of the else and let is execute for the first field as well.
0|i000xr:
QuickFIX/J QFJ-731

QuickFIXJ 1.5.3 does NOT support 5.0SP1

Bug Closed Major Incomplete Unassigned Roger Deng Roger Deng 21/Feb/13 04:37   16/Dec/13 23:13 16/Dec/13 23:13         0 1   Windows I used QuickFix/J examples:
(1) executor as the server;
[default]
FileStorePath=examples/target/data/executor
ConnectionType=acceptor
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=30
ValidOrderTypes=1,2,F
SenderCompID=EXEC
TargetCompID=BANZAI
UseDataDictionary=Y
DefaultMarketPrice=12.30

[session]
BeginString=FIXT.1.1
DefaultApplVerID=FIX.5.0SP1
SocketAcceptPort=9881

(2) banzai as the client;
[default]
FileStorePath=examples/target/data/banzai
ConnectionType=initiator
SenderCompID=BANZAI
TargetCompID=EXEC
SocketConnectHost=localhost
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=30
ReconnectInterval=5

[session]
BeginString=FIXT.1.1
DefaultApplVerID=FIX.5.0SP1
SocketConnectPort=9881


QuickfixJ 0|i000xz:
QuickFIX/J QFJ-730

Wrong SeqNum in the last Sequence Reset message after a Resend Request

Bug Closed Major Fixed Flakron Vranovci Damien Vidal Damien Vidal 18/Feb/13 15:19   21/Apr/16 13:40 04/Jan/16 14:13 1.5.3 1.6.2     0 3   Eclipse, Windows In the function nextResendRequest(Message resendRequest) you have this code at the end of the loop

if (begin != 0) {
generateSequenceReset(begin, msgSeqNum + 1);
}

if (endSeqNo > msgSeqNum) {
endSeqNo = endSeqNo + 1;
final int next = state.getNextSenderMsgSeqNum();
if (endSeqNo > next) {
endSeqNo = next;
}
generateSequenceReset(beginSeqNo, endSeqNo);
}



=> when you are on the case generating two Sequence Reset at the end of resend request you have an issue of FIX(34) in the last Sequence Reset:

Sequence Reset Message 1 begin != 0 => FIX(34)=begin => OK
Sequence Reset Message 2 endSeqNo > msgSeqNum => FIX(34)=beginSeqNo but beginSeqNo < begin => critical error in protocol it have to be FIX(34)=msgSeqNum+1 ( value sent in the message 1 with NewNoSeq=msgSeqNum+1)

ResendRequest, 0|i000y7:
QuickFIX/J QFJ-729

Allow MessageCrackers to handle polymorphic Message types

Improvement Open Default Unresolved Unassigned S Raf S Raf 07/Feb/13 13:13   07/Feb/13 13:13   1.5.3   Engine   0 1   The MessageCracker expects an invoker to be registered for the specific actual Message type being processed. If an invoker exists for a supertype of the received Message, the invoker won't be called.

For those extending MessageCracker, the onMessage(quickfix.Message message, SessionID sessionID) method can be overridden to allow implementers to handle the most general quickfix.Message type (but not, for example, only quickfix.fix44.Message messages).

However, for those providing a delegate object to the MessageCracker, there is no option to provide a handler for a more general Message type to provide custom fallback logic.

The crack(..) method should look for invokers registered for the received Message's superclass(es), as well as its actual type, before resorting to the fallback onMessage call in MessageCracker.
0|i000yf:
QuickFIX/J QFJ-728

SessionState is leaking memory when dealing with resends and sequence numbers are skipped due to a SequenceReset

Bug Closed Critical Fixed Christoph John Thilo-Alexander Ginkel Thilo-Alexander Ginkel 05/Feb/13 13:48   02/Apr/15 23:22 19/Dec/13 18:13 1.5.1, 1.5.3 1.6.0 Engine   2 3   JDK 1.7 When QuickFIX/J has to deal with ResendRequests (e.g., due to sequence number gaps or exceptions thrown by the client), the SessionState.messageQueue will grow and fill up with entries until the ResendRequest has been fulfilled, but will never clean up these queue entries later. Eventually this will consume all available heap (if no disconnect happen in between, which would clear the queue) and cause an OOM.

To reproduce this issue, subscribe to market data and raise an exception with a certain probability (e.g., every 100th message). Depending on the incoming message volume the messageQueue will fill up pretty quickly and won't release its content after the ResendRequest has been satisfied.
0|i000yn:
QuickFIX/J QFJ-727

build failure due to invalid character in source files

Bug Closed Default Fixed Christoph John amichair amichair 21/Jan/13 01:50   02/Apr/15 23:22 06/May/14 08:22 1.5.3 1.6.0 Build   0 2   Kubuntu 12.10, Oracle JDK 1.7.0_11 A Fresh checkout of the QFJ_RELEASE_1_5_3 tag fails to compile (using 'ant jar' following installation instructions on website), with the error:

[javac] /home/user/dev/quickfixj-src/core/src/main/java/quickfix/CachedFileStore.java:408: error: unmappable character for encoding UTF8
[javac] * @author mratsimbazafy 29 ao�t 2008

The platform encoding on most Linux systems (and probably others too nowadays) is UTF-8, whereas the source files seem to be in ISO-8859-1 (or ISO-8859-15, whatever the devs happen to be using). A search for non-ascii characters in all source files reveals:

$ find -name "*.java" | xargs grep -P -n "[\x80-\xFF]"
./core/src/test/java/quickfix/FileLogTest.java:65: // �bcf�d��
./core/src/test/java/quickfix/AbstractMessageStoreTest.java:102: // message 111 == �bcf�d��
./core/src/test/java/quickfix/mina/message/FIXMessageDecoderTest.java:119: // �bcf�d��
./core/src/test/java/quickfix/mina/message/FIXMessageEncoderTest.java:64: // �bcf�d��
./core/src/main/java/quickfix/CachedFileStore.java:408: * @author mratsimbazafy 29 ao�t 2008

The workaround would be to just delete these strings (they are all in comments), but the proper future-proof/cross-platform fix would be to convert these source files to UTF-8 encoding (e.g. using iconv) and update the build.xml files to add an encoding="UTF-8" attribute to all javac and jalopy tasks.
QuickfixJ, ant 0|i000yv:
QuickFIX/J QFJ-726

Missing fields in generated classes

Bug Closed Default Not a bug Unassigned Maarten Boekhold Maarten Boekhold 29/Dec/12 16:37   29/Dec/12 18:33 29/Dec/12 18:33 1.5.3   Message Generation   0 1   The following fields are not present in the generated Java class for TradeCaptureReport (FIX44 standard), but they are listed in the FIX44.xml message file:

<field name="SettlCurrAmt" required="N"/>
<field name="SettlCurrency" required="N"/>
<field name="SettlCurrFxRate" required="N"/>
<field name="SettlCurrFxRateCalc" required="N"/>
0|i000z3:
QuickFIX/J QFJ-725

Note that sequence numbers will be reset at 'StartTime' even if ResetOnLogon=N

New Feature Open Default Unresolved Unassigned Jim Mulcahey Jim Mulcahey 27/Dec/12 16:05   12/Apr/13 14:38       Documentation   0 1   When a new session is started based on the QF/J 'StartTime' configuration setting, the sequence numbers will be reset even if ResetOnLogon=N. The Configuration section in the User Manual does not make this clear, as 'StartTime' is only defined as..

"Time of day that this FIX session becomes activated"

It would help to have a note added in the Configuration section that the sequence numbers will be reset *even if* ResetOnLogon=N.
QuickfixJ 0|i000zb:
QuickFIX/J QFJ-724

quickfix.field.NoLegSecurityAltID extends quickfix.StringField instead of quickfix.IntField

Bug Closed Major Fixed Christoph John Maarten Boekhold Maarten Boekhold 24/Dec/12 07:27   21/Apr/16 13:40 04/Jan/16 16:13 1.5.3 1.6.2 Message Generation   0 2   quickfix.field.NoLegSecurityAltID extends quickfix.StringField instead of quickfix.IntField like all the other "No*" fields...
0|i000zj:
QuickFIX/J QFJ-723

need complete validation in DataDictionary rather than just first failure

New Feature Open Default Unresolved Unassigned Vishal Arora Vishal Arora 20/Dec/12 03:48   20/Dec/12 03:48           0 2   Currently when DataDictionary.validate method is called over a FIX Message, it throws exception on first failure. We need to fail it last, listing all failures during validation. This is required for testing of our application, where we can't expect developers to fix one FIX validation failure to find next one. 0|i000zr:
QuickFIX/J QFJ-722

Unnecessary Trailer and Header object allocation for every Message instance

Improvement Open Default Unresolved Unassigned Drew Noakes Drew Noakes 04/Dec/12 17:16   04/Dec/12 17:16   1.5.2       0 1   N/A In quickfix.Message, the field initialisers for 'header' and 'trailer' each new up an object.

Generated Message classes then replace these. This creates unnecessary work for the GC.

I see no reason that subclasses need to re-assign the trailer.

The Header can vary with each FIX version, so perhaps the API could be modified such that the header is created by a protected method which is overridden in generated subclasses.
garbage-collection, memory, performance 0|i000zz:
QuickFIX/J QFJ-721

non-FIXT sessions: NPE accessing ApplVerID if previous Logon was not completely processed

Bug Resolved Major Fixed Christoph John Jörg Thönnes Jörg Thönnes 29/Nov/12 11:30   30/Nov/12 16:09 30/Nov/12 16:09 1.5.2 1.5.3 Engine   0 2   In some cases the thread processing incoming FIX messages can get a NullPointerException accessing the ApplVerID
if the Logon process is not complete, e.g. because the counter party did not answer with a Logon response but continues
to send application messages.

In real ife, this issue was observed as a counter party sent many FIX messages without noticing a FIX re-login:
# counter party sends many messages
# QF/J sends logout
# counter party continues to send many messages
# QF/J forces disconnect due to Logout time-out (no 35=5 received so far)
# process restarts
# QF/J creates a new session
# QF/J sends Logon
# counter party continues to send many messages (but no Logon)
# QF/J receives a NPE for every message from the counter party:
{code}
[2012-11-08 14:44:26,644] [QFJ Timer] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: outgoing: 8=FIX.4.4|9=68|35=A|34=1079|49=XXXAT|52=20121108-13:44:26.640|56=XXXFL|98=0|108=30|10=124|
[2012-11-08 14:44:26,699] [SocketConnectorIoProcessor-0.0] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: incoming: 8=FIX.4.4|9=375|35=8|34=65834|43=Y|49=XXXFL|50=BU/XXXFL|52=20121108-13:44:26.675|56=XXXAT|122=20121108-12:45:47|6=0|...
[2012-11-08 14:44:26,712] [QFJ Timer] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: event : Initiated logon request
[2012-11-08 14:44:26,801] [QFJ Message Processor] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: event : null
java.lang.NullPointerException
at quickfix.MessageUtils.toBeginString(MessageUtils.java:256)
at quickfix.DefaultDataDictionaryProvider.getApplicationDataDictionary(DefaultDataDictionaryProvider.java:62)
at quickfix.Session.next(Session.java:913)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:722)
[2012-11-08 14:44:26,802] [SocketConnectorIoProcessor-0.0] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: incoming: 8=FIX.4.4|9=353|35=8|34=65835|43=Y|49=XXXFL|50=BU/XXXFL|52=20121108-13:44:26.676|56=XXXAT|122=20121108-12:45:47|6=0|...
[2012-11-08 14:44:26,811] [QFJ Message Processor] FIX.4.4:XXXAT->XXXFL:TEST-XXX-XXXFL-YYY: event : null
java.lang.NullPointerException
at quickfix.MessageUtils.toBeginString(MessageUtils.java:256)
at quickfix.DefaultDataDictionaryProvider.getApplicationDataDictionary(DefaultDataDictionaryProvider.java:62)
at quickfix.Session.next(Session.java:913)
at quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage(SingleThreadedEventHandlingStrategy.java:114)
at quickfix.mina.SingleThreadedEventHandlingStrategy.block(SingleThreadedEventHandlingStrategy.java:77)
at quickfix.mina.SingleThreadedEventHandlingStrategy$1.run(SingleThreadedEventHandlingStrategy.java:94)
at java.lang.Thread.run(Thread.java:722)
{code}

0|i00107:
QuickFIX/J QFJ-720

Improve log output when creating sessions and on unknown session ID during Logon

Improvement Resolved Default Fixed Christoph John Christoph John Christoph John 28/Nov/12 10:37   07/Nov/13 16:09 29/Nov/12 16:31 1.5.2 1.5.3 Engine   0 1   To ease the analysis of connection problems when working with multiple sessions/ports/log files it would be handy if there was a little more information given in one log line. This is especially necessary when grepping over multiple log files.

When starting a session the output is currently:
Listening for connections at <local address>

But should be something like:
Listening for connections at <local address> for sessions [<list of sessions>]

When there is an unknown session id encountered during logon, the output is currently:
Unknown session ID during logon: <session ID>

But to quickly identify the session which is concerned, the following output is better:
Unknown session ID during logon: <session ID> connecting from <remote address> to <local address> cannot be found in session list: [<list of sessions>]
0|i0010f:
QuickFIX/J QFJ-719

Document all FIX Session settings

Bug Resolved Major Fixed Jörg Thönnes Jörg Thönnes Jörg Thönnes 27/Nov/12 12:44   30/Nov/12 16:02 30/Nov/12 16:02 1.5.2 1.5.3 Documentation   0 1   Answering a question posted on the mailing list I found at least one undocumented setting:
- The TestRequestDelayMultiplier is not documented.

So we should document it and at the same time check for other undocumented features.
Here is the list of all session setttings (defined as constant with the prefix "SETTING_" in the Session class) which are
not mentioned in the "configuration.html":

- TestRequestDelayMultiplier
- NonStopSession
- DisableHeartBeatCheck
- ForceResendWhenCorruptedStore
- AllowedRemoteAddresses

h4. Steps
- Added documentation for missing items.
- Corrected formatting:
- Some settings are not in italics.
- Always "Y<BR>N".
0|i0010n:
QuickFIX/J QFJ-718

Logout message sent after event "resetting sequence numbers to 1" with msgSeqNum too low error

Bug Closed Default Fixed Unassigned Ashish Goswami Ashish Goswami 22/Nov/12 16:27   16/Dec/13 23:27 16/Dec/13 23:27 1.5.2   Engine   0 1   Windows7 Acceptor program sometimes send logout message with msgSeqNum too low error after receving logon message with reset Seq num flag<TAG 141>=Y.


Expected Behavior: Acceptor program should reset the seq and send the log on message

Config file settings:

ResetOnDisconnect=Y
ResetOnLogout=Y
ResetOnLogon=Y

Entries from Log file When this error happens:


2012-11-10 18:59:13,045 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=61|35=0|34=182|49=CD|52=20121110-23:59:13.045|56=DLR1|10=068|
2012-11-10 18:59:33,325 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=61|35=0|34=189|49=DLR1|52=20121110-23:59:54.923|56=CD|10=085|
2012-11-10 18:59:33,325 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=61|35=0|34=183|49=CD|52=20121110-23:59:33.325|56=DLR1|10=072|
2012-11-10 18:59:37,599 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=61|35=5|34=190|49=DLR1|52=20121110-23:59:59.199|56=CD|10=092|
2012-11-10 18:59:37,599 INFO event - FIX.4.4:CD->DLR1: Received logout request
2012-11-10 18:59:37,599 INFO Session - [FIX.4.4:CD->DLR1] Disconnecting: IO Session closed
2012-11-10 18:59:37,599 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=61|35=5|34=184|49=CD|52=20121110-23:59:37.599|56=DLR1|10=095|
2012-11-10 18:59:37,599 INFO event - FIX.4.4:CD->DLR1: No responder, not sending message: 8=FIX.4.4|9=61|35=5|34=184|49=CD|52=20121110-23:59:37.599|56=DLR1|10=095|
2012-11-10 18:59:37,599 INFO event - FIX.4.4:CD->DLR1: Sent logout response
2012-11-10 18:59:37,599 INFO event - FIX.4.4:CD->DLR1: Already disconnected: Received logout request
2012-11-10 19:00:12,700 INFO AcceptorIoHandler - MINA session created: /124.30.187.33:35167
2012-11-10 19:00:12,980 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=77|35=A|34=1|49=DLR1|52=20121111-00:00:34.573|56=CD|98=0|108=20|141=Y|10=046|
2012-11-10 19:00:12,980 INFO event - FIX.4.4:CD->DLR1: Accepting session FIX.4.4:CD->DLR1 from /124.30.187.33:35167
2012-11-10 19:00:12,980 INFO event - FIX.4.4:CD->DLR1: Acceptor heartbeat set to 20 seconds
2012-11-10 19:00:12,980 INFO event - FIX.4.4:CD->DLR1: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
2012-11-10 19:00:12,980 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=112|35=5|34=185|49=CD|52=20121111-00:00:12.980|56=DLR1|58=MsgSeqNum too low, expecting 191 but received 1|10=110|
2012-11-10 19:00:12,980 ERROR errorEvent - FIX.4.4:CD->DLR1: quickfix.SessionException MsgSeqNum too low, expecting 191 but received 1
2012-11-10 19:00:12,980 ERROR errorEvent - FIX.4.4:CD->DLR1: Disconnecting: Verifying message failed: quickfix.SessionException: MsgSeqNum too low, expecting 191 but received 1

Entries from log file when it works fine

2012-11-21 00:19:36,335 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=60|35=0|34=12|49=CD|52=20121121-05:19:36.335|56=DLR1|10=016|
2012-11-21 00:19:48,597 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=60|35=0|34=13|49=DLR1|52=20121121-05:19:58.465|56=CD|10=025|
2012-11-21 00:19:56,335 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=60|35=0|34=13|49=CD|52=20121121-05:19:56.335|56=DLR1|10=019|
2012-11-21 00:19:57,598 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=60|35=5|34=14|49=DLR1|52=20121121-05:20:07.458|56=CD|10=019|
2012-11-21 00:19:57,598 INFO event - FIX.4.4:CD->DLR1: Received logout request
2012-11-21 00:19:57,598 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=60|35=5|34=14|49=CD|52=20121121-05:19:57.598|56=DLR1|10=037|
2012-11-21 00:19:57,598 INFO event - FIX.4.4:CD->DLR1: Sent logout response
2012-11-21 00:19:57,598 INFO Session - [FIX.4.4:CD->DLR1] Disconnecting: Received logout request
2012-11-21 00:20:34,274 INFO AcceptorIoHandler - MINA session created: /124.30.187.33:4995
2012-11-21 00:20:55,162 INFO incoming - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=77|35=A|34=1|49=DLR1|52=20121121-05:21:05.042|56=CD|98=0|108=20|141=Y|10=044|
2012-11-21 00:20:55,162 INFO event - FIX.4.4:CD->DLR1: Accepting session FIX.4.4:CD->DLR1 from /124.30.187.33:4995
2012-11-21 00:20:55,162 INFO event - FIX.4.4:CD->DLR1: Acceptor heartbeat set to 20 seconds
2012-11-21 00:20:55,162 INFO event - FIX.4.4:CD->DLR1: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
2012-11-21 00:20:55,162 INFO event - FIX.4.4:CD->DLR1: Received logon
2012-11-21 00:20:55,162 INFO outgoing - FIX.4.4:CD->DLR1: 8=FIX.4.4|9=77|35=A|34=1|49=CD|52=20121121-05:20:55.162|56=DLR1|98=0|108=20|141=Y|10=051|
2012-11-21 00:20:55,162 INFO event - FIX.4.4:CD->DLR1: Responding to logon request
QuickfixJ, logon 0|i0010v:
QuickFIX/J QFJ-717

Use the same session for initiator and acceptor

Other Closed Default Not a bug Unassigned Eugene Lin Eugene Lin 15/Nov/12 22:30   15/Nov/12 22:45 15/Nov/12 22:45 1.5.1   Engine   0 0   QFJ engine under Linux trying to use the same session for both initiator and acceptor, using the same port. How to set up connection Type if it is doable ?

thanks
sequnece 0|i00113:
QuickFIX/J QFJ-716

Logout message is still sent before Logon on Initiators

Bug Resolved Default Fixed Christoph John Christoph John Christoph John 08/Nov/12 17:42   13/Nov/12 17:21 13/Nov/12 17:21 1.5.2 1.5.3     1 2   Follow-up to QFJ-357.

The problem still exists on Initiators in some cases. If an initiator is started before its StartTime is reached it can happen that a Logout message is sent as first message.
0|i0011b:
QuickFIX/J QFJ-715

CLONE - To handle 880 tag in FIX4.4 protocol using quickfixj1.3.3 jar

Bug Closed Critical Not a bug Unassigned Lailesh Jawale Lailesh Jawale 08/Nov/12 14:55   08/Nov/12 15:04 08/Nov/12 15:04 1.3.3   Message Generation   0 1   Production Hi,

I am trying to populate some extra fields as part of my ongoing requirment in project for clearing fields.
The extra tags need to be populated are:

Repeating group is:
453 =2 (448=CME447=D452=21448=CCP447=D452=16)
1003 and 880 tags

To process the repeating group we require to use DataDictionay internally so we are using it as below:

1) The call for quickfix message is:
quickfix.Message(msb.toString(), new DataDictionary("FIX44.xml"), true);

2) UseDataDictionary=Y as configuration part for FIX level.

We are able to genearte the repeating group (453 =2 (448=CME447=D452=21448=CCP447=D452=16)) and 1003 tag successfully, however when we tray to pass 880 field the quickfixj 1.3.3 throws an error as:

********************************************************************************
Exception stack is:
1. Header fields out of order (quickfix.InvalidMessage)
quickfix.Message:386 (null)
2. Component that caused exception is: SedaService{PreprocessServiceComponent}. Message payload is of type: String (org.mule.api.service.ServiceException)
org.mule.component.DefaultLifecycleAdapter:216 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/service/ServiceException.html)
********************************************************************************
Root Exception stack trace:
quickfix.InvalidMessage: Header fields out of order

**********************************************************************************

Please guide us to handle 880 tag along with repeating group and 1003 tag in fix4.4 protocol and using quickfixk1.3.3 jar.
0|i0011j:
QuickFIX/J QFJ-714

To handle 880 tag in FIX4.4 protocol using quickfixj1.3.3 jar

Bug Closed Critical Not a bug Unassigned Lailesh Jawale Lailesh Jawale 07/Nov/12 15:42   07/Nov/12 18:59 07/Nov/12 18:59 1.3.3   Message Generation   0 1   Production Hi,

I am trying to populate some extra fields as part of my ongoing requirment in project for clearing fields.
The extra tags need to be populated are:

Repeating group is:
453 =2 (448=CME447=D452=21448=CCP447=D452=16)
1003 and 880 tags

To process the repeating group we require to use DataDictionay internally so we are using it as below:

1) The call for quickfix message is:
quickfix.Message(msb.toString(), new DataDictionary("FIX44.xml"), true);

2) UseDataDictionary=Y as configuration part for FIX level.

We are able to genearte the repeating group (453 =2 (448=CME447=D452=21448=CCP447=D452=16)) and 1003 tag successfully, however when we tray to pass 880 field the quickfixj 1.3.3 throws an error as:

********************************************************************************
Exception stack is:
1. Header fields out of order (quickfix.InvalidMessage)
quickfix.Message:386 (null)
2. Component that caused exception is: SedaService{PreprocessServiceComponent}. Message payload is of type: String (org.mule.api.service.ServiceException)
org.mule.component.DefaultLifecycleAdapter:216 (http://www.mulesource.org/docs/site/current2/apidocs/org/mule/api/service/ServiceException.html)
********************************************************************************
Root Exception stack trace:
quickfix.InvalidMessage: Header fields out of order

**********************************************************************************

Please guide us to handle 880 tag along with repeating group and 1003 tag in fix4.4 protocol and using quickfixk1.3.3 jar.
0|i0011r:
QuickFIX/J QFJ-713

On JDK 7 unexpectedly find a registerd MBean for the ObjectName("org.quickfixj:type=Connector,role=Acceptor,*") by the camel-quickfix component of Apache Camel

Bug Closed Default Not a bug Christoph John Babak Vahdat Babak Vahdat 05/Nov/12 10:01   19/Nov/12 22:53 19/Nov/12 22:53 1.5.2   Engine   0 1   Using QuickFixJ version 1.5.2-bd by camel-quickfix we're observing some odd test failures on [JDK 7 profile of Apache Camel|https://builds.apache.org/job/Camel.trunk.fulltest.java7/] however the behaviour is nondeterministic as we see the failed tests only from time to time where *all* the tests of [{{QuickfixjEngineTest}}|http://svn.apache.org/viewvc/camel/trunk/components/camel-quickfix/src/test/java/org/apache/camel/component/quickfixj/QuickfixjEngineTest.java?revision=1399672&view=markup] do fail because of the same assert, but as already said only on the JDK 7 and just from time to time. Also we cann't reproduce the issue locally. As you see on the trunk currently we've disabled the assert on JDK7.

The stacktrace of the failed assert looks as the following:

{code}
java.lang.AssertionError: QFJ mbean should not have been registered
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.camel.component.quickfixj.QuickfixjEngineTest.assertDefaultConfiguration(QuickfixjEngineTest.java:569)
at org.apache.camel.component.quickfixj.QuickfixjEngineTest.defaultAcceptor(QuickfixjEngineTest.java:161)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
{code}

Which corresponds to [this revision|http://svn.apache.org/viewvc/camel/trunk/components/camel-quickfix/src/test/java/org/apache/camel/component/quickfixj/QuickfixjEngineTest.java?revision=1399672&view=markup] of {{QuickfixjEngineTest}}.

Currently we've disabled this assert as you can see by the [revision history of this class|http://svn.apache.org/viewvc/camel/trunk/components/camel-quickfix/src/test/java/org/apache/camel/component/quickfixj/QuickfixjEngineTest.java?view=log].

Please also note that [{{QuickfixjEngine}}|https://svn.apache.org/repos/asf/camel/trunk/components/camel-quickfix/src/main/java/org/apache/camel/component/quickfixj/QuickfixjEngine.java] does properly register/unregister the MBean, see it's {{doStart}} & {{doStop}} methods. This component's documentation is [here|http://camel.apache.org/quickfix.html]. Any hint or idea would be much appreciated. Please let us know if there's any more details you may need.
jmx 0|i0011z:
QuickFIX/J QFJ-712

ConcurrentModificationException in the toString method

Bug Closed Critical Not a bug Unassigned Igor Bakhtoiarov Igor Bakhtoiarov 30/Oct/12 09:37   12/Nov/12 08:39 12/Nov/12 08:39 1.5.2       0 2   I've found in my logs this exception:

java.util.ConcurrentModificationException
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
at java.util.TreeMap$ValueIterator.next(TreeMap.java:1145)
at quickfix.FieldMap.calculateTotal(FieldMap.java:612)
at quickfix.Message.checkSum(Message.java:160)
at quickfix.Message.toString(Message.java:134)
0|i00127:
QuickFIX/J QFJ-711

Lost Order Requests

Bug Closed Critical Not a bug Unassigned Robert Shalonov Robert Shalonov 24/Oct/12 16:21   24/Oct/12 17:13 24/Oct/12 16:36 1.5.2       0 1   Linux x86_64 When we get two order requests at the same time, the quickFixJ does not notify us of the second order. The fromApp method only notifies us of the first order and the second order gets lost. In the order requests bellow that came almost at the same time, only the first order got processed. Please, advise.

8=FIX.4.4 9=166 35=D 34=1904 49=CLIENT 52=20121024-12:37:39.100 56=SERVER-ORD 1=CLIENT_FIX 11=19_0_3_6_1_45459 21=1 38=250000 40=1 44=0.98956 54=1 55=USD/CAD 59=1 6 0=20121024-12:37:39.100 10=048
8=FIX.4.4 9=166 35=D 34=1905 49=CLIENT 52=20121024-12:37:39.101 56=SERVER-ORD 1=CLIENT_FIX 11=19_0_2_6_1_45459 21=1 38=800000 40=1 44=0.98956 54=1 55=USD/CAD 59=1 6 0=20121024-12:37:39.101 10=051
0|i0012f:
QuickFIX/J QFJ-710

Lost Subscription Requests

Bug Closed Critical Not a bug Unassigned Robert Shalonov Robert Shalonov 23/Oct/12 23:23   24/Oct/12 09:48 24/Oct/12 09:48 1.5.2       0 1   Linux x86_64 GNU/Linux We are using QuickFIX/J 1.5.2 . Our application runs as an Acceptor for our client. The client sends us a subscription requests for different symbols. However, out of 10 subscription requests send by the client our application gets only 8 requests. The 10 requests do show up on our fix messages logs. However, fromApp(quickfix.Message message, quickfix.SessionID sessionID) call back method only notifies us of 8 requests and not 10. Why fromApp() method notifies us only of 8 requests and not 10 despite of ten requests showing up in fix messages log? It happens sporadically. Our client is very unhappy about it and our reputation is on the line. Please, advise ASAP. Thanks.