i am using quickfixj to connect with target URL using proxy , the proxy protocol is socks ,
after checked with our proxy team , they said the destination URL (SocketConnectHost) is not passed to proxy , which means not send url to which proxy need to connect .

below is my quickfixj configure sample:

ProxyType=socks
ProxyHost=*************
ProxyPort=1080
ProxyVersion=5

SocketConnectHost=********
SocketConnectPort=******

I believe I've seen evidence of some sort of issue with infinite replay requests.

I've attached an the annotated log of the situation. The log is from "EXCHANGE", which is a QFJ 2.1.0 application; the other party of the session, "BROKER_GATEWAY", is not QFJ. Both applications are on the same host, so the message time stamps correlate.

Essentially, what occurs in this scenario is that there is a disconnect - and while the FIX session is disconnected, EXCHANGE generates 3 execution reports (er...10, er...11, and er...12). When the session reconnects, EXCHANGE sends a logon with a sqn 12 that is greater than what BROKER_GATEWAY was expected (it was expecting sqn 11), and follows with sqn 13 (er...11) and sqn 14 (er...12)

While EXCHANGE is sending those "queued" messages, BROKER_GATEWAY issues a resend-request, for messages starting at sqn 11 and with an infinite length.

EXCHANGE responds by replaying sqns 11 (er...10), 12 (admin msg as a gap-fill), and 13 (er...11), but never replays 14 (er...12) It isn't until 30 seconds later, that another message, a heartbeat, from EXCHANGE with sqn 15 triggers a second replay request, and 14 (er...12) is replayed.

It seems as if there is some sort of race, where the resend request arrives after sqn 14 was "triggered" to be sent, but before the internal state used to prepare a resent request has been updated.

I believe I've seen evidence of some sort of race condition. Log to follow

Fix engine (initiator) doesnt reconnect upon the acceptor's restart when http proxy is being used. It keeps displaying "Pending connection not established after 270734 ms.", which is a consequence of not reconnecting at all. Is there any workaround for http proxy to trigger reconnection?

We have configured ReconnectInterval, ProxyType=http, ProxyVersion=1.1.

If we change proxy type to socks we are seeing the reconnect attempt due to /org/apache/mina/proxy/ProxyConnector.java:181, but would be nice to have the same functionality for http proxy. I also cant see any obvious way to set reconnectionNeeded variable that would potentially trigger the reconnection which i have tested by resetting it myself with a debugger.

Hi
I want to start and stop session daily but at different time, for example

1.Session start at 9:30 UTC on Monday and stops at 9:28 UTC on Tuesday
2. On Tuesday session starts at 10:30 and stop on Sunday 10:28

How do I achieve the above in quick fix.

Can I change the sequence of FIX message tags? How to do it?
I am using AE type and version FIX 5.0 SP1.
I want to do the sequencing because tags are not getting parsed in sequence.
Message type AE contains group tag hierarchy as : 552 -> 54 -> 453,448,447,452.
So 54 is a group tag and 453,448,447,452 are subgroup tags. I am getting a problem with manipulating the subgroup tags. So I want those tags in sequence.
Can anyone help?

When cloning the repo master branch and trying to build the examples. The pom file is trying to download the quickfixj version 2.2.0-SNAPSHOT that doesn't exist in Maven.

configuration: quickfix.properties
[DEFAULT]
UseDataDictionary=Y

[SESSION]
AcceptorTemplate=Y
ConnectionType=acceptor
BeginString=FIX.4.4

Code:

    public synchronized void start() {
        try {
            final SLF4JLogFactory logger = new SLF4JLogFactory(this.sessionSettings);

            this.acceptor = new SocketAcceptor(this.application,
                                               this.messageStoreFactory,
                                               this.sessionSettings,
                                               logger,
                                               this.msgFactory);

            this.acceptor.setSessionProvider(new InetSocketAddress("0.0.0.0", 50000),
                                             new DynamicAcceptorSessionProvider(
                                                     this.sessionSettings,
                                                     new SessionID("FIX.4.4", "SENDCOMPID", "TARGETCOMPID"),
                                                     this.application,
                                                     this.messageStoreFactory,
                                                     logger,
                                                     this.msgFactory));
            this.acceptor.start();
        } catch (ConfigError ex) {
            log.error("Failed to start QuickFIX-J socket acceptor.", ex);
            this.acceptor = null;
        }
    }

Throws:

quickfix.ConfigError: SocketAcceptPort not defined
at quickfix.SessionSettings.getString(SessionSettings.java:149) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.SessionSettings.getLong(SessionSettings.java:229) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.mina.acceptor.AbstractSocketAcceptor.getAcceptorSocketDescriptor(AbstractSocketAcceptor.java:189) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.mina.acceptor.AbstractSocketAcceptor.createSessions(AbstractSocketAcceptor.java:230) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.mina.acceptor.AbstractSocketAcceptor.startAcceptingConnections(AbstractSocketAcceptor.java:96) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.SocketAcceptor.initialize(SocketAcceptor.java:108) ~[quickfixj-core-2.1.1.jar:2.1.1]
at quickfix.SocketAcceptor.start(SocketAcceptor.java:102) ~[quickfixj-core-2.1.1.jar:2.1.1]

Issue seems to be with this code

quickfix.mina.acceptor.AbstractSocketAcceptor
private void createSessions(SessionSettings settings) throws ConfigError, FieldConvertError {
        HashMap<SessionID, Session> allSessions = new HashMap<>();
        for (Iterator<SessionID> i = settings.sectionIterator(); i.hasNext();) {
            SessionID sessionID = i.next();
            String connectionType = settings.getString(sessionID,
                    SessionFactory.SETTING_CONNECTION_TYPE);

            boolean isTemplate = false;
            if (settings.isSetting(sessionID, Acceptor.SETTING_ACCEPTOR_TEMPLATE)) {
                isTemplate = settings.getBool(sessionID, Acceptor.SETTING_ACCEPTOR_TEMPLATE);
            }

            if (connectionType.equals(SessionFactory.ACCEPTOR_CONNECTION_TYPE)) {
                AcceptorSocketDescriptor descriptor = getAcceptorSocketDescriptor(settings, sessionID);
                if (!isTemplate) {
                    Session session = sessionFactory.create(sessionID, settings);
                    descriptor.acceptSession(session);
                    allSessions.put(sessionID, session);
                }
            }
        }
        setSessions(allSessions);

        if (socketDescriptorForAddress.isEmpty()) {
            throw new ConfigError("No acceptor sessions found in settings.");
        }
    }

// attempts to create descriptor for a session template

if (connectionType.equals(SessionFactory.ACCEPTOR_CONNECTION_TYPE)) {
* AcceptorSocketDescriptor descriptor = getAcceptorSocketDescriptor(settings, sessionID);*
if (!isTemplate) {

the maven plugin enforcer shows that quickfixj has a dependency convergence error for org.apache.maven:maven-artifact:3.5.0. Here is the output:

Dependency convergence error for org.apache.maven:maven-artifact:3.5.0 paths to dependency are:
+-project-that-uses-quickfixj
+-org.quickfixj:quickfixj-all:2.1.1
+-org.quickfixj:quickfixj-codegenerator:2.1.1
+-org.apache.maven:maven-plugin-api:3.5.0
+-org.apache.maven:maven-artifact:3.5.0
and
+-project-that-uses-quickfixj
+-org.quickfixj:quickfixj-all:2.1.1
+-org.quickfixj:quickfixj-codegenerator:2.1.1
+-org.apache.maven:maven-project:2.2.1
+-org.apache.maven:maven-artifact-manager:2.2.1
+-org.apache.maven:maven-artifact:2.2.1
and
+-project-that-uses-quickfixj
+-org.quickfixj:quickfixj-all:2.1.1
+-org.quickfixj:quickfixj-codegenerator:2.1.1
+-org.apache.maven:maven-project:2.2.1
+-org.apache.maven:maven-artifact:2.2.1

"Customizing Message Code Generation" article doesn't have information quickfixj-codegenerator.

Maven is standard de facto tool for building java application. And using of quickfixj-codegenerator is the most convenient way for using own dictionary.

So I suggest to add example of using this plugin for maven. Text may be like this:

If you are using the Maven build system, you can also use quickfixj-codegenerator:

<build>
<plugins>
<plugin>
<groupId>org.quickfixj</groupId>
<artifactId>quickfixj-codegenerator</artifactId>
<version>2.1.1</version>
<executions>
<execution>
<id>fixt11</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<dictFile>path/to/your/dictionary/file/FIXT11.xml</dictFile>
<packaging>quickfix.fixt11</packaging>
<fieldPackage>quickfix.field</fieldPackage>
</configuration>
</execution>
<execution>
<id>fix50sp2</id>
<goals>
<goal>generate</goal>
</goals>
<configuration>
<dictFile>path/to/your/dictionary/file/FIX50SP2.modified.xml</dictFile>
<packaging>quickfix.fix50sp2</packaging>
<fieldPackage>quickfix.field</fieldPackage>
</configuration>
</execution>
[...]
</plugin>
[...]
</plugins>
</build>

Hi, I have downloaded quickfix engine 1.15.1 and compiled for windows with VS2017 and while running the application the quickengine source is randomly populating different values for the variables. I have disabled the compiler optimization which resolved some issues but breaks in different places. Please advice.

Thanks

We are using fix acceptor (version 1.6.4). The acceptor resets the connection from initiators many times when logon is received. Can someone please help?

2019-12-01 23:10:00,712 |FIXT.1.1:SENDER->RECEIVER: 8=FIXT.1.1|9=74|35=A|56=SENDER|49=RECEIVER|52=20191201-23:10:00|34=1|108=60|98=0|1137=9|10=045|
2019-12-01 23:10:00,718 |FIXT.1.1:SENDER->RECEIVER: Accepting session FIXT.1.1:SENDER->RECEIVER from /(IP ADDRESS):(PORT)
2019-12-01 23:10:00,723 |FIXT.1.1:SENDER->RECEIVER: Acceptor heartbeat set to 60 seconds
2019-12-01 23:10:00,725 |FIXT.1.1:SENDER->RECEIVER: Setting DefaultApplVerID (1137=9) from Logon
2019-12-01 23:10:00,734 |FIXT.1.1:SENDER->RECEIVER: Refreshing message/state store at logon
2019-12-01 23:10:00,751 |FIXT.1.1:SENDER->RECEIVER: Received logon
2019-12-01 23:10:00,754 |FIXT.1.1:SENDER->RECEIVER: Responding to Logon request
2019-12-01 23:10:00,761 |FIXT.1.1:SENDER->RECEIVER: 8=FIXT.1.1|9=78|35=A|34=1|49=SENDER|52=20191201-23:10:00.761|56=RECEIVER|98=0|108=60|1137=9|10=253|
2019-12-01 23:10:04,859 |FIXT.1.1:SENDER->RECEIVER: Session state is not current; resetting FIXT.1.1:SENDER->RECEIVER
2019-12-01 23:10:04,865 |FIXT.1.1:SENDER->RECEIVER: 8=FIXT.1.1|9=59|35=5|34=2|49=SENDER|52=20191201-23:10:04.865|56=RECEIVER|10=155|
2019-12-01 23:10:04,877 |FIXT.1.1:SENDER->RECEIVER] Disconnecting: Session reset

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)

