What would cause us to receive Error: 1006?

Here is a log snippet:

2020-10-06 16:20:01.703054 3FE6D720 INFO App.cpp:234: application:"reuterClosing" on domain:"prod" started on host:"hallgat608" with pid:136291 as user:"evavol" cwd:"/data1/eva/log" config_dir:"/opt/eva/etc" config_file:"reuterClosing.cfg"

2020-10-06 16:20:01.871682 3FE6D720 INFO IceEnv.cpp:73: Ice print: IceLBM plugin compiled on Jun 16 2016 at 11:48:24, non-blocking mode disabled, lbm queue disabled/0, using UMS 6.9.0.1 [64-bit] Build: Jan 7 2016, 16:56:31 ( DEBUG license LBT-RM LBT-RU LBT-IPC LBT-SMX LBT-RDMA ) WC[PCRE 7.4 2007-09-21, regex, appcb] HRT[RDTSC,clock=2593MHz]

2020-10-06 16:20:01.871887 3FE6D720 INFO IceEnv.cpp:146: IceEnv::init(): set default Ice locator to:IceGrid/Locator -t:tcp -h hallgat608 -p 4060

2020-10-06 16:20:01.871986 3FE6D720 INFO App.cpp:260: enabled host agent as HostAgent -d:udp -h 127.0.0.1 -p 62000

2020-10-06 16:20:01.872400 3FE6D720 INFO App.cpp:283: configuring subsystem evacore::Timer

2020-10-06 16:20:01.872410 3FE6D720 INFO App.cpp:283: configuring subsystem evareuter::Reuter

2020-10-06 16:20:01.872448 3FE6D720 INFO Reuter.cpp:44: reuter configured with host:10.39.50.36 port:14002 login:evany service:IDN_SELECTFEED

2020-10-06 16:20:01.880259 3FE6D720 INFO Reuter.cpp:83: UPA initialized succesfully

2020-10-06 16:20:01.887928 3FE6D720 ERRR Reuter.cpp:65: rsslConnect() failed - <Impl/ripcsrvr.c:5983> Error: 1006 This connection has received a negative acknowledgement response from the server.

2020-10-06 16:20:01.888068 3FE6D720 ERRR App.cpp:300: App::run(): exception in appRun() rsslConnect() failed: <Impl/ripcsrvr.c:5983> Error: 1006 This connection has received a negative acknowledgement response from the server.

2020-10-06 16:20:01.888305 3FE6D720 INFO Reuter.cpp:93: UPA uninitialized successfully

Find more posts tagged with

elektron

elektron-sdk

elektron-transport-api

eta-api

rrt

error-1006

Accepted answers

moragodkrit.chumsri_1

@sue.jimenezday

From the logs, it's quite hard to pinpoint a root cause. The Error: 1006 seems to be the case that the server-side is busy or overloaded, so it can not accept a new connection from your UPA app.

If you still found the issue, I recommend you test the issue with one of the RSSL Consumers apps from the API package. Or using the rmdstestclient test tool to connecting to the server in the same period. It should be able to help you verify if the server can accept a new connection or not.

You may consider upgrading the application to use ETA API (the new name of UPA). It may help avoid issues that are already fixed in the latest version. You can download Refinitiv Realtime SDK from

https://developers.refinitiv.com/en/api-catalog/elektron/elektron-sdk-cc

Or get the package from GitHub.

https://github.com/Refinitiv/Real-Time-SDK

All comments

moragodkrit.chumsri_1

@sue.jimenezday

From the logs, it's quite hard to pinpoint a root cause. The Error: 1006 seems to be the case that the server-side is busy or overloaded, so it can not accept a new connection from your UPA app.

You may consider upgrading the application to use ETA API (the new name of UPA). It may help avoid issues that are already fixed in the latest version. You can download Refinitiv Realtime SDK from

https://developers.refinitiv.com/en/api-catalog/elektron/elektron-sdk-cc

Or get the package from GitHub.

https://github.com/Refinitiv/Real-Time-SDK

julien.dominici

Hi @moragodkrit.chumsri_1 ,

We were ready to open a ticket to the RTDS support but I found this topic first. We are encountering the same issue regularly in our company since a few months (probably after some upgrade to RTDS3.6 and earlier versions).

We are receiving that using recent testclient (in RSSL mode) and WS (json2) protocols (via market_price.py -based examples for instance) :

Any idea why this happens by any chance ? From a client perspective, it looks like it happens when a socket was recently closed and we try to reopen one in the few seconds following the close (but it happened at first use to a colleague of mine as well, so probably not a good path to follow..).

We have system metrics (down to CPU by core / second) for these servers and we are not observing resource issues.

Thanks for your help.

Julien

EXPLORE OUR SITES