10-21-2020 10:29 AM
Hi,
I m trying to find the root source for some of my computers not sending data to the test monitor. I'll open another post when i find it or get stuck in my reaserch. I checked the windows journal on one of them and found this error listed a lot.
Any thought what may cause this.
Thanks for the help
10-21-2020 10:32 AM
We're also having the following problem:
10-22-2020 05:19 AM
for the hearbeat problems we can have the following Windows events. Nothing can happened for a long time and suddendly it's like that:
for the first message written by sklod, we saw that we had a message with a timestamp from July that was still send in october! and as far as we had a look, it was send each minute!
Apparently the new client 2020R3 (previously 19.6) solved this problem
We still have sometimes the message but with a recent timestamp and it disappears after (should be a "normal" error). Now we have a lot of heartbeat messages
10-22-2020 12:36 PM
Hi sklod,
There was a particular issue a few releases back where the forwarding service would get stuck processing an old record, and the data produced after would not appear. Looking at that error message, it appears to be that same issue. This case has been improved a lot in recent releases.
Do you happen to know what version of SystemLink Client (on the target) and SystemLink Test Module/SystemLink Server (serverside) are being used?
10-22-2020 12:45 PM
Hi HVW,
As I mentioned in the reply to sklod above, the issue relating to the Test Monitor API has indeed been improved in client versions after 19.6.
However, the message that you still see leftover is instead related to the Asset module. It's trying to publish Asset Utilization data, but it is unable to see the APM service. This isn't really an error case for the forwarding service, as it will simply retry until the APM service becomes available, but we can definitely reduce the log spam when this happens.
Do you happen to know if the Asset Management module is installed on the server? If so, do you happen to know which version of SystemLink Client, Asset Module, and SystemLink Server are being used?
Thanks,
Alex
10-23-2020 02:47 AM
Hi Alex,
First many thanks for your answers, it's giving us a lot of understanding!
I am working with sklod so I will answer for both:
Before we were on the following configuration:
Client 19.6 - Server 19.6
and we directly went to Client 20R3 - Server 20R3
As you explain, it appears that the switch of version helped us to correct the first error message we were having. Clearly the client was getting stuck with an old record. We can tell you that at first sight it's no more the case.
For the second part yes we have the asset manager module installed but we do not have the licence for it:
and for what you say well, we saw that sometimes after a server reboot than not all the services were started on the server. We don't know if it concerned the APM service but we can have a look next week on that. Since we had this problem of services two times, they might be a correlation but we have to check.
Could it also be linked to the teststand configuration for SL (Enable asset utilization tracking)?
11-03-2020 11:56 AM
Glad to hear that the test results made it through.
The errors are not necessarily linked to the Asset Utilization Tracking in TestStand. All the Asset Utilization information from all sources goes through that forwarding service. Even if Asset Utilization Tracking is disabled in TestStand, there could be something else on the system publishing utilization data.
Also, it won't stop giving the warning until it manages to successfully publish all the leftover utilization data on the system. Even if whatever is creating the data is stopped, the existing data will still be there on the target, waiting to be synchronized with the server.
nisystemlinkforwarding.exe will continually log this error as long as it has APM data that it wants to forward, but can't for some reason. According to the error message above it looks like you're getting a 503 from the NI Web Server when contacting APM, which seems to indicate that the APM service is not running or not installed. If there was some recent downtime, then this might be correlated. Still, the APM service being down is not necessarily an error condition for the forwarding service, since it continually retries every minute or so (hence the error message reappearing every minute).