1. 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):

1. 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

The new module system available since JDK 9 does not allow duplicate packages on the module path.
As a result an application that depends on more than one messages version will have a split package issue, since quickfix.field exists in all quickfixj-messages-<version> jars.

The packaging needs to be changed in order to avoid duplicate packages used by different quickfixj modules.

The source-code of quickfixj-core (and maybe others?) are not published to Maven Central, making it harder for developers to use this library.

Please publish the source-code using https://bitbucket.org/simpligility/ossrh-pipeline-demo/src/4a6fdd4432e5625e62602559a133530e9ffa408a/pom.xml#lines-63 as an example.

Java Modules (jigsaw) does not allow users to load JAR files that export the same package.

Mutually-exclusive JAR files (e.g. FIX42, FIX44 JAR files) are allowed to export the same package, but users cannot import quickfixj-core and quickfixj-messages-fix44 simultaneously because they export the same package. Doing so results in the following compile-time error message:

the unnamed module reads package quickfix.field from both quickfixj.messages.fix44 and quickfixj.core
module quickfixj.messages.fix44 reads package quickfix.field from both quickfixj.core and quickfixj.messages.fix44
module quickfixj.core reads package quickfix.field from both quickfixj.messages.fix44 and quickfixj.core

Please refactor the artifacts so JAR files that must be imported together do not export the same package.

I construct a message in the following way:

quickfix.fix44.MarketDataRequest message = new quickfix.fix44.MarketDataRequest();
        
        char zero = '0';
        char one = '1';
        message.setField(new quickfix.field.MDReqID("EURUSD")); // 262
        message.setField(new quickfix.field.SubscriptionRequestType(one)); // 263
        message.setField(new quickfix.field.MarketDepth(1)); // 264
        message.setField(new quickfix.field.MDUpdateType(0)); // 265            

        message.setField(new quickfix.field.NoMDEntryTypes(2)); // 267
        message.setField(new quickfix.field.MDEntryType(zero)); // 269        
        message.setField(new quickfix.field.MDEntryType(one)); // 269

        message.setField(new quickfix.field.NoRelatedSym(1)); // 146
        message.setField(new quickfix.field.SecurityID("4001")); // 48
        message.setField(new quickfix.field.SecurityIDSource("8")); // 22
        
        Session.sendToTarget(message, senderCompID, marketTargetCompID); 

I also load a dictionary in which tags 146, 48 and 22 are after tag 269. But the message sent to the trader looks like this:

8=FIX.4.4^A9=121^A35=V^A34=2^A49=USERNAME^A52=20190821-11:11:42.045^A56=TRADER^A22=8^A48=4001^A146=1^A262=EURUSD^A263=1^A264=1^A265=0^A267=2^A269=1^A10=191^A

The confusing thing is that tags 146, 48 and 22 are mixed and moved before tag 262 even though the dictionary doesn't allow that.

I have two suggestion why this may happen:

• Quickfix/J mixes the tags because of an issue or because I miss some configuration.
• The dictionary provided by the trader is not loaded and I use some defaultdictionary which brings me to this issue.

I don't know if that would help but here is the cfg file:

[DEFAULT]
ConnectionType=initiator
BeginString=FIX.4.4

StartTime=08:30:00
EndTime=21:30:00
ReconnectInterval=5
HeartBtInt=5
LogonTimeout=60

FileStorePath=target/data/sessions/
FileLogPath=target/data/logs/

SenderCompID=USERNAME
UseDataDictionary=Y
SocketUseSSL=Y


[SESSION]
TargetCompID=TRADER
SocketConnectHost=URL_OF_THE_TRADER
SocketConnectPort=443
DataDictionary=/var/quickfixj/automated/DICTIONARY.xml

The property SLF4JLogPrependSessionID "Controls whether session ID is prepended to log message." This property is passed down to SLF4J and used in the method quickfix.SLF4JLog#getLogger.

Based on the property name and description, one would think that the Session ID will appear as prefix of category. But the method getLogger suffixes category with session ID instead of prefixing it. I think this is a bug.

Bug:

private Logger getLogger(SessionID sessionID, String category, String defaultCategory, String logPrefix) {
    return LoggerFactory.getLogger((category != null
            ? substituteVariables(sessionID, category)
            : defaultCategory) + logPrefix);
}

Proposed Fix:

private Logger getLogger(SessionID sessionID, String category, String defaultCategory, String logPrefix) {
    return LoggerFactory.getLogger(logPrefix + (category != null
            ? substituteVariables(sessionID, category)
            : defaultCategory));
}

Thanks!

[Affects all vaguely recent versions]

The DefaultSessionFactory stores a cache DataDictionary objects based on the file name of that object.

createDataDictionary fetches a DataDictionary object based on the file name and then applies settings to it based on the session.

Because it applies the settings to and returns the DataDictionary object in the cache, not a copy of it, when a different session uses a dictionary from the same file, it will also have the settings applied.

This means that configuration that's supposed to be session specific is not.

What we should do is instead have a `SessionDataDictionarySettings` object to encapsulate the settings. Then when using the data dictionary, pass in the relevant settings for the session the message is being validated for.

This would allow us to gain the advantages of reusing DataDictionary objects (lower memory usage) with the configuration settings required.

It will however likely involve API changes.

From mailing list https://sourceforge.net/p/quickfixj/mailman/message/36618317/

[Quickfixj-users] Session validation settings have no effect for FIXT unless AppDataDictionary is set explicitly
From: Ilya Kurnosov <kurniliya@gm...> - 2019-03-21 08:50:46

Hello! I ran into some interesting behavior with quickfixj 2 today. My
question is if it's intentionally designed this way? And, if yes, if
someone could explain the reasoning behind it?

The behavior I see is that all the session validation settings:

• Session.SETTING_VALIDATE_FIELDS_HAVE_VALUES
  ("ValidateFieldsHaveValues")
• Session.SETTING_VALIDATE_FIELDS_OUT_OF_ORDER
  ("ValidateFieldsOutOfOrder")
• Session.SETTING_VALIDATE_UNORDERED_GROUP_FIELDS
  ("ValidateUnorderedGroupFields")
• Session.SETTING_VALIDATE_USER_DEFINED_FIELDS
  ("ValidateUserDefinedFields")
• Session.SETTING_ALLOW_UNKNOWN_MSG_FIELDS ("AllowUnknownMsgFields")

have exactly no effect on the validation of FIXT application messages
unless one also explicitly sets "AppDataDictionary" option
(Session.SETTING_APP_DATA_DICTIONARY).
I observe this behavior in tests, but the code in
DefaultSessionFactory#processFixtDataDictionaries looks rather unambiguous
too (
https://github.com/quickfix-j/quickfixj/blob/QFJ_RELEASE_2_1_1/quickfixj-core/src/main/java/quickfix/DefaultSessionFactory.java#L283).
It looks like DefaultSessionFactory#createDataDictionary (the only place
using those Validate* and AllowUnknownMsgFields settings) is called to
create app dictionary IIF AppDataDictionary is present.

Is this behavior intentional?

problem

The default application dictionary is loaded if it is not specified but the validation settings do not get applied. This would only work if method DefaultSessionFactory#createDataDictionary got called.

If a message contains a repeating group in which the first tag is not defined in the dictionary, a NullPointerException is thrown while parsing the message/group.

To reproduce, you can use this FIX string with the standard 4.2 dictionary.
It contains an undefined tag (9876) as the first tag of the NoAllocs (78) repeating group.

8=FIX.4.2|9=130|35=D|34=2|49=SND1|52=20190719-04:56:39.042|56=TGT1|11=1|78=1|9876=npe|79=a|80=1|21=1|55=x|54=1|60=20190719-04:56:53.826|38=1|40=1|10=169|

Here is the stack trace for 1.6.4:

Exception in thread "main" java.lang.NullPointerException
	at quickfix.Message.checkFieldValidation(Message.java:662)
	at quickfix.Message.parseGroup(Message.java:633)
	at quickfix.Message.parseBody(Message.java:559)
	at quickfix.Message.parse(Message.java:470)
	at quickfix.Message.fromString(Message.java:453)
	[...]

and for 2.1.1:

Exception in thread "main" java.lang.NullPointerException
	at quickfix.Message.checkFieldValidation(Message.java:748)
	at quickfix.Message.parseGroup(Message.java:711)
	at quickfix.Message.parseBody(Message.java:637)
	at quickfix.Message.parse(Message.java:548)
	at quickfix.Message.fromString(Message.java:531)
	[...]

