Im trying to implement a LogHandler to enable logging to a SEQ logging server, see http://getseq.net . I have used the code for the PaperTrail Log handler as a template.
I have tried, and managed to send the data to the server in the main loop using HttpClient version 0.0.5, but when try to do the same within the log method the HTTP client hangs receiving the response from the SEQ server.
I have added some extra logging to the HTTP client to see whats happening. I have also added a SerialLogHandler to see the system messages.,
The response is 262 characters long and while iterating this loop
while (client.available()) {
#ifdef LOGGING
Serial.print("Reading character #");
Serial.print(client.available());
#endif
char c = client.read();
#ifdef LOGGING
Serial.print(", Character: ");
Serial.print(c);
Serial.print(" , ");
Serial.print(client.available());
Serial.println(" , Characters left: ");
#endif
lastRead = millis();
if (c == -1) {
error = true;
#ifdef LOGGING
Serial.println("HttpClient>\tError: No data available.");
#endif
break;
}
// Check that received character fits in buffer before storing.
if (bufferPosition < sizeof(buffer)-1) {
#ifdef LOGGING
Serial.print("HttpClient>\tAdding character# ");
Serial.print(bufferPosition);
Serial.println(" to Buffer.");
#endif
buffer[bufferPosition] = c;
} else if ((bufferPosition == sizeof(buffer)-1)) {
#ifdef LOGGING
Serial.println("HttpClient>\tError: Buffer overflow.");
#endif
buffer[bufferPosition] = '\0'; // Null-terminate buffer
client.stop();
error = true;
#ifdef LOGGING
Serial.println("HttpClient>\tError: Response body larger than buffer.");
#endif
}
bufferPosition++;
}
#ifdef LOGGING
Serial.println("HttpClient>\tTerminating Buffer.");
#endif
buffer[bufferPosition] = '\0'; // Null-terminate buffer
i can see that the TCP Connection returns data in 128 bytes chunks, and it manages to receive two chunks, but when receiving the 257:th character it hangs.
If I run the same in the main loop the call returns, but after 256 characters the system logs an error
0000173096 [wiring] ERROR: recv error = 128
indicating that there is actually an error in the TCP client, but that this is recoverable while in the main loop.
I havn't run the code on a GSM Particle, but I have a Boron and a Electron at home and will do that tonight.
I have now tested with my Boron as well and this device has the same behaviour. As for the electron I have problems connecting that to the mobile network, but will follow up on that once i get it working.
The issue seems to be closed but we’re still getting these errors from all our 3rd gen devices (deviceOS 1.4.2) as we use TCPclient to send data & also Papertrail to monitor our logs. Any ideas?
It seems like we receive this error for each TCPclient.available() we do. We use the TCPclient in our own HTTPclient. This error returns aprrox. 1 message per second. Having 80 devices in the field (and steadily growing) this adds a huge overload on our Papertrail log limit
I found the following in spark_wiring_tcpclient_posix.cpp but not sure if this is the TCPclient we use because it opens spart_wiring_tcpclient if I click through.
Hi community, any idea why I’m still getting this error on all my devices in the field (and filling up my Papertrail logs)? Using deviceOS 1.4.4.
Thanks.
I had the same issue pop up using the TCPClient on Boron with DeviceOS 2.2.0. Electron on the same deviceOS was fine, as others have reported.
Interestingly, TCPClient was working fine on boron for a few weeks, and then with unrelated code changes today, this issue popped up. I may try to roll back the changes to see what line of code caused the issue.
It appears that filtering this message out using a logHandler level of LOG_LEVEL_NONE for wiring, as shown below, mitigates the problem, though this is fairly heavy-handed. I’d prefer to find a specific cause, but at least I can continue making progress on other things while I debug this.
SerialLogHandler logHandler(LOG_LEVEL_WARN, /* system level*/ {
/* specific handling for application, unspecified categories will default to
* LOG_LEVEL_INFO
*/
{"app", LOG_LEVEL_WARN},
{"wiring", LOG_LEVEL_NONE} // this mitigates the problem
});