Has anyone ever seen an issue where calling the REST API with the “/query=relevance=blah” returns stale results? I’ve bounced the Root Server service and even restarted the Root server, but the call still returns old values (specifdally, i’m trying to return all fixlets with a name that contain “test”. WhenI login to the console as the same user as the one making the rest call, I can see the “test” task in the Console, but I get no results in the Rest API results.
If you try to use the REST API “/query” without a Web Reports server reachable from the root, then you get an error message saying no Web Reports server could be contacted or something like that.
All REST API calls go to the root, but at least in the case of /query it seems to get passed on to Web Reports. All other REST calls get processed by the root as far as I know.
I was getting results, but like I said, they were stale, Even a query like “number of bes computers” was returning an incorrect number that didn’t agree with the console.
Even now, my sample task shows up in WebReports > Explore Data > Content, but not in a crafted query "(name of it) of bes fixlets whose (name of it as lowercase contains “test”)…
Do you have multiple Web Reports servers? Is there one that is not being used anymore, but still up?
I think the Root contacts a particular Web Reports server based upon settings on the root server. You can have multiple WebReports servers, but one in particular is used for REST API /query
I rebooted the root with no change. No recent updates applied that wasn’t applied on our other IEM deployment root servers. They were off by a couple hundred (which was because I deleted a bunch of inactive clients in order to get different computer counts). I edited my previous post to show the different results.
Yes, i’ll have to open a PMR I suppose. Will reply back with their findings.
Well I got no progress on my issue, the only thing that seemed to correct anything for us was to reboot the WR server, so we just have an open action to reboot the server nightly. Not ideal.
Our next step is to try to install WR on a separate server and see if the co-location was causing some sort of lock. Will report back once we get some results from that.