RSearch response never comes

igorg · February 2021

Hello,

Started a couple of hours ago, RSearch request times out. We always use 10 seconds as a timeout. This is the first time I see this kind of problem. Tried 2 minutes - no response. Trying 10 mins.

Could you check if this is a known issue?

Thanks

Alex Putkov.1 · May 2021

The issue has been fixed in an update to Eikon v4.0.53 and in Eikon v4.0.54.

Alex Putkov.1 · February 2021

I don't see any service alerts related to Search service in Eikon, and I don't reproduce the issue on my end. I just tried a simple search using a sample application utilizing RSearch library, and the result was returned within a second or two.

igorg · February 2021

@Alex Putkov. we're still experiencing the same issue. The request is not getting any response.

We have a second machine and it works without a problem.

The only difference I see is :

working machine has Eikon 4.0.52 (4.0.52055)

not working machine - 4.0.53 (4.0.53072). Was this version releases this weekend?

How can we do a rollback? This is a very critical issue because the non-working machine is our only production machine with Eikon. Could you help with this?

Alex Putkov.1 · February 2021

@igorg

I don't believe the version of Eikon is the culprit here. I've been using Eikon v4.0.53072 since October last year, and I have not experienced the issue you describe. This said, if you'd like to try rolling back the version of Eikon to see if it makes a difference, please contact Refinitiv Helpdesk. The Helpdesk can help you perform the rollback.

igorg · February 2021

if it's not the version, how can I debug this issue?

Alex Putkov.1 · February 2021

In the first instance I would suggest using Fiddler to see if the HTTP request to the Search Web service is generated by RSearch COM library, and whether the request is successful.

Alex Putkov.1 · February 2021

Btw, if you'd like to check when Eikon v4.0.53 was installed on your machine, see %PROGRAMDATA%\Thomson Reuters\Eikon Data\UpdatesHistory.xml file, which lists the full history of core Eikon updates installed on the machine. If you see that the date of Eikon update from v4.0.52 to v 4.0.53 corresponds with the time you started experiencing the problem with RSearch library, it may be worth trying to roll back the version of Eikon.

igorg · February 2021

I almost was convinced it's not related to the version

<Action>Install</Action>

<Type>Full Package</Type>

<Name>Refinitiv Eikon</Name>

<InstallMethod>Automatic Update</InstallMethod>

</Update>

igorg · February 2021

@Alex Putkov. rollback fixed the issue.

Alex Putkov.1 · February 2021

This is good news. Now we need to figure out what to do going forward. Rollback is a workaround for the immediate production issue. It cannot be a long term solution. The root cause of the problem can't be the software update in the Eikon version per se, since I'm using the updated version and don't experience the problem. The root cause must be the combination of the changes that came with Eikon v4.0.53 install and something machine or site specific, which we need to determine. I would suggest installing Eikon v4.0.53 on a test machine, reproducing the problem and start troubleshooting. As I mentioned in a previous comment, I would suggest starting with Fiddler capture of the HTTP request.

igorg · February 2021

I will do some investigation on my local machine when it gets 4.0.53 (is there a way to force an upgrade?). This week is going to be busy, but I agree we need to find the reason for that issue.

Alex Putkov.1 · February 2021

If you uninstall Eikon and reinstall it from http://eikon.thomsonreuters.com, you should get the latest version, which is currently 4.0.53.

igorg · February 2021

@Alex Putkov. My local Eikon got upgraded today I see the same behavior. Also I've got Fiddler installed. Could you tell me what should I search for? Domain names?

Alex Putkov.1 · February 2021

What you're looking for is the request to the Search service corresponding to your search, e.g. https://amers2.views.cp.thomsonreuters.com/search/ThomsonReuters/MarketsSearch/Services/2012/05/01/Search.svc/SearchEquityQuotes?query='a%2A'&$select=RIC&$filter=SearchAllCategory%20eq%20'Equities'&$top=5

igorg · February 2021

Last 4 GET requests are the queries for Mexico universe. The request and response look good for me.

The last CONNECT - not sure why it's there and what it would mean.

Request url :

https://amers2.views.cp.thomsonreuters.com/search/ThomsonReuters/MarketsSearch/Services/2012/05/01/Search.svc/SearchEquityQuotes?$select=RIC&amp;$filter=(RIC eq &#39;*.MX&#39;) and (ExchangeCode eq &#39;MEX&#39;) and SearchAllCategory eq &#39;Equities&#39;&amp;$skip=1500&amp;$top=119

Response:

