CProtocol::ProcessSNMPValue in Log file when expecting CProtocol::LogHttpCommunication

219 views#processsnmpvalue
0
0 Comments

Hello everyone,

I installed HTTP driver on clients environment with 10.4.3.0-14001 version and I'm getting this messages in log:

2025/01/29 13:23:38.139|SLProtocol - 5476 - OneWeb Enterprise|20836|CProtocol::<strong>ProcessSNMPValue</strong>|CRU|-1|-> 13:23:38 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 ), returned VT_BSTR : HTTP/1.1 200 
2025/01/29 13:23:42.975|SLProtocol - 5476 - OneWeb Enterprise|20836|CProtocol::<strong>ProcessSNMPValue</strong>|CRU|-1|-> 13:23:42 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 ), returned VT_BSTR : HTTP/1.1 200 
2025/01/29 13:23:47.931|SLProtocol - 5476 - OneWeb Enterprise|20836|CProtocol::<strong>ProcessSNMPValue</strong>|CRU|-1|-> 13:23:47 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 ), returned VT_BSTR : HTTP/1.1 200

And some of the data is not processed as expected.

I'm running the same driver on internal server with 10.4.4.0-14113 version with this logs and processing works as expected:

2025/01/29 14:43:48.333|SLProtocol - 13052 - OneWeb Enterprise - copy|2608|CProtocol::<strong>LogHttpCommunication</strong>|CRU|-1|-> 14:43:48 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 OK), returned VT_BSTR : HTTP/1.1 200 OK
2025/01/29 14:43:51.572|SLProtocol - 13052 - OneWeb Enterprise - copy|2608|CProtocol::<strong>LogHttpCommunication</strong>|CRU|-1|-> 14:43:51 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 OK), returned VT_BSTR : HTTP/1.1 200 OK
2025/01/29 14:43:55.101|SLProtocol - 13052 - OneWeb Enterprise - copy|2608|CProtocol::<strong>LogHttpCommunication</strong>|CRU|-1|-> 14:43:55 - Get for getUserTerminalIdsStatusCode (status code: HTTP/1.1 200 OK), returned VT_BSTR : HTTP/1.1 200 OK

Does anyone know if there is some bug or changes between versions that I should be aware of?

Jan-Klaas Kesteloot [SLC] [DevOps Advocate] Answered question 29th January 2025

1 Answer

1
1.13K 0 Comments

If you have a redundant connection, it could be a side effect of RN 39114 where the connection type may have end up incorrectly in the log (see https://docs.dataminer.services/release-notes/General/General_Feature_Release_10.4/General_Feature_Release_10.4.4.html)

Problem with SLProtocol due to incorrect redundant connection [ID 39114]
The redundant polling feature allows SLProtocol to select another connection when the main connection goes into a timeout.
In some cases, when SLProtocol selected a connection with a type different from that of the main connection, an error could occur. From now on, when SLProtocol has to select another connection when the main connection goes into a timeout, it will only take into account connections with a type equal to that of the main connection.

Jan-Klaas Kesteloot [SLC] [DevOps Advocate] Answered question 29th January 2025
You are viewing 1 out of 1 answers, click here to view all answers.