Looking in the QuickFixJ 2.x releases, it looks like the SQL schema definitions for oracle are missing some tables which are defined for other databases. (event_log, messages_log)

I can't find any documentation which suggests that they aren't required for Oracle. I can craft them manually but am curious why they're omitted.

We receive 35=2 (RESENDREQUEST) from clinet, but its only logged in *.messages log.
Not present in *.event log. we expect following message should be present in event log at least - 'Received ResendRequest FROM:'. or any validation failure message from 'verify' method.

But no clue in *.event log.

Fix session was interrupted due to network issue... Both side FIX processes ( Client, Sender) did not know about the n/w issue. The Client side was continuously sending logon request to other side... Once the n/w issue was resolved the connectivity was established. However, the sequence was not in sync at this time . Hence , The sender sent resend request (35=2) immediately after successful logon response.
But this 35=2 request was not processed by quick fix engine at my side ( Client side). I can see the message in quickfix messages.log arrived from sender but not traceability on what had happened with this message.
Only what i can see , the Client side ( fix engine) sent 35=2 for which the sender has responded with sequencereset i.e., 35=4. I think , the sender on the other side responded well with the Admin messages sent by my quickFix engine.

the problem is why my fix engine (i.e., the client ) did not respond to 35=2 resent request given by sender ? . I am expecting my Fix engine should have responed with 35=4 like my Sender's engine . I am using QuickfixEngineJ 1.5.3

Some one kindly help please. The below the sequence of FIX messaged traced in messages.log/

Response from Sender:
8=FIXT.1.19=72 35=A 34=75098 49=456 52=20190516-23:30:20.382 56=123 98=0 108=30 1137=9 10=178

Resent request from sender ( problem where I did not respond for this message)
8=FIXT.1.19=66 35=2 34=75099 49=456 52=20190516-23:30:20.38256=123 7=74910 16=0 10=154

Resent request from Client (i.e., by my quick fix engine )
8=FIXT.1.19=66 35=2 34=74963 49=123 52=20190516-23:30:20.436 56=456 7=75019 16=0 10=154

reset request responded by sender:
8=FIXT.1.19=99 35=434=75019 43=Y 49=456 52=20190516-23:30:20.489 56=123 122=20190516-23:30:20.489 36=75100 123=Y 10=043

I think there is an issue with letting garbledMessages(when the new RejectGarbledMessage property is set to Y) through the AbstractIoHandler. Its being passed here: https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/main/java/quickfix/mina/AbstractIoHandler.java#L142 and if the reason is that the message is garbled because of missing MsgType it will crash here: https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/main/java/quickfix/mina/initiator/InitiatorIoHandler.java#L64. Which means that the sequencenumber won't be incremented and the purpose with the property is neglected.

<20190516-14:30:21, FIX.4.4:SCILA5MD->FIXRFQTRADE, error> (Processing garbled message: Missing or garbled message type in 8=FIX.4.49=8034=149=FIXRFQTRADE52=20190516-14:29:47.67156=SCILA5MD98=0108=30141=Y10=174)
<20190516-14:30:32, FIX.4.4:SCILA5MD->FIXRFQTRADE, error> (quickfix.FieldNotFound: Field was not found in message, field=35
quickfix.FieldNotFound: Field was not found in message, field=35
at quickfix.FieldMap.getField(FieldMap.java:223)
at quickfix.FieldMap.getString(FieldMap.java:237)
at quickfix.mina.initiator.InitiatorIoHandler.processMessage(InitiatorIoHandler.java:64)
at quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:142)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:858)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:398)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:234)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:947)
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:535)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:703)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:659)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:648)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1120)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Hi, I am trying to connect third party fix engine Aphelion using their their port,ip,SenderCompID ,TargetCompID, username and password but I am facing issue if I try to get username and pwd from config file. my program is working fine if I send username and explicitly programaticaly.
I do not want to do it programaticaly as Calypso is providing "Fix Engine" using Quickfixj so I just wanted to pass all the values from config.

.

If the FileStore stream is closed for any unexpected reason, the reset will fail indefinitely even if the original cause is fixed (or was just a transient error), since it will continue to try and flush/closed the failed stream, instead of truly resetting and opening a new one.

In our case the error was triggered by the disk being full (space was then freed up), but any reason for closing the stream could get the store stuck in this unrecoverable state. Perhaps the store reset mechanism should be made more robust so that it really tries to reset even in this unexpected state rather than require the application to be restarted manually.

quickfix.RuntimeError: java.io.IOException: Stream Closed
at quickfix.SessionState.reset(SessionState.java:384)
at quickfix.Session.resetState(Session.java:2624)
at quickfix.Session.nextLogon(Session.java:2116)
at quickfix.Session.next(Session.java:1026)
at quickfix.Session.next(Session.java:1204)
at quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:222)
at quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:146)
at java.lang.Thread.run(Thread.java:748)
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.close(FileStore.java:218)
at quickfix.FileStore.close(FileStore.java:209)
at quickfix.FileStore.closeAndDeleteFiles(FileStore.java:223)
at quickfix.FileStore.initialize(FileStore.java:101)
at quickfix.FileStore.reset(FileStore.java:405)
at quickfix.SessionState.reset(SessionState.java:382)
... 7 more Suppressed: 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.FilterOutputStream.close(FilterOutputStream.java:158)
at java.io.FilterOutputStream.close(FilterOutputStream.java:159)
... 13 more

Recently, I have experienced a QuickFIX/J based application ignoring or rejecting messages with an invalid checksum (depending on the setting of the RejectGarbledMessage property). On the other hand, these messages featured the required structure for further processing.

So I have decided to provide an enhancement which allows the FIX Engine to process messages with invalid checksum as ordinary messages having passed validation. This enhancement will be provided as a configuration option controlled by the property ProcessMessageWithInvalidChecksum. By default, this property will be set to 'N' such that Messages with invalid checksum will be either ignored or rejected as before.

In particular, it will only be possible to set either RejectGarbledMessage or ProcessMessageWithInvalidChecksum to 'Y' for a specific session. If both properties are set to 'Y' at once, a ConfigError will be thrown.

When using multiple SocketConnectHost/SocketConnectPort combinations, it would be nice to be able to see which combo was being used for the connection attempt.

Hello QuickFix support,

Could you advise on the following issue, please?

We receive intermittent "Required Tag Missing" error while parsing incoming fix messages, even though the missing field is present in the message. For example in the following message the tag 447 is present on the message, and yet sometimes we receive “Required Tag Missing, field=447” while parsing it.

8=FIX.4.4|9=284|35=F|49=TEST_49|56=TEST_56|34=420|52=20190302-07:31:57.079|115=TEST3|116=TEST_116|11=TEST_11|41=TEST_41|55=TEST_55|48=TEST_48|22=4|54=2|60=20190302-07:31:56.933|38=TEST_38|207=TEST_207|454=3|455=TEST_455_1|456=TEST_456_1|455=TEST_455_2|456=TEST_456_2|455=TEST_455_3|456=TEST_456_3|453=1|448=TEST_448|447=D|452=3|10=XXX|

This issue has been observed with cancel messages and it normally happens after application startup. We do use a data dictionary, and 99.8% of the time such cancellation messages work fine. We use quick fix version 1.5.3. (quickfixj-core-1.5.3.jar and quickfixj-msg-fix44-1.5.3.jar)

Could you take a look at it?

Many thanks
Michael

Our side it's client side, we only receive the messages from the server side, not sending any mesages from our side. So server side give us one certificate to use the SSL encryption(we generate the trust store by our selfservles), in our dev env and UAT env is good. But for the production it's bad.

Then we try to resolve the issue, we find when prod env validate the keyusage, client and server side decide to use RSA, RSA need to validate the 3 key usages, but our certification only have 1 key usage. The SSL hand shake failed.

Error Class: X509TrustManagerWrapper, method: checkServerTrusted()

Could you please help to check this issue? Thank you for your help.

ERROR MESSAGE:
adding as trusted cert:
Subject: CN=Root Certification Authority, OU=Sysadmin Team, O=360 Treasury Systems AG, C=DE
Issuer: CN=Root Certification Authority, OU=Sysadmin Team, O=360 Treasury Systems AG, C=DE
Algorithm: RSA; Serial number: 0x2ec09da74e9247da
Valid from Fri Dec 23 22:04:34 CST 2016 until Mon Dec 23 22:04:34 CST 2030

adding as trusted cert:
Subject: CN=Issuing Certification Authority, OU=Sysadmin Team, O=360 Treasury Systems AG, C=DE
Issuer: CN=Root Certification Authority, OU=Sysadmin Team, O=360 Treasury Systems AG, C=DE
Algorithm: RSA; Serial number: 0x4158dfbd6b0a96bb
Valid from Fri Dec 23 22:05:53 CST 2016 until Sat Dec 23 22:05:53 CST 2023

trigger seeding of SecureRandom
done seeding SecureRandom
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session

