You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-->javax.net.ssl|WARNING|E1|MQTT Rec: @{"organization":"A&D", "program":"Cardiac Recovery"}|2024-11-02 19:12:05.463 EDT|SSLSocketImpl.java:1666|handling exception (
"throwable" : {
java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:283)
at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:309)
at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350)
at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803)
at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478)
at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472)
at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1455)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1059)
at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:966)
at java.base/java.io.DataInputStream.readByte(DataInputStream.java:271)
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:137)
at java.base/java.lang.Thread.run(Thread.java:833)}
every second when running with tls (ssl) debug turned on System.setProperty("javax.net.debug", "SSL");
Looking at the source code here at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92) I see this:
try {
// read header
if (remLen < 0) {
// Assume we can read the whole header at once.
// The header is very small so it's likely we
// are able to read it fully or not at all.
// This keeps the parser lean since we don't
// need to cope with a partial header.
// Should we lose synch with the stream,
// the keepalive mechanism would kick in
// closing the connection.
bais.reset();
byte first = in.readByte();
clientState.notifyReceivedBytes(1);
byte type = (byte) ((first >>> 4) & 0x0F);
if ((type < MqttWireMessage.MESSAGE_TYPE_CONNECT) ||
(type > MqttWireMessage.MESSAGE_TYPE_DISCONNECT)) {
// Invalid MQTT message type...
throw ExceptionHelper.createMqttException(MqttException.REASON_CODE_INVALID_MESSAGE);
}
remLen = MqttWireMessage.readMBI(in).getValue();
bais.write(first);
// bit silly, we decode it then encode it
bais.write(MqttWireMessage.encodeMBI(remLen));
packet = new byte[(int)(bais.size()+remLen)];
packetLen = 0;
}
// read remaining packet
if (remLen >= 0) {
// the remaining packet can be read with timeouts
readFully();
// reset packet parsing state
remLen = -1;
byte[] header = bais.toByteArray();
System.arraycopy(header,0,packet,0, header.length);
message = MqttWireMessage.createWireMessage(packet);
// @TRACE 301= received {0}
log.fine(CLASS_NAME, methodName, "301",new Object[] {message});
}
} catch (SocketTimeoutException e) {
// ignore socket read timeout
}
Note the // ignore socket read timeout. Now I am not sure if the repeated stack traces (which absolutely overwhelm the output of any other information) is an error on my part, the paho library or not an error at all.
If this is expected behavior, it makes the ssl debugging option almost useless. If it is expected behavior can I ask why it must be so? Can the timeout be made longer so as not to overwhelm any other output?
The text was updated successfully, but these errors were encountered:
I get the following stacktrace
every second when running with tls (ssl) debug turned on
System.setProperty("javax.net.debug", "SSL");
Looking at the source code here
at org.eclipse.paho.client.mqttv3.internal.wire.MqttInputStream.readMqttWireMessage(MqttInputStream.java:92)
I see this:Note the
// ignore socket read timeout
. Now I am not sure if the repeated stack traces (which absolutely overwhelm the output of any other information) is an error on my part, the paho library or not an error at all.If this is expected behavior, it makes the ssl debugging option almost useless. If it is expected behavior can I ask why it must be so? Can the timeout be made longer so as not to overwhelm any other output?
The text was updated successfully, but these errors were encountered: