Closing connection to DACS Library, since we have not received a message for <180> seconds

ivan.amo

Our DACS Snkd running on our ADS, is getting flooded by the below message:

"Closing connection to DACS Library, since we have not received a message for <180> seconds"

We have identified the application causing it, which is using Opendacs API and what they are seen at their end is the below:

[lbarbul_o_10.109.34.208] DAC Connect...

[lbarbul_o_10.109.34.208] Creating new DAC context...

[lbarbul_o_10.109.34.208] Establishing DAC connection to ads1-tor.fg.rbc.com:8211

[lbarbul_o_10.109.34.208] Daemon connection state is DOWN

[lbarbul_o_10.109.34.208] Daemon connection closed

[lbarbul_o_10.109.34.208] DAC connection established: ads1-tor.fg.rbc.com:8211

[lbarbul_o_10.109.34.208] Log-in denied

2023-11-13 15:10:26.034: [T4] Looking for AA.N

2023-11-13 15:10:26.034: [T4] Symbol=AA.N found

2023-11-13 15:10:26.034: [T4] Looking for mdCache8 index 1

2023-11-13 15:10:26.038: [T4] r=AA.N,status=All is well,qt=72625577,tt=20:09:00:000,st=A,b=24.730000,a=24.750000,l=24.740000,bs=3,as=7,ls=200,vw=24.6788,pc= /C,v=238192,c=USD,sp=,m=,ex=,hp=25.020000,lp=24.330000,op=24.490000,yc=24.640000,ycd=10 NOV 2023,lt=100,name=ALCOA CORP,sr=,oi=0,sc=0,ofo=,ofc=24.640000,td=13 NOV 2023,dp=6DP,pa=,sa=,GEN_VAL1=,BCAST_REF=AA.N,PROD_PERM=6562,tt_ns=20:09:00:000:000:000,VMA10D=1014699,VMA25D=1146196,VMA50D=1163408,;

2023-11-13 15:10:26.038: r=AA.N,status=Reuters DAC denied access,qt=0,tt=,st= ,b=,a=,l=,bs=0,as=0,ls=0,vw=,pc=,v=0,c=,sp=,m=,ex=,hp=,lp=,op=,yc=,ycd=,lt=0,name=,sr=,oi=0,sc=0,ofo=,ofc=,td=,dp=,pa=,sa=,GEN_VAL1=,BCAST_REF=,PROD_PERM=,tt_ns=,VMA10D=-1246915200,VMA25D=-1246915120,VMA50D=-1246915104,;

For some odd reason, is like the dacs connections are costantly been recycled causing the above to happen. But if the DACS connection is already UP, then there are no issues:

[lbarbul_o_10.109.34.208] DAC Connect...

[lbarbul_o_10.109.34.208] Found existing DAC context...

[lbarbul_o_10.109.34.208] Connection already exist.

[lbarbul_o_10.109.34.208] Already logged-in

2023-11-13 16:24:50.124: [T12] Looking for AA.N

2023-11-13 16:24:50.124: [T12] Symbol=AA.N found

2023-11-13 16:24:50.124: [T12] Looking for mdCache8 index 1

2023-11-13 16:24:50.127: [T12] r=AA.N,status=All is well,qt=75600019,tt=21:00:00:000,st=A,b=0.000000,a=0.000000,l=24.600000,bs=290,as=170,ls=246403,vw=24.6373,pc= /C,v=572791,c=USD,sp=,m=,ex=,hp=25.020000,lp=24.330000,op=24.490000,yc=24.640000,ycd=10 NOV 2023,lt=100,name=ALCOA CORP,sr=,oi=0,sc=0,ofo=,ofc=24.600000,td=13 NOV 2023,dp=6DP,pa=,sa=,GEN_VAL1=,BCAST_REF=AA.N,PROD_PERM=6562,tt_ns=21:00:00:000:000:000,VMA10D=1014699,VMA25D=1146196,VMA50D=1163408,;

[lbarbul_o_10.109.34.208] PE allowed access by cache: 6562. Symbol: AA.N

To confirm:

• User lbarbul_o has 1 mount in DACS and the source is his desktop, so even if he spin up more sessions from the same desktop, should not be getting access denied
• User is permissioned in DACS to access RIC AA.N

Is it normal behaviour that Opendacs API sessions get constantly recycled, as our dacs snkd is not getting any message from the Opendacs API

What could be the cause of the above? Any suggestions?

Jirapongse

@ivan.amo

I think it is better to check the cause of Log-in denied because it could be the cause of this issue.

I checked the OpenDACS C++ developer guide and it doesn't mention anything about session recycling. It mentions two connection modes in OpenDACS: the 'single connect' mode and 'multi connect' mode.

It also mentions this:

In ‘multi-connect’ mode, all Refinitiv Real-Time DACS Daemons must run on the same machine as the application. Running the Refinitiv Real-Time DACS Demons on a separate machine may cause performance issues due to the overhead in network communication. 

For details on configuring multiple Refinitiv Real-Time DACS Daemon instances on a single machine, refer to the Data Access Control System Software Installation Manual.

I assume the "found existing DACS context" is the application logic.

Yes, it has the ping parameter when acquiring the AuthorizationSystem.

Please refer to the the OpenDACS developer guide in the OpenDACS package for more information.

However, for the questions regarding the settings in DACS Sink Daemon, please kindly contact the DACS support team directly via MyRefinitiv.

Otherwise, you can contact the API support team (Refintiiv Developer Connect) directly via Contact Premium support to verify this behavior in the OpenDACS API.