• • • ClientHello, TLSv1.2
      RandomCookie: GMT: 1526460512 bytes = { 58, 213, 205, 241, 212, 73, 219, 161, 144, 98, 52, 91, 241, 165, 108, 180, 251, 112, 36, 206, 93, 44, 219, 44, 154, 111, 191, 171 }

      Session ID: {}
      Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
      Compression Methods:

      { 0 }

      Extension elliptic_curves, curve names:

      {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}

      Extension ec_point_formats, formats: [uncompressed]
      Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
      ***
      [write] MD5 and SHA1 hashes: len = 239
      0000: 01 00 00 EB 03 03 5B FC F0 60 3A D5 CD F1 D4 49 ......[..`:....I
      0010: DB A1 90 62 34 5B F1 A5 6C B4 FB 70 24 CE 5D 2C ...b4[..l..p$.],
      0020: DB 2C 9A 6F BF AB 00 00 64 C0 24 C0 28 00 3D C0 .,.o....d.$.(.=.
      0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5...
      0040: 0F 00 39 00 38 C0 23 C0 27 00 3C C0 25 C0 29 00 ..9.8.#.'.<.%.).
      0050: 67 00 40 C0 09 C0 13 00 2F C0 04 C0 0E 00 33 00 g.@...../.....3.
      0060: 32 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F 00 2.,.+.0.....2...
      0070: A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 08 C0 ../...-.1.......
      0080: 12 00 0A C0 03 C0 0D 00 16 00 13 00 FF 01 00 00 ................
      0090: 5E 00 0A 00 34 00 32 00 17 00 01 00 03 00 13 00 ^...4.2.........
      00A0: 15 00 06 00 07 00 09 00 0A 00 18 00 0B 00 0C 00 ................
      00B0: 19 00 0D 00 0E 00 0F 00 10 00 11 00 02 00 12 00 ................
      00C0: 04 00 05 00 14 00 08 00 16 00 0B 00 02 01 00 00 ................
      00D0: 0D 00 1C 00 1A 06 03 06 01 05 03 05 01 04 03 04 ................
      00E0: 01 04 02 03 03 03 01 03 02 02 03 02 01 02 02 ...............
      NioProcessor-2, WRITE: TLSv1.2 Handshake, length = 239
      [Raw write]: length = 244
      0000: 16 03 03 00 EF 01 00 00 EB 03 03 5B FC F0 60 3A ...........[..`:
      0010: D5 CD F1 D4 49 DB A1 90 62 34 5B F1 A5 6C B4 FB ....I...b4[..l..
      0020: 70 24 CE 5D 2C DB 2C 9A 6F BF AB 00 00 64 C0 24 p$.],.,.o....d.$
      0030: C0 28 00 3D C0 26 C0 2A 00 6B 00 6A C0 0A C0 14 .(.=.&.*.k.j....
      0040: 00 35 C0 05 C0 0F 00 39 00 38 C0 23 C0 27 00 3C .5.....9.8.#.'.<
      0050: C0 25 C0 29 00 67 00 40 C0 09 C0 13 00 2F C0 04 .%.).g.@...../..
      0060: C0 0E 00 33 00 32 C0 2C C0 2B C0 30 00 9D C0 2E ...3.2.,.+.0....
      0070: C0 32 00 9F 00 A3 C0 2F 00 9C C0 2D C0 31 00 9E .2...../...-.1..
      0080: 00 A2 C0 08 C0 12 00 0A C0 03 C0 0D 00 16 00 13 ................
      0090: 00 FF 01 00 00 5E 00 0A 00 34 00 32 00 17 00 01 .....^...4.2....
      00A0: 00 03 00 13 00 15 00 06 00 07 00 09 00 0A 00 18 ................
      00B0: 00 0B 00 0C 00 19 00 0D 00 0E 00 0F 00 10 00 11 ................
      00C0: 00 02 00 12 00 04 00 05 00 14 00 08 00 16 00 0B ................
      00D0: 00 02 01 00 00 0D 00 1C 00 1A 06 03 06 01 05 03 ................
      00E0: 05 01 04 03 04 01 04 02 03 03 03 01 03 02 02 03 ................
      00F0: 02 01 02 02 ....
      [Raw read]: length = 5
      0000: 16 03 03 00 51 ....Q
      [Raw read]: length = 81
      0000: 02 00 00 4D 03 03 5B FC F0 60 AE 8D 17 B5 8E 84 ...M..[..`......
      0010: CF D5 5C 73 E2 E2 9F 4C 6E DE 5A F6 70 84 DC 26 ..\s...Ln.Z.p..&
      0020: BD 46 7C D7 F9 1B 20 B7 8F 74 A3 FE 3A 4A CA 76 .F.... ..t..:J.v
      0030: 42 16 15 1C 42 05 DF 71 05 EC D2 19 06 51 B2 37 B...B..q.....Q.7
      0040: D3 45 74 78 DA EE 45 00 3D 00 00 05 FF 01 00 01 .Etx..E.=.......
      0050: 00 .
      NioProcessor-2, READ: TLSv1.2 Handshake, length = 81

    • ServerHello, TLSv1.2
      RandomCookie: GMT: 1526460512 bytes = { 174, 141, 23, 181, 142, 132, 207, 213, 92, 115, 226, 226, 159, 76, 110, 222, 90, 246, 112, 132, 220, 38, 189, 70, 124, 215, 249, 27 }

      Session ID:

      {183, 143, 116, 163, 254, 58, 74, 202, 118, 66, 22, 21, 28, 66, 5, 223, 113, 5, 236, 210, 25, 6, 81, 178, 55, 211, 69, 116, 120, 218, 238, 69}

      Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256
      Compression Method: 0
      Extension renegotiation_info, renegotiated_connection: <empty>
      ***
      %% Initialized: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA256]

  • TLS_RSA_WITH_AES_256_CBC_SHA256
    [read] MD5 and SHA1 hashes: len = 81
    0000: 02 00 00 4D 03 03 5B FC F0 60 AE 8D 17 B5 8E 84 ...M..[..`......
    0010: CF D5 5C 73 E2 E2 9F 4C 6E DE 5A F6 70 84 DC 26 ..\s...Ln.Z.p..&
    0020: BD 46 7C D7 F9 1B 20 B7 8F 74 A3 FE 3A 4A CA 76 .F.... ..t..:J.v
    0030: 42 16 15 1C 42 05 DF 71 05 EC D2 19 06 51 B2 37 B...B..q.....Q.7
    0040: D3 45 74 78 DA EE 45 00 3D 00 00 05 FF 01 00 01 .Etx..E.=.......
    0050: 00 .
    [Raw read]: length = 5
    0000: 16 03 03 06 17 .....
    [Raw read]: length = 1559
    0000: 0B 00 06 13 00 06 10 00 06 0D 30 82 06 09 30 82 ..........0...0.
    0010: 03 F1 A0 03 02 01 02 02 08 08 86 A7 7C 19 C2 57 ...............W
    0020: F7 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B 05 00 .0...*.H........
    0030: 30 71 31 0B 30 09 06 03 55 04 06 13 02 44 45 31 0q1.0...U....DE1
    0040: 20 30 1E 06 03 55 04 0A 0C 17 33 36 30 20 54 72 0...U....360 Tr
    0050: 65 61 73 75 72 79 20 53 79 73 74 65 6D 73 20 41 easury Systems A
    0060: 47 31 16 30 14 06 03 55 04 0B 0C 0D 53 79 73 61 G1.0...U....Sysa
    0070: 64 6D 69 6E 20 54 65 61 6D 31 28 30 26 06 03 55 dmin Team1(0&..U
    0080: 04 03 0C 1F 49 73 73 75 69 6E 67 20 43 65 72 74 ....Issuing Cert
    0090: 69 66 69 63 61 74 69 6F 6E 20 41 75 74 68 6F 72 ification Author
    00A0: 69 74 79 30 1E 17 0D 31 37 30 37 32 35 30 37 31 ity0...170725071
    00B0: 32 31 35 5A 17 0D 31 39 30 37 32 35 30 37 31 32 215Z..1907250712
    00C0: 31 35 5A 30 81 95 31 0B 30 09 06 03 55 04 06 13 15Z0..1.0...U...
    00D0: 02 44 45 31 0F 30 0D 06 03 55 04 08 0C 06 48 65 .DE1.0...U....He
    00E0: 73 73 65 6E 31 1A 30 18 06 03 55 04 07 0C 11 46 ssen1.0...U....F
    00F0: 72 61 6E 6B 66 75 72 74 20 61 6D 20 4D 61 69 6E rankfurt am Main
    0100: 31 20 30 1E 06 03 55 04 0A 0C 17 33 36 30 20 54 1 0...U....360 T
    0110: 72 65 61 73 75 72 79 20 53 79 73 74 65 6D 73 20 reasury Systems
    0120: 41 47 31 16 30 14 06 03 55 04 0B 0C 0D 53 79 73 AG1.0...U....Sys
    0130: 61 64 6D 69 6E 20 54 65 61 6D 31 1F 30 1D 06 03 admin Team1.0...
    0140: 55 04 03 0C 16 33 36 30 54 20 50 72 6F 64 20 53 U....360T Prod S
    0150: 53 4C 20 45 6E 64 70 6F 69 6E 74 30 82 01 22 30 SL Endpoint0.."0
    0160: 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 ...*.H..........
    0170: 01 0F 00 30 82 01 0A 02 82 01 01 00 BB D7 1C EE ...0............
    0180: 6B 4D F3 B8 25 8D 65 6E 92 FE 28 14 BE AA 07 BD kM..%.en..(.....
    0190: C1 96 96 74 14 29 75 EA 9E 8D 64 FF 76 A5 BB 51 ...t.)u...d.v..Q
    01A0: BC 47 F0 36 40 88 F9 8F 90 6C 98 F9 3B EA 6E 81 [email protected]..;.n.
    01B0: F2 08 EA AF 06 E1 01 5E 71 23 E7 86 E0 27 FB D5 .......^q#...'..
    01C0: E8 2F AF 08 6A F5 DF 99 2B CF E7 FC 03 34 31 6D ./..j...+....41m
    01D0: 2F BA CA 60 40 74 29 37 5A 0D A6 AC 9F 6B 54 86 /..`@t)7Z....kT.
    01E0: 59 21 05 8C 34 5D DC B0 F0 86 BB BA 93 8B 16 34 Y!..4].........4
    01F0: F6 65 51 12 E8 DE F1 7D F2 54 79 65 5F EC 41 CB .eQ......Tye_.A.
    0200: E8 9F BF 3E 34 CA A6 92 AC FE 5C 92 A7 7A 1D 52 ...>4.....\..z.R
    0210: B2 E9 82 DA CA D7 BA C4 73 85 1A 18 B9 A4 57 30 ........s.....W0
    0220: FD 77 9C AB 7C DE 5D 0B 03 78 6A 5D D2 C8 68 39 .w....]..xj]..h9
    0230: 19 F0 4E 4B C0 B1 84 D1 EE DE 9A A1 F0 4F E7 85 ..NK.........O..
    0240: 1A B5 C0 A6 C6 76 5C 31 F2 8B D6 EC DF 07 E7 05 .....v\1........
    0250: 2F 77 DC 9C 29 31 1C 01 ED 61 EE BF 1B DF BB 8C /w..)1...a......
    0260: 52 19 D6 A0 AB 77 04 FB 34 BF 76 D9 8F 55 BC C8 R....w..4.v..U..
    0270: 8E F5 46 1D 6E 2D 13 D1 B9 5E 90 91 02 03 01 00 ..F.n-...^......
    0280: 01 A3 82 01 7E 30 82 01 7A 30 0C 06 03 55 1D 13 .....0..z0...U..
    0290: 01 01 FF 04 02 30 00 30 1F 06 03 55 1D 23 04 18 .....0.0...U.#..
    02A0: 30 16 80 14 E4 4B DF C0 AA 47 AD B3 B9 4A A6 29 0....K...G...J.)
    02B0: E5 42 9C F3 3F E7 13 43 30 4C 06 08 2B 06 01 05 .B..?..C0L..+...
    02C0: 05 07 01 01 04 40 30 3E 30 3C 06 08 2B 06 01 05 .....@0>0<..+...
    02D0: 05 07 30 02 86 30 68 74 74 70 3A 2F 2F 70 6B 69 ..0..0http://pki
    02E0: 2E 33 36 30 74 2E 63 6F 6D 2F 63 65 72 74 73 2F .360t.com/certs/
    02F0: 33 36 30 74 2D 73 75 62 72 6F 6F 74 2D 63 61 2D 360t-subroot-ca-
    0300: 30 31 2E 63 65 72 30 3F 06 03 55 1D 20 04 38 30 01.cer0?..U. .80
    0310: 36 30 34 06 08 2A 82 14 82 68 01 02 04 30 28 30 604..*...h...0(0
    0320: 26 06 08 2B 06 01 05 05 07 02 01 16 1A 68 74 74 &..+.........htt
    0330: 70 3A 2F 2F 70 6B 69 2E 33 36 30 74 2E 63 6F 6D p://pki.360t.com
    0340: 2F 70 6F 6C 69 63 79 30 1D 06 03 55 1D 25 04 16 /policy0...U.%..
    0350: 30 14 06 08 2B 06 01 05 05 07 03 02 06 08 2B 06 0.............
    0360: 01 05 05 07 03 01 30 3F 06 03 55 1D 1F 04 38 30 ......0?..U...80
    0370: 36 30 34 A0 32 A0 30 86 2E 68 74 74 70 3A 2F 2F 604.2.0..http://
    0380: 70 6B 69 2E 33 36 30 74 2E 63 6F 6D 2F 63 72 6C pki.360t.com/crl
    0390: 2F 33 36 30 74 2D 73 75 62 72 6F 6F 74 2D 63 61 /360t-subroot-ca
    03A0: 2D 30 31 2E 63 72 6C 30 1D 06 03 55 1D 0E 04 16 -01.crl0...U....
    03B0: 04 14 50 6B 3A 75 C0 DE 02 2D 53 3D BF CD 09 84 ..Pk:u...-S=....
    03C0: 98 86 82 AE 30 10 30 2B 06 03 55 1D 10 04 24 30 ....0.0+..U...$0
    03D0: 22 80 0F 32 30 31 37 30 37 32 35 30 37 31 32 31 "..2017072507121
    03E0: 35 5A 81 0F 32 30 31 38 30 37 32 35 30 37 31 32 5Z..201807250712
    03F0: 31 35 5A 30 0E 06 03 55 1D 0F 01 01 FF 04 04 03 15Z0...U........
    0400: 02 07 80 30 0D 06 09 2A 86 48 86 F7 0D 01 01 0B ...0...*.H......
    0410: 05 00 03 82 02 01 00 13 50 BA 85 34 92 93 1D 22 ........P..4..."
    0420: 75 A9 FD 28 24 A7 47 17 90 0C 8B 59 05 2A F9 F0 u..($.G....Y.*..
    0430: F8 7D 99 4F 8F 75 BF D1 C4 3F E7 A7 98 CE D3 58 ...O.u...?.....X
    0440: 88 13 83 E5 EB 3E 60 4E 83 AA 80 FC 2E 7B 01 60 .....>`N.......`
    0450: 07 83 A6 C1 31 DB E1 0A C5 43 EE 27 17 08 8F 4F ....1....C.'...O
    0460: 8B AB 65 7A D7 C8 D3 AD A8 75 B7 62 E7 53 01 DC ..ez.....u.b.S..
    0470: 33 BB B7 2C 96 D5 3F 20 FC 69 FE 3D C1 5E CB 44 3..,..? .i.=.^.D
    0480: AB F8 BE 7B 99 01 79 BB 57 A4 94 D1 C5 11 04 65 ......y.W......e
    0490: 75 8D F8 F0 9F A6 2C E4 8A 51 B0 01 9D 2F DF 31 u.....,..Q.../.1
    04A0: 9A B8 8E D7 3C B4 62 76 3C DD 2A 0C 35 F2 C7 0B ....<.bv<.*.5...
    04B0: 20 D5 58 73 06 20 3C D1 6B 63 96 37 6E EA 1B 65 .Xs. <.kc.7n..e
    04C0: BF 6B 5E AB 4C CA D6 91 7E CD BC ED 84 CC B9 D9 .k^.L...........
    04D0: AB 25 80 93 28 FD 85 FE 21 8E 0F 2D 3D 22 91 05 .%..(...!..-="..
    04E0: A7 59 72 03 20 E8 D6 10 7E CF B0 34 7F 79 3B 47 .Yr. ......4.y;G
    04F0: C5 10 C1 09 EC FC 4A 3E BC 21 F0 FB 7F CF 4C C0 ......J>.!....L.
    0500: 4B 98 1B 7E 3B 06 92 51 73 F4 35 60 D8 7B 72 42 K...;..Qs.5`..rB
    0510: 87 3F BF 9D 4A 55 EB 40 24 57 F6 16 7B 4E 39 BB .?..JU.@$W...N9.
    0520: E5 61 40 C2 D9 2B A7 5B 81 09 C2 69 35 F8 A1 A2 .a@..+.[...i5...
    0530: A7 BA 67 42 7C A3 C5 E6 9E AC 3A C3 8C 6F EB 53 ..gB......:..o.S
    0540: 0A 65 39 67 64 C6 EC 7B 57 7B 9E 54 AE E4 2E A3 .e9gd...W..T....
    0550: 05 E9 0B 10 97 BF BC 47 CA F6 C7 1B 24 A6 CD D9 .......G....$...
    0560: B7 B7 6F A1 D0 31 21 F4 F7 1D E6 42 1C 53 E5 22 ..o..1!....B.S."
    0570: F6 D4 67 36 B0 0B 5C 69 7A B3 F3 31 F3 DA 48 DB ..g6..\iz..1..H.
    0580: EF 7A 1B 99 A4 AE 65 4E 5A 3D 5B 87 9D 1C A6 1A .z....eNZ=[.....
    0590: 1C 07 0D 8A 79 15 AD D1 8D 87 22 6A D2 2B D3 DC ....y....."j.+..
    05A0: 9C 55 05 FB 88 7B 91 15 ED EE 30 30 DE A6 79 B8 .U........00..y.
    05B0: E9 49 B7 AA DA CB 3C 4C 4E FE FB 44 93 F6 15 9A .I....<LN..D....
    05C0: 04 A9 18 E1 51 82 05 CE 43 4E 99 C7 14 FA 1B 8C ....Q...CN......
    05D0: F6 D8 2C 88 E7 33 98 02 4A 0E 41 C0 F5 88 6E 57 ..,..3..J.A...nW
    05E0: CF 59 F8 14 7F E0 51 DA 28 4E 39 C6 D1 0C B6 05 .Y....Q.(N9.....
    05F0: A1 72 9C 7D 68 6F E0 D5 F9 F3 0B 87 7E AF 79 EC .r..ho........y.
    0600: C1 46 68 BC CE 91 98 47 1C F8 9D 02 CF 82 27 D2 .Fh....G......'.
    0610: 64 1D FC C8 DC F2 C8 d......
    NioProcessor-2, READ: TLSv1.2 Handshake, length = 1559
    • Certificate chain
      chain [0] = [
      [
      Version: V3
      Subject: CN=360T Prod SSL Endpoint, OU=Sysadmin Team, O=360 Treasury Systems AG, L=Frankfurt am Main, ST=Hessen, C=DE
      Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11

Key: Sun RSA public key, 2048 bits
modulus: 23712639208870547784934191030619387186574960001448184563206627792919596794770863916315542403970126901173207460879435287069014771623470331049929375045431124035167295456775590846384585558930676280801332442931483209242576237017576066124335085690849009132657890501481937293890660164877270727104316253459785959195876890654110642093619312253053142562293031483654484631881868891371699187919798922793667210760211106397007627967008550144244902921525222408109884089361945984512779871487391974953810469509555802158583127744803376858365706377038448938877003235243384520886173915777511443225158149320165300692093957485459943624849
public exponent: 65537
Validity: [From: Tue Jul 25 15:12:15 CST 2017,
To: Thu Jul 25 15:12:15 CST 2019]
Issuer: CN=Issuing Certification Authority, OU=Sysadmin Team, O=360 Treasury Systems AG, C=DE
SerialNumber: [ 0886a77c 19c257f7]

Certificate Extensions: 7
[1]: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: E4 4B DF C0 AA 47 AD B3 B9 4A A6 29 E5 42 9C F3 .K...G...J.).B..
0010: 3F E7 13 43 ?..C
]
]

[2]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]

[3]: ObjectId: 2.5.29.32 Criticality=false
CertificatePolicies [
[CertificatePolicyId: [1.2.276.360.1.2.4]
[PolicyQualifierInfo: [
qualifierID: 1.3.6.1.5.5.7.2.1
qualifier: 0000: 16 1A 68 74 74 70 3A 2F 2F 70 6B 69 2E 33 36 30 ..http://pki.360
0010: 74 2E 63 6F 6D 2F 70 6F 6C 69 63 79 t.com/policy

]] ]
]

[4]: ObjectId: 2.5.29.37 Criticality=false
ExtendedKeyUsages [
clientAuth
serverAuth
]

[5]: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
]

[6]: ObjectId: 2.5.29.16 Criticality=false
PrivateKeyUsage: [
From: Tue Jul 25 15:12:15 CST 2017, To: Wed Jul 25 15:12:15 CST 2018]

[7]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 50 6B 3A 75 C0 DE 02 2D 53 3D BF CD 09 84 98 86 Pk:u...-S=......
0010: 82 AE 30 10 ..0.
]
]

Unparseable certificate extensions: 2
[1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
Unparseable AuthorityInfoAccess extension due to
java.io.IOException: invalid URI name (host portion is not a valid DNS name, IPv4 address, or IPv6 address):http://pki.360t.com/certs/360t-subroot-ca-01.cer

0000: 30 3E 30 3C 06 08 2B 06 01 05 05 07 30 02 86 30 0>0<..+.....0..0
0010: 68 74 74 70 3A 2F 2F 70 6B 69 2E 33 36 30 74 2E http://pki.360t.
0020: 63 6F 6D 2F 63 65 72 74 73 2F 33 36 30 74 2D 73 com/certs/360t-s
0030: 75 62 72 6F 6F 74 2D 63 61 2D 30 31 2E 63 65 72 ubroot-ca-01.cer

[2]: ObjectId: 2.5.29.31 Criticality=false
Unparseable CRLDistributionPoints extension due to
java.io.IOException: invalid URI name (host portion is not a valid DNS name, IPv4 address, or IPv6 address):http://pki.360t.com/crl/360t-subroot-ca-01.crl

0000: 30 36 30 34 A0 32 A0 30 86 2E 68 74 74 70 3A 2F 0604.2.0..http:/
0010: 2F 70 6B 69 2E 33 36 30 74 2E 63 6F 6D 2F 63 72 /pki.360t.com/cr
0020: 6C 2F 33 36 30 74 2D 73 75 62 72 6F 6F 74 2D 63 l/360t-subroot-c
0030: 61 2D 30 31 2E 63 72 6C a-01.crl

]
Algorithm: [SHA256withRSA]
Signature:
0000: 13 50 BA 85 34 92 93 1D 22 75 A9 FD 28 24 A7 47 .P..4..."u..($.G
0010: 17 90 0C 8B 59 05 2A F9 F0 F8 7D 99 4F 8F 75 BF ....Y.*.....O.u.
0020: D1 C4 3F E7 A7 98 CE D3 58 88 13 83 E5 EB 3E 60 ..?.....X.....>`
0030: 4E 83 AA 80 FC 2E 7B 01 60 07 83 A6 C1 31 DB E1 N.......`....1..
0040: 0A C5 43 EE 27 17 08 8F 4F 8B AB 65 7A D7 C8 D3 ..C.'...O..ez...
0050: AD A8 75 B7 62 E7 53 01 DC 33 BB B7 2C 96 D5 3F ..u.b.S..3..,..?
0060: 20 FC 69 FE 3D C1 5E CB 44 AB F8 BE 7B 99 01 79 .i.=.^.D......y
0070: BB 57 A4 94 D1 C5 11 04 65 75 8D F8 F0 9F A6 2C .W......eu.....,
0080: E4 8A 51 B0 01 9D 2F DF 31 9A B8 8E D7 3C B4 62 ..Q.../.1....<.b
0090: 76 3C DD 2A 0C 35 F2 C7 0B 20 D5 58 73 06 20 3C v<.*.5... .Xs. <
00A0: D1 6B 63 96 37 6E EA 1B 65 BF 6B 5E AB 4C CA D6 .kc.7n..e.k^.L..
00B0: 91 7E CD BC ED 84 CC B9 D9 AB 25 80 93 28 FD 85 ..........%..(..
00C0: FE 21 8E 0F 2D 3D 22 91 05 A7 59 72 03 20 E8 D6 .!..-="...Yr. ..
00D0: 10 7E CF B0 34 7F 79 3B 47 C5 10 C1 09 EC FC 4A ....4.y;G......J
00E0: 3E BC 21 F0 FB 7F CF 4C C0 4B 98 1B 7E 3B 06 92 >.!....L.K...;..
00F0: 51 73 F4 35 60 D8 7B 72 42 87 3F BF 9D 4A 55 EB Qs.5`..rB.?..JU.
0100: 40 24 57 F6 16 7B 4E 39 BB E5 61 40 C2 D9 2B A7 @$W...N9..a@..+.
0110: 5B 81 09 C2 69 35 F8 A1 A2 A7 BA 67 42 7C A3 C5 [...i5.....gB...
0120: E6 9E AC 3A C3 8C 6F EB 53 0A 65 39 67 64 C6 EC ...:..o.S.e9gd..
0130: 7B 57 7B 9E 54 AE E4 2E A3 05 E9 0B 10 97 BF BC .W..T...........
0140: 47 CA F6 C7 1B 24 A6 CD D9 B7 B7 6F A1 D0 31 21 G....$.....o..1!
0150: F4 F7 1D E6 42 1C 53 E5 22 F6 D4 67 36 B0 0B 5C ....B.S."..g6..\
0160: 69 7A B3 F3 31 F3 DA 48 DB EF 7A 1B 99 A4 AE 65 iz..1..H..z....e
0170: 4E 5A 3D 5B 87 9D 1C A6 1A 1C 07 0D 8A 79 15 AD NZ=[.........y..
0180: D1 8D 87 22 6A D2 2B D3 DC 9C 55 05 FB 88 7B 91 ..."j.+...U.....
0190: 15 ED EE 30 30 DE A6 79 B8 E9 49 B7 AA DA CB 3C ...00..y..I....<
01A0: 4C 4E FE FB 44 93 F6 15 9A 04 A9 18 E1 51 82 05 LN..D........Q..
01B0: CE 43 4E 99 C7 14 FA 1B 8C F6 D8 2C 88 E7 33 98 .CN........,..3.
01C0: 02 4A 0E 41 C0 F5 88 6E 57 CF 59 F8 14 7F E0 51 .J.A...nW.Y....Q
01D0: DA 28 4E 39 C6 D1 0C B6 05 A1 72 9C 7D 68 6F E0 .(N9......r..ho.
01E0: D5 F9 F3 0B 87 7E AF 79 EC C1 46 68 BC CE 91 98 .......y..Fh....
01F0: 47 1C F8 9D 02 CF 82 27 D2 64 1D FC C8 DC F2 C8 G......'.d......

]
***
NioProcessor-2, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: KeyUsage does not allow key encipherment
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_256_CBC_SHA256]
NioProcessor-2, SEND TLSv1.2 ALERT: fatal, description = certificate_unknown
NioProcessor-2, WRITE: TLSv1.2 Alert, length = 2
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: General SSLEngine problem
NioProcessor-2, called closeOutbound()
NioProcessor-2, closeOutboundInternal()
[Raw write]: length = 7
0000: 15 03 03 00 02 02 2E .......
NioProcessor-2, called closeInbound()
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
NioProcessor-2, called closeOutbound()
NioProcessor-2, closeOutboundInternal()

When seeking for optimizations for file sync I have come across the FileStore.set method and was wondering about its thread safety. I labelled this issue as improvement, because I am not sure if it is maybe already been taken care of somewhere else, however lets look at this method:

https://github.com/quickfix-j/quickfixj/blob/045be5c09f872b1bf7b1a8ed2904efd0030c59bd/quickfixj-core/src/main/java/quickfix/FileStore.java#L364

As you can see, at the very beginning of the function the offset inside the RandomAccessFile is taken as the message offset. The actual writing of the information happens after many more instructions, one of them even including a synchronization on a file descriptor.

According to my understanding the offset obtained on line 365 could easily be outdated by the time the message is written at line 377. Of course it is possible, that synchronization is supposed to be happening outside of the set method, however I do not see any contract enforcing this in MessageStore.set.

Should this method not be thread safe to avoid potential data inconsitencies?

The issues is based on my observation and investigation. Please correct me if I misunderstood it, thanks!

Scenario:

• We use SocketInitiator to connect to vendor server and consume data.
• ResendRequestChunkSize is set to 5000.
  Now assume our process is down for several hours, and 10 million messages are queued up on the vendor side. Once we get connected again, we will send about 2000 resend requests with batch size of 5000 to catch up to the latest message. In between of every two batches, vendor sends latest messages to us, which have much higher sequence number, and are added to the messageQueue in SessionState. They will not be processed until all the 10 million messages have been received by us, which means the memory will keep expanding during our "catching up" time. And this will eventually cause out of memory issue.

Proposed Solution:

Not limiting messageQueue size could be risky. My understanding is that messageQueue should only store temporary out of order messages, and if there are say 100,000 messages in it, there must be something wrong. Therefore options should be provided to discard newer messages instead of keep eating up the memory.

My proposal is to:

1. Change LinkedHashMap to TreeMap. Even it may slow things down a little bit, O(lg n) should work fine given the size of messageQueue is normally very small. Even when it grows up, sequence number ordered entries should be beneficial.
2. Update enqueue method to limit the size of messageQueue. If the queue is full, then add the new message and remove the entry with highest sequence number.
3. Update dequeueMessagesUpTo method.

If you think this could work, I would be happy to submit a PR, thanks!

In https://www.quickfixj.org/usermanual/2.0.0/usage/configuration.html

It says the default for FileStoreMaxCachedMsgs is 10k. I believe that this isn't true. It's Integer.MAX_VALUE.

I think this is an old issue, but still seems to be a problem with the latest version of quickfixj 2.1.0.

After my initiator sends a Logon message, the acceptor immediately sends back a Logout Message followed by closing the connection. Looking at the tcpdump, it is clear why the connection is closed

x.x.x.x.56988 > x.x.x.x.25265: Flags [P.], cksum 0x9863 (incorrect -> 0xe431), seq 1:104, ack 1, win 21, length 103
E.....@[email protected].(.7.>..+P....c..8=FIX.4.2.9=81.35=A.34=1161.49=XXX.52=20181130-15:08:36.259.56=**.98=0.108=10.554=**.10=026.
15:08:36.336321 IP (tos 0x60, ttl 48, id 0, offset 0, flags [DF], proto TCP (6), length 188)
x.x.x.x.x > x.x.x.x.56988: Flags [P.], cksum 0xdd5d (correct), seq 1:149, ack 104, win 4096, length 148
E`[email protected]...>..+(.8YP....]..8=FIX.4.2.9=0124.35=5.34=552397.49=XXX.52=20181130-15:08:36.298.56=XXX.789=469881.58=MsgSeqNum too low, expecting 469881 but received 1161.10=079.

The problem is that fromAdmin is never called before onLogout because of the connection reset following the logout message. IE: it is not in the QFJ log file but I can see it in the tcp dump.

The initiator stack trace (ie connection reset) looks like

"..."
"\tat quickfix.Session.disconnect(Session.java:2028)"
"\tat quickfix.mina.AbstractIoHandler.exceptionCaught(AbstractIoHandler.java:84)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:828)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:590)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:48)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:937)"
"\tat org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:102)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:590)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:48)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:937)"
"\tat org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:102)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:590)"
"\tat org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:580)"
"\tat org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:729)"
"\tat org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:659)"
"\tat org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:648)"
"\tat org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)"
"\tat org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1120)"
"\tat org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)"
"\tat java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)"
"\tat java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)"
"\tat java.base/java.lang.Thread.run(Thread.java:844)"

and all I receive on the initiator side is

"Initiated logon request"
"Disconnecting: Socket exception (/x.x.x.x:25265): java.io.IOException: Connection reset by peer"
"onLogout: FIX.4.2:XXX->XXX"

message from Christoph John

So this seems to be a special case that is not covered by the unit test.
The problem is that the session is disconnected the "hard way" through the IOException, not waiting for messages to be processed that might still be in flight. This might have to be changed in the AbstractIoHandler to behave similar to the sessionClosed() callback.

But this is only a first quick analysis. Of course this has to be made reproducable in a unit test and then fixed.

The optimizations in commit 6229d0722d8c6f6e7b2b251772a92caf2f4bdc25 cause a regression where using fields with a non-default charset such as UTF-8 causes message corruption (even if the charset is properly set via CharsetSupport.setCharset()).

Further, the test that caught this regression (MessageTest.testMessageWithEncodedField via its helper method) was modified in the same commit to work around the test failure, so that the test passes but the bug still occurs in real applications..

I will submit a PR shortly with a fix.

We have been using DynamicAcceptorSessionProvider in our project for quite sometime now, together with ThreadedSocketAcceptor.
After a recent upgrade to Quickfix 2.1.0 (from 1.5.3), we saw some errors that I believe is caused by Quickfix being unable to find the session settings.
The stack trace looks like below:

2018-11-19 00:01:13,236|| ERROR |||| org.quickfixj.QFJException: quickfix.ConfigError: Missing ConnectionType | NioProcessor-23 | q.m.a.AcceptorIoHandler
org.quickfixj.QFJException: quickfix.ConfigError: Missing ConnectionType
at quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:153) ~[quickfixj-core-2.1.0.jar:2.1.0]
at quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118) ~[quickfixj-core-2.1.0.jar:2.1.0]
at quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129) ~[quickfixj-core-2.1.0.jar:2.1.0]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) ~[mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) [mina-core-2.0.19.jar:?]
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437) [mina-core-2.0.19.jar:?]
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) [mina-core-2.0.19.jar:?]
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) [mina-core-2.0.19.jar:?]
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) [mina-core-2.0.19.jar:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0-zing_18.06.0.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0-zing_18.06.0.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_18.06.0.0]
Caused by: quickfix.ConfigError: Missing ConnectionType
at quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:102) ~[quickfixj-core-2.1.0.jar:2.1.0]

