quickfix sends logout in response to logon - quickfix

I have a FIX server and client implemented using quickfix v1.14.3. When the client sends a logon request, the server immediately sends a logout message.There is nothing in the logs to indicate why it is so. The SenderCompID and TargetCompID both match between the server and client. I have removed the previous sessions states on both the server and client. Is there any way to find why the server is sending the logout message?
Here is the server configuration
enter code here
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=60
FileStorePath=/temp/quickfix/mktdata
SocketAcceptPort=32323
SocketReuseAddress=Y
SenderCompID=Server1
[SESSION]
BeginString=FIX.4.4
TargetCompID=INCA
StartTime=00:30:00
EndTime=21:30:00
ReconnectInterval=30
HeartBtInt=30
SocketConnectPort=6523
SocketConnectHost=0.0.0.0
DataDictionary=/opt/quickfix/spec/FIX44.xml
Here is the client configuration
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
ReconnectInterval=1
FileStorePath=/temp/quickfix/order
StartTime=00:00:00
EndTime=00:00:00
SocketConnectHost=localhost
UseDataDictionary=Y
SenderCompID=INCA
DataDictionary=/opt/quickfix/spec/FIX44.xml
[SESSION]
BeginString=FIX.4.4
TargetCompID=Server1
SocketConnectPort=32323

Answering from the comments, it's a start time/end time issue.
I think it may be due to StartTime/EndTime. My problems occurred in the evening when the time is past the EndTime(UTC).– RamJul 27 at 13:13

Your problem looks like problem of not matching StartTime and EndTime settings of the Acceptor and the Initiator. However, if you like find out more, implement IApplicationExt instead of IApplication, and in the section where you override the IApplication interface functions, override also FromEarlyIntercept and test msg for "is Logout":
public void FromEarlyIntercept(Message msg, SessionID sessionID)
{
string msgText = msg.GetField(Tags.Text);
if (msg is Logout)
{
Console.WriteLine(" Connection of Session {0} forced to logout, because: {1}", sessionID, msgText);
}
There in the respective Logout tags content you may find the explanation for your LogOut. I hope this helps.

Related

QuickFIX/J cannot logon after TestRequest

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.

How to work FIX session on VPN when we connect the apllication with FIX server

how the FIX Session works on VPN Tunnel and how many sessions should be created when we send the request on FIX.
my problem is that many session have created on VPN in one day i.e 30 000 session created so my FIX protocol does not respond properly,
how can I create only one session at a time?
This property file I used for FIX connectivity.
FileStorePath=data
ConnectionType=initiator
SenderCompID=XXX
TargetCompID=PSE
#SocketConnectHost=********
StartTime=09:30:00
Asia/Manila
EndTime=16:30:01
Asia/Manila
HeartBtInt=30
ReconnectInterval=50000
ResetOnLogon=Y
ResetOnLogout=Y
ResetOnDisconnect=Y
Username=*******
Password=*****
BeginString=FIXT.1.1
DefaultApplVerID=9
SocketConnectPort=xx
Session.lookupSession(sessionId).logout("user requested");
This function is get used for logging out.But gives the following error:
FIXIT.1.1:135->PSE, event> (Initiated logout response) FIXIT.1.1:135->PSE, event> (Disconnecting:Received logout response)
This are the logs that are shown on my console.
In the above the logout is done successfully and the session is removed from my side.But problem is that i didn't understand session is get destroyed or not? And if the session is destroyed then why VPN server is showing the connection is not destroyed? Is the problem from my side or there is a network issue?

QuickFIX Initiator sends logout request and does not reconnect

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.

Jasig CAS - 404 code after successful service ticket validation

We are currently trying to deploy CAS 4.0.1 on a JBoss EAP 6.3.0 server.
The login webflow was customised in order to redirect to a specific login form depending on the service calling CAS for authentication. Depending on these forms, we use specific authentication handlers, and a specific Credential model. Besides that, the configuration is rather standard.
At the moment, we are experiencing the following issue: when a user attempts to access a service secured by CAS, he is correctly redirected to the portal, and the expected login view is rendered ; upon successful login, the Service Ticket is delivered to the authentication filter on the service side (standard j_spring_cas_security_check), which then validates it successfully against CAS' ticket registry. We see in the logs that CAS is rendering the cas2ServiceSuccessView ; however, instead of delivering the expected XML response, the user is redirected to the login form.
We then confirmed that we were in fact getting a 404 error after the cas2ServiceSuccessView... Any idea what could trigger such behaviour/what we could have done wrong ?
Note that we are getting the same error regardless of how we call CAS for the ST validation: whether it is manually through /serviceValidate?ticket=ST-YYY&service=XXX, or via the /j_spring_cas_security_check on the service side...
Edit: we have the same behaviour running CAS on Tomcat 7.
Thanks in advance.
Below the debug logs that we are getting:
08:54:10,806 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Last-Modified value for [/cas/serviceValidate] is: -1
08:54:10,809 INFO [org.perf4j.TimingLogger] (http-/0.0.0.0:8080-7) start[1433314450807] time[2] tag[VALIDATE_SERVICE_TICKET]
08:54:10,810 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] (http-/0.0.0.0:8080-7) Audit trail record BEGIN
=============================================================
WHO: audit:unknown
WHAT: ST-3-uecoOwdbdIn4bc2WvXfe-cas-test
ACTION: SERVICE_TICKET_VALIDATED
APPLICATION: CAS
WHEN: Wed Jun 03 08:54:10 CEST 2015
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.0.1
=============================================================
08:54:10,810 DEBUG [org.springframework.validation.DataBinder] (http-/0.0.0.0:8080-7) DataBinder requires binding of required fields [renew]
08:54:10,811 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Rendering view [org.springframework.web.servlet.view.InternalResourceView: name 'cas2ServiceSuccessView'; URL [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp]] in DispatcherServlet with name 'cas'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Added model object 'assertion' of type [org.jasig.cas.validation.ImmutableAssertion] to request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Removed model object 'pgtIou' from request in view with name 'cas2ServiceSuccessView'
08:54:10,811 DEBUG [org.springframework.web.servlet.view.InternalResourceView] (http-/0.0.0.0:8080-7) Forwarding to resource [/WEB-INF/view/jsp/cas2ServiceSuccessView.jsp] in InternalResourceView 'cas2ServiceSuccessView'
08:54:10,812 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) Successfully completed request
08:54:10,814 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-/0.0.0.0:8080-7) DispatcherServlet with name 'cas' processing GET request for [/cas/login]
08:54:10,814 DEBUG [org.springframework.webflow.mvc.servlet.FlowHandlerMapping] (http-/0.0.0.0:8080-7) Mapping request with URI '/cas/login' to flow with id 'login'
In SpringSecurity 4.x, CasAuthenticationFilter's defaultFilterProcessesUrl path is changed.
So Change '/j_spring_cas_security_check' to '/login/cas' in Configuration.
... and of course, the cause was rather silly: somehow (I have to look at our merge/git history), the viewResolver bean defined in cas-servlet.xml did not have a basenames property set.

