I use QuickFixN to connect to 2 liquidity providers.
One is connecting and working fine. The other isn't showing any error message, seems to be connecting, but Logon isn't succeeding.
In the messages log: I am sending the Logon request (message type 'A'), and receiving back another message type A, but then nothing happens. 30secs later this happens again. It has many repeats looking like this:
20131118-20:11:32.422 : 8=FIX.4.49=11535=A34=149=XXXX50=XXXX52=20131118-20:11:32.40856=XXXX57=XXXX98=0108=30141=Y10=152
20131118-20:11:32.795 : 8=FIX.4.49=11535=A34=149=XXXX50=XXXX52=20131118-20:11:32.61956=XXXX57=XXXX98=0108=30141=Y10=156
....same again every 30secs....
the event log looks like this:
20131118-20:11:32.023 : Connecting to AA.AAA.AAA.AAA on port BBBB
20131118-20:11:32.395 : Connection succeeded
20131118-20:11:32.408 : Session reset: ResetOnLogon
20131118-20:11:32.422 : Session reset: ResetSeqNumFlag
20131118-20:11:32.422 : Initiated logon request
20131118-20:11:32.796 : Message 1 Rejected: 9
20131118-20:11:32.798 : Verify failed: Tried to send a reject while not logged on
20131118-20:11:32.798 : Session FIX.4.4:XXXX->YYYY disconnecting: Verify failed: Tried to send a reject while not logged on
Within my application, on the QuickFix.Application interface, OnCreate is being called for this session, and so is OnLogout, but OnLogon is not. Neither FromAdmin or FromApp receive any messages from this session.
What could I be doing wrong?
The "Message 1 Rejected: 9" phrase is saying the message with sequence number 1 (the Logon message) was rejected for reason 9. The reason is a FIX Session Reject Reason and 9 indicates a CompID problem. Double-check your sender and target CompIDs in the message to be sure they are correct for your counterparty. Note that your side of the session is rejecting their login so it could be an issue with configuration of your session. The "Verify failed" message is logged because QuickFIX/n is apparently trying to send a reject message before the session is logged in.
Related
Summary
I have an initiator with quickfix 50sp2 on a FIXT1.1 transport layer. As I see in the log messages, there is no connection problem. Heartbeats are reaching to each side. But randomly my initiator sends test request to acceptor even if it gets heartbeat as expected. Acceptor response to test request with a heartbeat including TestReqID. After that my initiator sends logon messages. Acceptor sends logon too and then loop starts. If I restart the whole application, initiator can logon and gets heartbeat.
Expectation
After acceptor sends heartbeat with specific TestReqID, I'm expecting that getting and sending heartbeats. Instead, initiator is sending logon message and not loggin' to the acceptor.
Event.Log
20220719-01:01:05: Initiated logon request
20220719-01:01:05: Setting DefaultApplVerID (1137=9) from Logon
20220719-01:01:05: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
20220719-01:01:05: Received logon
20220719-09:00:17: Sent test request TEST
20220719-09:00:29: Disconnecting: Timed out waiting for heartbeat
20220719-09:00:33: Pending connection not established after 4001 ms.
20220719-09:00:36: Pending connection not established after 7002 ms.
20220719-09:00:36: MINA session created: local=/hosti:porti, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/hosta:porta
20220719-09:00:37: Initiated logon request
20220719-09:00:37: Setting DefaultApplVerID (1137=9) from Logon
20220719-09:00:48: Disconnecting: Timed out waiting for logon response
20220719-09:01:29: MINA session created: local=/hosti:porti, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/hosta:porta
20220719-09:01:30: Initiated logon request
20220719-09:01:30: Setting DefaultApplVerID (1137=9) from Logon
20220719-09:01:40: Disconnecting: Timed out waiting for logon response
20220719-09:02:29: MINA session created: local=/hosti:porti, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/hosta:porta
Messages.log
8=FIXT.1.19=00005235=049=ACCEPTOR56=INITIATOR34=98952=20220719-08:58:46.53810=079
8=FIXT.1.19=6135=034=95749=INITIATOR50=SNDRSUBID52=20220719-08:59:05.15856=ACCEPTOR10=107
8=FIXT.1.19=00041535=849=ACCEPTOR56=INITIATOR34=99052=20220719-08:59:16.22737=ORDID11=NONE453=3448=GL-P447=D452=28448=INITIATOR447=D452=1448=KL305447=D452=12880=TRDMTCHID17=1234567150=F39=221100=1.000000021101=1.000000055=EURUSD48=17107122=M54=138=1.000000040=244=1.000000059=0528=P32=1.000000031=1.0000000151=014=1.00000006=060=20220719-08:59:16.226797=Y10=090
8=FIXT.1.19=00052135=AE49=ACCEPTOR56=INITIATOR34=99152=20220719-08:59:16.23220008=1.000000021100=1.000000021102=123420017=020018=1.0000000730=1.0000000571=90063491003=123456:123A487=0856=0829=1001855=1880=TRDMTCHID570=N55=EURUSD48=17107122=M38=1.000000032=1.000000031=1.000000075=20220719715=2022071960=20220719-08:59:16.000573=0552=154=137=ORDID453=3448=INITIATOR447=D452=1448=GL-P447=D452=28448=KL305447=D452=12528=P1057=N797=Y1703=11704=1000000010=054
8=FIXT.1.19=6135=034=95849=INITIATOR50=SNDRSUBID52=20220719-08:59:35.15856=ACCEPTOR10=111
8=FIXT.1.19=00005235=049=ACCEPTOR56=INITIATOR34=99252=20220719-08:59:46.59010=072
8=FIXT.1.19=6135=034=95949=INITIATOR50=SNDRSUBID52=20220719-09:00:05.15856=ACCEPTOR10=096
8=FIXT.1.19=00005235=049=ACCEPTOR56=INITIATOR34=99352=20220719-09:00:16.65910=063
8=FIXT.1.19=7035=134=96049=INITIATOR50=SNDRSUBID52=20220719-09:00:17.15856=ACCEPTOR112=TEST10=110
8=FIXT.1.19=00006135=049=ACCEPTOR56=INITIATOR34=99452=20220719-09:00:17.163112=TEST10=073
8=FIXT.1.19=12435=A34=149=INITIATOR50=SNDRSUBID52=20220719-09:00:37.15956=ACCEPTOR98=0108=30141=Y553=USERNAME554=PASSWORD1137=91409=010=083
8=FIXT.1.19=00009135=A49=ACCEPTOR56=INITIATOR34=152=20220719-09:00:37.17820002=2698=0108=30141=Y1409=01137=910=061
8=FIXT.1.19=12435=A34=149=INITIATOR50=SNDRSUBID52=20220719-09:01:30.15856=ACCEPTOR98=0108=30141=Y553=USERNAME554=PASSWORD1137=91409=010=076
8=FIXT.1.19=00009135=A49=ACCEPTOR56=INITIATOR34=152=20220719-09:01:30.17520002=2698=0108=30141=Y1409=01137=910=052
8=FIXT.1.19=12435=A34=149=INITIATOR50=SNDRSUBID52=20220719-09:02:30.15856=ACCEPTOR98=0108=30141=Y553=USERNAME554=PASSWORD1137=91409=010=077
8=FIXT.1.19=00009135=A49=ACCEPTOR56=INITIATOR34=152=20220719-09:02:30.17520002=2698=0108=30141=Y1409=01137=910=053
What I've Tried
Added TestRequestDelayMultiplier = 1 to the session properties.
Found this topic it looks relative but there is no answer.
session.properties
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=60
ResetOnLogon=Y
FileLogPath=logs/Client_Logs
SenderCompID=INITIATOR
SenderSubID=SNDRSUBID
ValidateIncomingMessage=N
TestRequestDelayMultiplier=1
[SESSION]
BeginString=FIXT.1.1
TargetCompID=ACCEPTOR
StartDay=sunday
EndDay=friday
StartTime=21:35:00
EndTime=21:30:00
HeartBtInt=30
CheckLatency=N
SocketConnectPort=port
SocketConnectHost=host
DefaultApplVerID=9
UseDataDictionary=Y
DataDictionary=config/cptyFIX50sp2.xml
FileStorePath=logs/Client_Seq_Store
TransportDataDictionary=config/FIXT11.xml
AppDataDictionary=config/cptyFIX50sp2.xml
I think the problem is that the counterparty does not reply to your TestRequest message with the full SessionID. Normally this is a combination of SenderCompID and TargetCompID.
However, in your settings you specify SenderSubID=SNDRSUBID but the counterparty does not include the SNDRSUBID on their messages. In my opinion they should send it back to you as TargetSubID.
Could you try to remove the SenderSubID from your settings and see if that works?
If you need the SenderSubID on some of your messages then please only set it programatically on selected messages and not for the complete session.
We are using QuickFixN for sending orders to exchange and receiving execution reports.
If the VPN for exchange is disconnected during the day, the QuickFixN could not reconnect until the next day, despite having the ResetOnLogon and ResetOnDisconnected settings set to N.
We do not understand the reason: the sequence, or something else?
0171217-12:15:39.122 : Created session
20171217-12:15:39.129 : Connecting to 172.16.105.151 on port 10060
20171217-12:15:39.399 : Connection succeeded
20171217-12:15:39.423 : Initiated logon request
20171217-12:15:39.680 : Session FIX.4.2:NOOR->MBS disconnecting: System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
at QuickFix.SocketInitiatorThread.ReadSome(Byte[] buffer, Int32 timeoutMilliseconds)
at QuickFix.SocketInitiatorThread.Read()
20171217-12:15:41.140 : Connecting to 172.16.105.151 on port 10060
20171217-12:15:41.398 : Connection succeeded
20171217-12:15:41.399 : Initiated logon request
20171217-12:15:41.654 : Session FIX.4.2:NOOR->MBS disconnecting: System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
at QuickFix.SocketInitiatorThread.ReadSome(Byte[] buffer, Int32 timeoutMilliseconds)
at QuickFix.SocketInitiatorThread.Read()
Requests to exchange
20171217-12:15:39.423 : 8=FIX.4.2|9=65|35=A|34=7304|49=NOOR|52=20171217-12:15:39.415|56=MBS|98=0|108=30|10=192|
20171217-12:15:41.398 : 8=FIX.4.2|9=65|35=A|34=7305|49=NOOR|52=20171217-12:15:41.398|56=MBS|98=0|108=30|10=196|
20171217-12:15:43.397 : 8=FIX.4.2|9=65|35=A|34=7306|49=NOOR|52=20171217-12:15:43.397|56=MBS|98=0|108=30|10=198|
20171217-12:15:45.398 : 8=FIX.4.2|9=65|35=A|34=7307|49=NOOR|52=20171217-12:15:45.398|56=MBS|98=0|108=30|10=202|
20171217-12:15:47.399 : 8=FIX.4.2|9=65|35=A|34=7308|49=NOOR|52=20171217-12:15:47.399|56=MBS|98=0|108=30|10=206|
20171217-12:15:49.400 : 8=FIX.4.2|9=65|35=A|34=7309|49=NOOR|52=20171217-12:15:49.400|56=MBS|98=0|108=30|10=192|
Well the error means your counterparty is likely sending a TCP reset packet to you. So it looks like you're making the connection, but then failing the logon attempt and the result is the reset packet.
Is your username / password correct?
First of All , thank you #rupweb for your replay and interest to give a hand .Second , there were two sources of this problem : 1 - before disconnecting the client system -that connects to remote party - it must logout. 2 - the executable file of client system must run from the same physical location each time.Because, the Fix generates file to keep the sequence on my device to start another handshaking and connecting next time.
I am trying to figure out what FIX resend (35=2) do , so I have my own FIX engine
to send the following message to FIX acceptor :
Notice : The following messages has 0x01 replaced by '|' already !!
Step1 :
logon : (8=FIX.4.2|9=86|35=A|34=12|49=YADTS|52=20160316-11:22:43.000|56=DS68AA|96=13575522|98=0|108=30|10=162|)
Step2:
receive : (8=FIX.4.2|9=00073|35=A|49=DS68AA|56=YADTS|34=9|52=20160316-03:22:48.744|108=30|98=0|10=200|)
logon looke like works !!!
Step3:
client resend request to accptor :
(8=FIX.4.2|9=72|35=2|34=13|49=YADTS|52=20160316-11:22:48.000|56=DS68AA|7=2|16=0|10=166|)
Step4:
client send heartbeat to accetor :
(8=FIX.4.2|9=62|35=0|34=14|49=YADTS|52=20160316-11:23:12.000|56=DS68AA|10=032|)
Step5:
accptor send to client :
(8=FIX.4.2|9=00072|35=2|49=DS68AA|56=YADTS|34=10|52=20160316-03:23:17.677|7=13|16=0|10=119|)
Step6:
acceptor send to client :
(8=FIX.4.2|9=00128|35=5|49=DS68AA|56=YADTS|34=11|52=20160316-03:23:47.676|58=A timeout occurred while waiting for a resend request response|10=232|)
What I am bothered is , in Step5 , I am asking resend request with begin_seqno=2(7=2) to the last seqno (16=0) in Step3 .
But , Why in Step5 ,the accptor send resend request to client ?
Should not acceptor should resend message which seqno between 2 to the last ?!
I have no idea Why acceptor send the 35=2 message to client for ,
any commets are great appreciated !!
I am using a FIX session to get TradeCaptureReports. When connection is established, I get responses to TradeCaptureRequest. After logon, heartbeat messages are sending and receiving.
But then FIX initiator sends logout request and does not reconnect, even if ReconnectInterval is set to 1 in session config.
event log:
08:23:56 : Initiated logon request
08:23:56 : Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1
08:23:56 : Received logon response
08:25:42 : Initiated logout request
I need to keep QuickFIX connection alive and keep sending scheduled TradeCaptureRequests. Do you have any idea, what can cause this logout?
Message log after logon request and response:
8=FIX.4.4|9=56|35=0|34=3|49=**|52=20151203-08:24:56.310|56=***|10=169|
8=FIX.4.4|9=56|35=0|49=***|56=**|34=3|52=20151203-08:24:55.771|10=179|
8=FIX.4.4|9=56|35=0|34=4|49=**|52=20151203-08:25:26.313|56=***|10=171|
8=FIX.4.4|9=56|35=0|49=***|56=**|34=4|52=20151203-08:25:25.772|10=179|
8=FIX.4.4|9=56|35=5|34=5|49=**|52=20151203-08:25:42.338|56=***|10=182|
Session Config:
HeartBtInt=30
ReconnectInterval=1
ResetOnLogon=Y
StartTime=00:00:00
EndTime=00:00:00
I won't be able to test this until Monday, but I don't think you can set your StartTime to be equal to your EndTime. That would explain why it's disconnecting, because it doesn't think it's time for the session to be up.
QuickFix does support week long sessions, if you use the StartDay and EndDay parameters, in conjunction with the StartTime and EndTime ones.
I am trying to set up an alert for a channel to send emails. The problem is that when a channel produces an alert, on having tried to send e-mail the mistake takes place: "Connection reset". The server of mail is external to the company.
To prove the sending of message in Mirth, I have defined a channel that when it receives a hl7 message sends a mail to a certain direction with the following code javascript:
var smtpConn = SMTPConnectionFactory.createSMTPConnection();
smtpConn.send('example1#mailserver.es', '', 'example2#mailserver.es', 'subject', 'body');
logger.info('mensaje enviado');
Producing the same mistake:
Caused by: javax.mail.MessagingException: Exception reading response;
nested exception is:
java.net.SocketException: Connection reset
at com.sun.mail.smtp.SMTPTransport.readServerResponse(SMTPTransport.java:1925)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1684)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:525)
at javax.mail.Service.connect(Service.java:313)
at javax.mail.Service.connect(Service.java:172)
at javax.mail.Service.connect(Service.java:121)
at javax.mail.Transport.send0(Transport.java:190)
at javax.mail.Transport.send(Transport.java:120)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1232)
The Setting configuration is:
SMTP Host: ipsmtphostserver, Port: 465,SendTimeOut:2000,DefaultFromAccess:anyemail#mail.com, SecureConnection:I have tried with both TTL and SSL,RequiereAuthentication: Yes.
I have thought that the problem was firewall or antivirus, but I have deactivated a moment them and it follows the problem.