{
  "d": [
    {
      "RIC": "LRN.MX"
    },
    {
      "RIC": "ANTON.MX"
    },
    {
      "RIC": "FLYN.MX"
    },
    {
      "RIC": "AGRONN.MX"
    },
    {
      "RIC": "RENN.MX"
    },
    {
      "RIC": "MASMN.MX"
    },
    {
      "RIC": "INFON.MX"
    },
    {
      "RIC": "INDVN.MX"
    },
    {
      "RIC": "JOBSN.MX"
    },
    {
      "RIC": "ATLN.MX"
    },
    {
      "RIC": "CRTON.MX"
    },
    {
      "RIC": "HCMN.MX"
    },
    {
      "RIC": "AGON.MX"
    },
    {
      "RIC": "BEZN.MX"
    },
    {
      "RIC": "SPXN.MX"
    },
    {
      "RIC": "DECN.MX"
    },
    {
      "RIC": "GRMNN.MX"
    },
    {
      "RIC": "AYN.MX"
    },
    {
      "RIC": "HN.MX"
    },
    {
      "RIC": "XRAY.MX"
    },
    {
      "RIC": "RMSN.MX"
    },
    {
      "RIC": ".PG.MX"
    },
    {
      "RIC": ".PL.MX"
    },
    {
      "RIC": "SRENN.MX"
    },
    {
      "RIC": "BOKAN.MX"
    },
    {
      "RIC": "AKEN.MX"
    },
    {
      "RIC": "TREN.MX"
    },
    {
      "RIC": "HEEN.MX"
    },
    {
      "RIC": "TITRN.MX"
    },
    {
      "RIC": "ETEGN.MX"
    },
    {
      "RIC": "RNECN.MX"
    },
    {
      "RIC": "MITSN.MX"
    },
    {
      "RIC": "MATASN.MX"
    },
    {
      "RIC": "ZOTN.MX"
    },
    {
      "RIC": "DXN.MX"
    },
    {
      "RIC": "U9EN.MX"
    },
    {
      "RIC": "2382N.MX"
    },
    {
      "RIC": "6481N.MX"
    },
    {
      "RIC": "JUVEN.MX"
    },
    {
      "RIC": "PRQRN.MX"
    },
    {
      "RIC": "788N.MX"
    },
    {
      "RIC": "REEN.MX"
    },
    {
      "RIC": "DANSKEN.MX"
    },
    {
      "RIC": "9697N.MX"
    },
    {
      "RIC": "RPRXN.MX"
    },
    {
      "RIC": "TRNEN.MX"
    },
    {
      "RIC": "9928N.MX"
    },
    {
      "RIC": "DOXN.MX"
    },
    {
      "RIC": "BDEVN.MX"
    },
    {
      "RIC": "GILN.MX"
    },
    {
      "RIC": "INFNN.MX"
    },
    {
      "RIC": "INVEBN.MX"
    },
    {
      "RIC": "ITVN.MX"
    },
    {
      "RIC": "PSONN.MX"
    },
    {
      "RIC": "LOGIN.MX"
    },
    {
      "RIC": "ORPN.MX"
    },
    {
      "RIC": "NTT1N.MX"
    },
    {
      "RIC": "EPIAN.MX"
    },
    {
      "RIC": "TL5N.MX"
    },
    {
      "RIC": "BLUN.MX"
    },
    {
      "RIC": "EXPNN.MX"
    },
    {
      "RIC": "HNSAN.MX"
    },
    {
      "RIC": "4536N.MX"
    },
    {
      "RIC": "7270N.MX"
    },
    {
      "RIC": "6301N.MX"
    },
    {
      "RIC": "ARCON.MX"
    },
    {
      "RIC": "CRNC.MX"
    },
    {
      "RIC": "DMPN.MX"
    },
    {
      "RIC": "RMVN.MX"
    },
    {
      "RIC": "BVICN.MX"
    },
    {
      "RIC": "036570N.MX"
    },
    {
      "RIC": "3626N.MX"
    },
    {
      "RIC": "ENGHN.MX"
    },
    {
      "RIC": "OLAN.MX"
    },
    {
      "RIC": "5108N.MX"
    },
    {
      "RIC": "2013N.MX"
    },
    {
      "RIC": "6098N.MX"
    },
    {
      "RIC": "AVVN.MX"
    },
    {
      "RIC": "7911N.MX"
    },
    {
      "RIC": "7912N.MX"
    },
    {
      "RIC": "7951N.MX"
    },
    {
      "RIC": "KINVBN.MX"
    },
    {
      "RIC": "WKLN.MX"
    },
    {
      "RIC": "6841N.MX"
    },
    {
      "RIC": "GEBNN.MX"
    },
    {
      "RIC": "CHRN.MX"
    },
    {
      "RIC": "4543N.MX"
    },
    {
      "RIC": "RLFN.MX"
    },
    {
      "RIC": "6701N.MX"
    },
    {
      "RIC": "8591N.MX"
    },
    {
      "RIC": "1928N.MX"
    },
    {
      "RIC": "4901N.MX"
    },
    {
      "RIC": "MNDIN.MX"
    },
    {
      "RIC": "7701N.MX"
    },
    {
      "RIC": "HLMAN.MX"
    },
    {
      "RIC": "AONN.MX"
    },
    {
      "RIC": "BKIN.MX"
    },
    {
      "RIC": "1209N.MX"
    },
    {
      "RIC": ".AV.MX"
    },
    {
      "RIC": "VNT1.MX"
    },
    {
      "RIC": "762N.MX"
    },
    {
      "RIC": ".AD.MX"
    },
    {
      "RIC": "1.SUS.MX"
    },
    {
      "RIC": "2.SUS.MX"
    },
    {
      "RIC": ".AM.MX"
    },
    {
      "RIC": ".TV.MX"
    },
    {
      "RIC": ".SUS.MX"
    },
    {
      "RIC": ".TM.MX"
    },
    {
      "RIC": ".TMUSD.MX"
    },
    {
      "RIC": "REXR.MX"
    },
    {
      "RIC": "RIOT.MX"
    },
    {
      "RIC": "ALT1.MX"
    },
    {
      "RIC": "DAON.MX"
    },
    {
      "RIC": "TXG.MX"
    },
    {
      "RIC": ".NG.MX"
    },
    {
      "RIC": ".TIC.MX"
    },
    {
      "RIC": ".STI.MX"
    },
    {
      "RIC": ".NL.MX"
    },
    {
      "RIC": "TSUN.MX"
    }
  ],
  "Paging": {
    "FirstHit": 1501,
    "LastHit": 1619,
    "Hits": 119,
    "TotalHits": 1619
  }
}