SASL authorization failing while connecting to XMPP server

I am trying to connect to gmail using SMACK API through XMPP server. but getting the
error : SASL authentication failed using mechanism PLAIN
you can check a glimpse of code. I got it from net only
ConnectionConfiguration connConfig = new ConnectionConfiguration("talk.google.com", 5222, "gmail.com");
connection = new XMPPConnection(connConfig);
connection.connect();
SASLAuthentication.supportSASLMechanism("PLAIN", 0);
I checked in the smack debug window. it says in XML :
< invalid-authzid />
I am already having account on gmail and my gtalk is also running.
You need to set the authentication before you connect viz
SASLAuthentication.supportSASLMechanism("PLAIN", 0);
must appear before connection.connect().
See my blog.
ConnectionConfiguration cc = new ConnectionConfiguration(
"vietnam.agilemobile.com", 5222, vietnam.agilemobile.com");
XMPPConnection connection = new XMPPConnection(cc);
try {
SASLAuthentication.supportSASLMechanism("PLAIN", 0);
connection.connect();
Log.e("LOGIN", "" + 111);
// You have to put this code before you login
Log.e("LOGIN", "" + 222);
// You have to specify your gmail addres WITH #gmail.com at the end
connection.login("nemodo", "123456", "resource");
Log.e("LOGIN", "" + 333);
// See if you are authenticated
System.out.println(connection.isAuthenticated());
} catch (XMPPException e1) {
e1.printStackTrace();
}
I also get this mistake, but i can not work.
For anyone looking for possible solutions to this many years after this was originally asked and answered, I recently was able to get past this authentication error by explicitly setting the authzid value on the XMPPTCPConnectionConfiguration.
I was running into an issue where my connection configuration worked fine for some client XMPP servers, but not for others, even though they were all using SASL PLAIN authentication. After some troubleshooting, I learned that the ones that were failing were expecting an authzid value. After adjusting my code to set this, it works in both the environments that were working before, as well as the environments that were failing.
Here is how I am building my connection configuration:
XMPPTCPConnectionConfiguration.builder()
.setHost(XMPP_DOMAIN)
.setXmppDomain(XMPP_DOMAIN)
.setPort(XMPP_PORT)
.setCompressionEnabled(true) // optional, not all servers will support this
.setUsernameAndPassword(XMPP_USER, XMPP_PASSWORD)
.setResource(XMPP_RESOURCE)
.setAuthzid(JidCreate.entityBareFrom(String.format("%s#%s", XMPP_USER, XMPP_DOMAIN))) // <-- this was the change I needed
.build();
Specifically I needed to add this line:
.setAuthzid(JidCreate.entityBareFrom(String.format("%s#%s", XMPP_USER, XMPP_DOMAIN)))