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
The issue has been fixed in an update to Eikon v4.0.53 and in Eikon v4.0.54.
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.
@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?
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.
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.
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.
If you uninstall Eikon and reinstall it from http://eikon.thomsonreuters.com, you should get the latest version, which is currently 4.0.53.
@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?
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
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&$filter=(RIC%20eq%20'%2A.MX')%20and%20(ExchangeCode%20eq%20'MEX')%20and%20SearchAllCategory%20eq%20'Equities'&$skip=1500&$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
}
}
@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&$filter=(RIC%20eq%20'%2A.CN')%20and%20(ExchangeCode%20eq%20'COL')%20and%20SearchAllCategory%20eq%20'Equities'&$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.
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.
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