I find this very strange, as we definitely have the session configuration, and the session configuration specifies the 'ConnectionType' (which is an 'acceptor').

We have recently upgraded from quickfixj 1.5.3 to 2.1.0, and saw the following error:

java.util.ConcurrentModificationException: null
        at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442) ~[?:1.8.0-zing_18.06.0.0]
        at java.util.HashMap$KeyIterator.next(HashMap.java:1466) ~[?:1.8.0-zing_18.06.0.0]
        at java.util.AbstractCollection.finishToArray(AbstractCollection.java:232) ~[?:1.8.0-zing_18.06.0.0]
        at java.util.AbstractCollection.toArray(AbstractCollection.java:143) ~[?:1.8.0-zing_18.06.0.0]
        at java.util.ArrayList.<init>(ArrayList.java:178) ~[?:1.8.0-zing_18.06.0.0]
        at quickfix.mina.SessionConnector.getSessions(SessionConnector.java:160) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at org.quickfixj.jmx.mbean.connector.ConnectorAdmin.registerSessions(ConnectorAdmin.java:178) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at org.quickfixj.jmx.mbean.connector.ConnectorAdmin.lambda$postRegister$0(ConnectorAdmin.java:170) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335) ~[?:1.8.0-zing_18.06.0.0]
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327) ~[?:1.8.0-zing_18.06.0.0]
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263) ~[?:1.8.0-zing_18.06.0.0]
        at quickfix.mina.SessionConnector.addDynamicSession(SessionConnector.java:166) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at quickfix.mina.acceptor.DynamicAcceptorSessionProvider.getSession(DynamicAcceptorSessionProvider.java:150) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at com.anz.axle.direct.connectafix.quickfix.QuickfixAcceptor$1.getSession(QuickfixAcceptor.java:107) ~[spdee-direct-connectafix-4.1798.jar:?]
        at quickfix.mina.acceptor.AcceptorIoHandler.findQFSession(AcceptorIoHandler.java:118) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at quickfix.mina.AbstractIoHandler.messageReceived(AbstractIoHandler.java:129) ~[quickfixj-core-2.1.0.jar:2.1.0]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:997) ~[mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) [mina-core-2.0.19.jar:?]
        at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:437) [mina-core-2.0.19.jar:?]
        at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:256) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1114) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:121) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:641) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:634) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:539) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$1200(AbstractPollingIoProcessor.java:68) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1242) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.process(AbstractPollingIoProcessor.java:1231) [mina-core-2.0.19.jar:?]
        at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:683) [mina-core-2.0.19.jar:?]
        at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) [mina-core-2.0.19.jar:?]