igorg · February 2021

@Alex Putkov.Ok, I could find what exactly is not working and how to reproduce.

This is related to how many requests are sent in the background to the servers. If it's more than 1, it never invokes the callback.

Example,

https://amers2.views.cp.thomsonreuters.com/search/ThomsonReuters/MarketsSearch/Services/2012/05/01/Search.svc/SearchEquityQuotes?$select=RIC&amp;$filter=(RIC eq &#39;*.CN&#39;) and (ExchangeCode eq &#39;COL&#39;) and SearchAllCategory eq &#39;Equities&#39;&amp;$top=500

This is the Colombia ticker universe query. The response has less than 500 results, so it does not have to send another request. This works without a problem.

The second example is in my previous comment: Mexico request. It sends 4 requests to the server. And the listener never gets a response.

I expect you can reproduce this.

Alex Putkov.1 · February 2021

@igorg

I was able to reproduce the problem on my end. I raised support case 09621660 on your behalf with Refinitiv Helpdesk, who will be escalating the issue to the dev team that owns RSearch library. The Helpdesk will also keep you informed on the progress.
As I was trying to reproduce the issue I made a couple of observations that may be of interest to you.

The problem is only reproduced when RSearch library is used in C++. It is not reproduced when it's used in C#.
The problem only manifests when the value of NBROWS parameter is greater than 1000. If you need an immediate workaround, you could just change the value of NBROWS from 2000 that you must be using in all your searches to 1000. Since, as you noticed in your Fiddler capture, the data is retrieved in chunks of 500 items, changing the value of NBROWS parameter from 2000 to 1000 shouldn't have any adverse effect on performance of your data retrieval.

igorg · February 2021

Thank you, @Alex Putkov.. You're a big help as always.

I've got an email from support with your comments

1. and I saw that it works in C#. We don't use C# with Eikon, so it's good to know, but doesn't help

2. It's good to know I can use 1000 as a limit in my search. The performance will be affected, but it's not that important.

Actually, I just checked my code and found that this is a configurable parameter in the program (I'm glad I did it), so I can easily change 2000 to 1000. I did a quick test and seems it works fine. However, I would need to run more tests before I can push this change in prod. So for now, we will use 4.0.52 in prod and wait for an update from the support/dev team.

Thank you again

RSearch response never comes

Best Answer

Answers

Categories