Does anyone know or have a document of how the Web Reports server caches data. In other words, how does data flow into web reports when the WR server is on the root server and remote from the root server.
We are still have a problem with WR cache becoming corrupt, and WR reporting erroneous data. Support thinks that it is a network issue.
I haven’t been able to figure out if it uses http for obtaining the actual fixlet/device results though – it could be that query is occasionally timing out on your BigFix server though
You might be able to look at the PropertyResults, FixletResults, etc to see what the date is on them?
Development claims that the problem is a network error as seen from the Web Reports log. Since our Bigfix Server is virtual with virtual storage and the database is on a remote server, all data movement is over the network. We don’t have a problem with the console, just Web Reports. It seems that Web Reports is not handling an error condition and recovering.
It should be the same way, but more complicated the more things are separated.
Does the WebReports server / service have read access to the remote BFEnterprise DB and the ability to connect to it? I’m not certain, but I thought it needed to read it directly for some things.
I think prior to 8.2 Web Reports used a direct SQL connection but after 8.2 it switched to using an authentication token (stored in dbo.data_sources in BESReporting and dbo.SERVERDATA_SESSIONS in BFEnterprise) meaning web reports gathers all data over 52311 and thus from the root server application and not directly from the database
Here is the final answer to the problem from development.
We see the following error:
CAUGHT EXCEPTION ON BACKGROUND THREAD: Error
414 – Request-URI Too
Long
…
A background server data exception occurred for datasource xxxxxx (yyyyyy)
: Error
414 –
Request-URI Too Long
This kind of error is due to requests returning back data larger than the WebReports line buffer admitted value (the default is 32768) and prevents WRs from successfully completing the refresh and it causes WRs to show old or inaccurate data.
The WRs request length can be configured and increased to avoid the error, setting the key _BESRelay_HTTPServer_MaxRequestLineLength.
So, please, on WebReports systems (stand-alone and local to the Root Server) set the Client setting _BESRelay_HTTPServer_MaxRequestLineLength =
65536.
If the problem continues, keep increasing the value until the issue is resolve. We ended up with a value of 163840 which is significantly greater than the default of 32768.