which seems like a bug in quickfixj itself. Looking at how the map inside SessionConnector get set... it looks like it is just a HashMap from AbstractSocketAcceptor#createSessions().
Shouldnt it use a concurrent map instead?

QFJ-428 made the generic setField(int key, Field<?> field) method public, claiming this will avoid having to use a switch statement and call each type-specific overload explicitly.

However, this is misleading and introduces a bug, since the two are not equivalent.

Specifically, the type-specific overloads do proper type conversions on the value, while the generic setField does not. For example, if you pass a DoubleField with a very large or small value, it will convert it into a string in scientific notation (with exponent) which is invalid in the FIX protocol, whereas calling the type-specific setField(DoubleField field) will properly use the DoubleConverter to convert it correctly.

When this method was non-public this was less of a problem, assuming its internal usages are correct (I don't know if this is the case, but assume it is). However making it public now creates a pitfall for anyone using this method in client code which will likely result in a bug on some data.

The solution would be to either implement it fully with proper type conversion (e.g. using the switch statement from QFJ-428), or at the very least, to add a javadoc to this method that warns about using it and clearly states that it does not do proper type conversion, so users will be able to decide whether this is what they really intend to do or not.

TransactTime (tag 60) should be in UTC. Default constructor for TransactTime() should return date in UTC. Instead, it uses default local time (LocalDateTime.now()):

public UtcTimeStampField(int field)

As a result, the constructed object is not in UTC.

When creating an initiator or an acceptor (both synchronous and thread-per-session) without specifying either queue size or watermarks, the watermark tracker is still created and is working incorrectly immediately blocking the reads (queue size 0 is > upper watermark of -1).

Watermarks should only be activated when the queue size is not specified and both lower and upper watermarks are configured to values > 0.

Pull request (code change + tests) - https://github.com/quickfix-j/quickfixj/pull/213

Repetitive error: Multiple logons/connections for this session are not allowed
when client try to reconnect to server. (see server logs below)

Looks like session was not cleared correctly after exception.
Exception

Nov  6 06:47:32 aemulator: java.io.IOException: Broken pipe
Nov  6 06:47:32 aemulator: at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
Nov  6 06:47:32 aemulator: at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
Nov  6 06:47:32 aemulator: at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
Nov  6 06:47:32 aemulator: at sun.nio.ch.IOUtil.write(IOUtil.java:65)
Nov  6 06:47:32 aemulator: at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
Nov  6 06:47:32 aemulator: at org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:384)
Nov  6 06:47:32 aemulator: at org.apache.mina.transport.socket.nio.NioProcessor.write(NioProcessor.java:47)
Nov  6 06:47:32 aemulator: at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.writeBuffer(AbstractPollingIoProcessor.java:1107)
Nov  6 06:47:32 aemulator: at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flushNow(AbstractPollingIoProcessor.java:994)
Nov  6 06:47:32 aemulator: at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.flush(AbstractPollingIoProcessor.java:921)
Nov  6 06:47:32 aemulator: at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:688)
Nov  6 06:47:32 aemulator: at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
Nov  6 06:47:32 aemulator: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
Nov  6 06:47:32 aemulator: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
Nov  6 06:47:32 aemulator: at java.lang.Thread.run(Thread.java:748)

