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?
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.
When I try to hit my site, I am getting the following error:
Error Tue May 10 16:54:40 IST 2016 1462879480679
/atg/endeca/assembler/droplet/InvokeAssembler A problem occurred
assembling the content for content item /content/Web/Home Pages. The
response received was {previewModuleUrl=http://localhost:8006/ifcr,
#type=ContentSlot, atg:currentSiteProductionURL=www.local.com:7103,
canonicalLink=com.endeca.infront.cartridge.model.NavigationAction#49dded95,
ruleLimit=1, #error=com.endeca.infront.content.ContentException:
com.endeca.navigation.ENEConnectionException: Error establishing
connection to retrieve Navigation Engine request
'http://localhost:15000/graph?node=0&profiles=NoPriceRange|site&offset=0&nbins=0&merchdebug=1&irversion=640'.
Tried all: '2' addresses, but could not connect over HTTP to server:
'localhost', port: '15000' Check MDEX Logs and specified query
parameters. , contentCollection=/content/Web/Home Pages}. Servicing
the error open parameter.
When I try to access EAC Admin Console to restart MDEX Engine, it is not getting loaded. Why that might be?
Ensure your endeca servers are running. Try to access localhost:8500/cas?wsdl
Is the Dgraph port provided as 15000 in all configurations?
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 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.
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.