Server logs.

2018-11-07 13:06:56.731 +0000 ERROR [NioProcessor-471] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:06:57.736 +0000 ERROR [NioProcessor-472] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:06:58.740 +0000 ERROR [NioProcessor-473] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:06:59.780 +0000 ERROR [NioProcessor-474] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:07:01.446 +0000 ERROR [NioProcessor-475] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:07:03.446 +0000 ERROR [NioProcessor-476] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:07:05.446 +0000 ERROR [NioProcessor-477] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed
2018-11-07 13:07:07.446 +0000 ERROR [NioProcessor-478] quickfixj.errorEventFIX.4.4:emulator->TRADE:  - Multiple logons/connections for this session are not allowed

HI Team,

I have FIX acceptor service written over quickfix/j. We are having an issue which needs urgent resolution as it is impacting our client.

1) In general scenarios where if our acceptor service does receive heartbeat from client in an active connection it sends three consecutive test request and if it does not get response from client , it simply drop the connection which is correct.

2) The problem is if our service receive a logon message (35=A) from client with certain delay assume 9 sec and by the time we response to that logon message it cross 10 sec window. Client timeout the connection as client side timeout window is 10 sec. But for our service since we have responded back to client it assume it as active connection and keep on sending test request through out day the day until we bounce the adaptor. It also does not allow any more connection to the same server.

please help.

Example

Client sent the logon message at 20181017-06:17:29.011
Our Forwarder service received logon at : 2018-10-17T06:17:38,003
Forwarder service forward the connection to backed fixadaptor service which was received by it at 2018-10-17 07:17:41,054
backed adaptor respons back within same time : 2018-10-17 07:17:41,054

But since overall window is more than 10 sec , it is being timed out at client side.

After this backed adaptor keep on sending test request even though there is no heartbeat from client

My application is sending logon request and getting logon response and session get logged in perfectly at first time . After some time session get disconnected due to heartbeat timeout and my application send login again and acceptor send login response within same second but my initiator don't get connected after 10 second it send another login request. Ideally it should not send login request again.

Event logs are

20181015-13:36:34: Sent test request TEST

20181015-13:37:01: Disconnecting: Timed out waiting for heartbeat

20181015-13:37:02: Initiated logon request

20181015-13:37:13: Disconnecting: Timed out waiting for logon response

20181015-13:37:32: Disconnecting: Socket exception (/192.168.40.29:31815): java.io.IOException: Connection reset by peer

20181015-13:38:02: Initiated logon request

Message logs

8=FIX.4.2^A9=69^A35=A^A34=1064^A49=test^A52=20181015-13:37:02.570^A56=test^A98=0^A108=30^A10=075^A
8=FIX.4.2^A9=000593^A35=A^A34=001527^A43=N^A52=20181015-13:37:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=210^A
8=FIX.4.2^A9=69^A35=A^A34=1065^A49=test^A52=20181015-13:38:02.569^A56=test^A98=0^A108=30^A10=085^A
8=FIX.4.2^A9=000593^A35=A^A34=001528^A43=N^A52=20181015-13:38:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=212^A

As you can see we send login request at 20181015-13:37:02.570 and get response at 20181015-13:37:02 then still it send one more login request.
Any help would be really appreciated

I have removed actual SendercompId and Target comp Id

I am using camel 2.14.1 and quickfixh 1.5.3. I have raised in mailing list but no reply and this is production issue so please pardon me.

This code validates the checksum of incoming messages:

Message.java:

private void validateCheckSum(*String* messageData) throws InvalidMessage {
        try {
            // Body length is checked at the protocol layer
            final int checksum = trailer.getInt(CheckSum.FIELD);
            if (checksum != *MessageUtils.checksum(messageData)*) {
                // message will be ignored if checksum is wrong or missing
                throw MessageUtils.newInvalidMessageException("Expected CheckSum=" + MessageUtils.checksum(messageData)
                        + ", Received CheckSum=" + checksum + " in " + messageData, this);
            }
        } catch (final FieldNotFound e) {
            throw MessageUtils.newInvalidMessageException("Field not found: " + e.field + " in " + messageData, this);
        }
    }

And in MessageUtils calculation ends up here:

public static int checksum(*Charset charset*, String data, boolean isEntireMessage) {
        if (CharsetSupport.isStringEquivalent(charset)) { // optimization - skip charset encoding
            int sum = 0;
            int end = isEntireMessage ? data.lastIndexOf("\00110=") : -1;
            int len = end > -1 ? end + 1 : data.length();
            for (int i = 0; i < len; i++) {
                sum += data.charAt(i);
            }
            return sum & 0xFF; // better than sum % 256 since it avoids overflow issues
        }
        return checksum(*data.getBytes(charset)*, isEntireMessage);
    }

So the problem here is that calculation happens NOT on raw network bytes but on a java String that is later transformed to bytes using CharsetSuport's charset, which can be not the same what original message producer used, and produce different bytes.

So in practice this can cause to situation where message with correct checksum will be ignored because was read by QFJ using incorrect charset.

Looks like I'm witnessing this situation. Use case is to use non-unicode symbol in message and different charsets on producer-consumer sides.

Hi,
Don't know if this a bug or we are not using the API correctly.
But since 2.1.0 we observe strange behavior concering the checksum and bodylength field.

JUnit Test:

@Test
public void testBodyLengthAndChecksum() throws FieldNotFound

2.0.0 ====>>>

8=FIX.4.49=1535=AE55=[N/A]10=072
15
072

2.1.0 ====>>>

8=FIX.4.49=1535=AE55=[N/A]10=072
100
000

Any help would be much appreciated.

Greetings,
Simon.

The documentation for MessageStore.set() says:

     * @return true is successful, false otherwise
     * @throws IOException IO error

However the return code is pointless. set is called by SessionState.set which is in turned called by Session.sendRaw, which does the following:

            if (num == 0) {
                final int msgSeqNum = header.getInt(MsgSeqNum.FIELD);
                if (persistMessages) {
                    state.set(msgSeqNum, messageString);
                }
                state.incrNextSenderMsgSeqNum();
            }
            return result;

So the return code is just pointless.

Throwing an exception on the other hand, does cause the return value of sendRaw (and hence Session.send to change.

Perhaps if it returns false Session.sendRaw should return false. (We may still want to call incrNextSenderMsgSeqNum however.)

Following code snippet:
{{
int lower = 10;
int upper = 20;
return SocketAcceptor.newBuilder()
.withQueueWatermarks(lower, upper)
.build();
}}

always ends up with exception:

{{
11:15:17 Caused by: quickfix.ConfigError: invalid queue watermarks, required: 0 <= lower watermark < upper watermark
11:15:17 at quickfix.AbstractSessionConnectorBuilder.withQueueWatermarks(AbstractSessionConnectorBuilder.java:58)
}}}

Method withQueueWatermarks should verify parameters instead of class fields.

I am using FIX4.4 and QuickFIX/ v1.0.0 for its implementation.

I came across a situation where i had subscribed for Market Data and was successfully receiving Snapshot message then suddenly all communication with the Market Session stopped and i didn't receive any more snapshot from the server on the Market Data Session.

When i asked the support they said that they didn't receive any heartbeat from my end after sending the TEST Request messages. so they closed the connection. But some time we didn't see the TEST request in our log file even they sent out.

we configured heartbeat value is 45 secs.

My Questions are:

What might have caused the system to not send out a Heartbeat message?

Using QuickFIX/J how can i ensure my periodic heartbeat message?

Whats the best time interval for heartbeat? (Mine is currently set to 60 seconds)

For Processing Marketdata will take 10-15min if we don't have any session disconnection.

So if we increase heartbeat value, is there any issue?

we Processing marketdata for every 4 hour per day and during this marketdata processing only we are disconnecting sessions.

I have a dictionary which is defined as follows (stripped some stuff out for simplicity)

<message name="QuoteRequest" msgtype="R" msgcat="app">
<field name="QuoteReqID" required="Y"/>
<group name="NoRelatedSym" required="Y">
<component name="Instrument" required="Y"/>
</group>
<field name="Text" required="N"/>
</message>
...
<message name="Quote" msgtype="S" msgcat="app">
<field name="QuoteReqID" required="Y"/>
<component name="Instrument" required="Y"/>
</message>
...
<component name="Instrument">
<field name="Symbol" required="Y"/>
<field name="SecurityID" required="N"/>
<field name="SecurityIDSource" required="N"/>
<field name="Product" required="N"/>
<field name="SecurityType" required="N"/>
<field name="SecuritySubType" required="N"/>
<field name="SecurityXMLLen" required="N"/>
<field name="SecurityXML" required="N"/>
<field name="SecurityXMLSchema" required="N"/>
</component>

From inside the java code, If I run the following code to see if field 55 ("Symbol") is listed as required in the R msg, it returns false:

GroupInfo gi = dictionary.getGroup("R", 146);
boolean requiredInRMsg = gi.getDataDictionary().isRequiredField("R", 55);

If I run the following code to see if field 55 ("Symbol") is listed as required in the S msg, it returns true:

GroupInfo gi = dictionary.getGroup("S", 146);
boolean requiredInRMsg = gi.getDataDictionary().isRequiredField("S", 55);

It appears that quickfix is not respecting the Required flag for a field in a component if that component is inside of a group.