You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Julian Feinauer <j....@pragmaticminds.de> on 2019/04/12 08:56:27 UTC
[Netty / S7] Many log messages although everything works
Hi all,
as many of you may know, we use PLC4X pretty heavily in Prod.
We recently checked our logs and found a lot of entries from PLC4X which are thrown although everything is working.
This is something I want to fix (if theres no issue then be silent).
We use the S7 driver, but I think this is a general Netty (tcp?) topic.
The mostly logged issue is thrown logged by io.netty.channel.DefaultChannelPipeline and is
```
An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[?:1.8.0_161] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[?:1.8.0_161] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[?:1.8.0_161] at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1108) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:345) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]
```
Could anyone comment on that, what this means or what we can / should do to handle this?
We get this entry nearly 100 times a hour (for multiple hundreds requests).
Re: [Netty / S7] Many log messages although everything works
Posted by Christofer Dutz <ch...@c-ware.de>.
But that's not the way you handle logging.
Logging frameworks are built to allow analysis and turn on and off this parts interesting to me as a user. The way you define what you want is by configuring the logging.
Staying by your car example:
Probably you didn't leave the volume of the stereo at the factory setting ;-) so that's what we/you have to do to.
Chris
Outlook für Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Julian Feinauer <j....@pragmaticminds.de>
Sent: Friday, April 12, 2019 11:06:31 AM
To: dev@plc4x.apache.org
Subject: Re: [Netty / S7] Many log messages although everything works
Hi Chris,
well.. thats like the handling procedure if you have an unknown noise in your car... turn the radio louder __
In this case, I wanted to delete the curse not mute the logs... as It sounds for me this is a issue to be addressed.
Julian
Am 12.04.19, 11:01 schrieb "Christofer Dutz" <ch...@c-ware.de>:
You could increase the log-level ... should reduce the amount of logging drastically.
Chris
Am 12.04.19, 10:56 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
Hi all,
as many of you may know, we use PLC4X pretty heavily in Prod.
We recently checked our logs and found a lot of entries from PLC4X which are thrown although everything is working.
This is something I want to fix (if theres no issue then be silent).
We use the S7 driver, but I think this is a general Netty (tcp?) topic.
The mostly logged issue is thrown logged by io.netty.channel.DefaultChannelPipeline and is
```
An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[?:1.8.0_161] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[?:1.8.0_161] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[?:1.8.0_161] at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1108) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:345) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]
```
Could anyone comment on that, what this means or what we can / should do to handle this?
We get this entry nearly 100 times a hour (for multiple hundreds requests).
Re: [Netty / S7] Many log messages although everything works
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Chris,
well.. thats like the handling procedure if you have an unknown noise in your car... turn the radio louder __
In this case, I wanted to delete the curse not mute the logs... as It sounds for me this is a issue to be addressed.
Julian
Am 12.04.19, 11:01 schrieb "Christofer Dutz" <ch...@c-ware.de>:
You could increase the log-level ... should reduce the amount of logging drastically.
Chris
Am 12.04.19, 10:56 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
Hi all,
as many of you may know, we use PLC4X pretty heavily in Prod.
We recently checked our logs and found a lot of entries from PLC4X which are thrown although everything is working.
This is something I want to fix (if theres no issue then be silent).
We use the S7 driver, but I think this is a general Netty (tcp?) topic.
The mostly logged issue is thrown logged by io.netty.channel.DefaultChannelPipeline and is
```
An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[?:1.8.0_161] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[?:1.8.0_161] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[?:1.8.0_161] at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1108) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:345) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]
```
Could anyone comment on that, what this means or what we can / should do to handle this?
We get this entry nearly 100 times a hour (for multiple hundreds requests).
Re: [Netty / S7] Many log messages although everything works
Posted by Christofer Dutz <ch...@c-ware.de>.
You could increase the log-level ... should reduce the amount of logging drastically.
Chris
Am 12.04.19, 10:56 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
Hi all,
as many of you may know, we use PLC4X pretty heavily in Prod.
We recently checked our logs and found a lot of entries from PLC4X which are thrown although everything is working.
This is something I want to fix (if theres no issue then be silent).
We use the S7 driver, but I think this is a general Netty (tcp?) topic.
The mostly logged issue is thrown logged by io.netty.channel.DefaultChannelPipeline and is
```
An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. java.io.IOException: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[?:1.8.0_161] at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[?:1.8.0_161] at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[?:1.8.0_161] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[?:1.8.0_161] at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1108) ~[netty-buffer-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:345) ~[netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459) [netty-transport-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:886) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.23.Final.jar!/:4.1.23.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]
```
Could anyone comment on that, what this means or what we can / should do to handle this?
We get this entry nearly 100 times a hour (for multiple hundreds requests).
Re: [Netty / S7] Many log messages although everything works
Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi,
sorry, also some meetings : )
We should investiage it (in fact Tim is just doing that, I think).
And either it’s a "regular" case, then we should set a log output on the right level.
And if its something we can handle more gracefully, tha we should do that : )
Julian
PS.: I think we should discuss the logging overall. I'm unsure if I like the S7 Info log, which always gives me 3 or 4 Log statements on each connection (and I establish MANY of them, regularly __).
Am 12.04.19, 15:26 schrieb "Christofer Dutz" <ch...@c-ware.de>:
Hi Otto,
when inspecting the TCP traffic, for example Siemens LOGO devices tend to just hang up without sending a TCP ack if they get something they don't like.
It's not TCP compliant, but it's the way they roll :-(
So I know when trying to access a LOGO device with the S7 protocol, I had to disable the part where the driver tries to find out what type of PLC he is talking to because of this ... don't really know how we can counter-react this situation ...
How about me adding the Exception handler and simply logging things there so we can define a breakpoint and try to find out what's going on?
Chris
Am 12.04.19, 15:06 schrieb "Otto Fowler" <ot...@gmail.com>:
I would think you’d want to handle it, and then investigate the reason for
it in this instance
On April 12, 2019 at 08:51:05, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi Otto,
I think the English translation would be something like:
"Connection reset by remote" or "Connection reset by peer"
Not sure if this helps understand what's going on ... I always thought it
was related to
the PLC hanging up without following the correct procedure for doing that.
Sort of like
just hanging up the phone without saying goodbye.
Perhaps really implementing an exception handler and just swallowing the
exception
Because we know we're operating in "unpolite" environments ... but not sure
what
We could do to gracefully handle the situation.
@Julian ... would it be ok to catch that and simply log an "INFO" severity
message ("Remote hung up unexpectedly")
Chris
Am 12.04.19, 13:52 schrieb "Otto Fowler" <ot...@gmail.com>:
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Otto Fowler <ot...@gmail.com>.
I think adding the handling is the first thing to do, if this freaks out
someone who knows what they are doing, what will it do to someone new to
the project?
Also, maybe the drivers will need a quirks mode?
On April 12, 2019 at 09:26:25, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi Otto,
when inspecting the TCP traffic, for example Siemens LOGO devices tend to
just hang up without sending a TCP ack if they get something they don't
like.
It's not TCP compliant, but it's the way they roll :-(
So I know when trying to access a LOGO device with the S7 protocol, I had
to disable the part where the driver tries to find out what type of PLC he
is talking to because of this ... don't really know how we can
counter-react this situation ...
How about me adding the Exception handler and simply logging things there
so we can define a breakpoint and try to find out what's going on?
Chris
Am 12.04.19, 15:06 schrieb "Otto Fowler" <ot...@gmail.com>:
I would think you’d want to handle it, and then investigate the reason for
it in this instance
On April 12, 2019 at 08:51:05, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi Otto,
I think the English translation would be something like:
"Connection reset by remote" or "Connection reset by peer"
Not sure if this helps understand what's going on ... I always thought it
was related to
the PLC hanging up without following the correct procedure for doing that.
Sort of like
just hanging up the phone without saying goodbye.
Perhaps really implementing an exception handler and just swallowing the
exception
Because we know we're operating in "unpolite" environments ... but not sure
what
We could do to gracefully handle the situation.
@Julian ... would it be ok to catch that and simply log an "INFO" severity
message ("Remote hung up unexpectedly")
Chris
Am 12.04.19, 13:52 schrieb "Otto Fowler" <ot...@gmail.com>:
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Otto,
when inspecting the TCP traffic, for example Siemens LOGO devices tend to just hang up without sending a TCP ack if they get something they don't like.
It's not TCP compliant, but it's the way they roll :-(
So I know when trying to access a LOGO device with the S7 protocol, I had to disable the part where the driver tries to find out what type of PLC he is talking to because of this ... don't really know how we can counter-react this situation ...
How about me adding the Exception handler and simply logging things there so we can define a breakpoint and try to find out what's going on?
Chris
Am 12.04.19, 15:06 schrieb "Otto Fowler" <ot...@gmail.com>:
I would think you’d want to handle it, and then investigate the reason for
it in this instance
On April 12, 2019 at 08:51:05, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi Otto,
I think the English translation would be something like:
"Connection reset by remote" or "Connection reset by peer"
Not sure if this helps understand what's going on ... I always thought it
was related to
the PLC hanging up without following the correct procedure for doing that.
Sort of like
just hanging up the phone without saying goodbye.
Perhaps really implementing an exception handler and just swallowing the
exception
Because we know we're operating in "unpolite" environments ... but not sure
what
We could do to gracefully handle the situation.
@Julian ... would it be ok to catch that and simply log an "INFO" severity
message ("Remote hung up unexpectedly")
Chris
Am 12.04.19, 13:52 schrieb "Otto Fowler" <ot...@gmail.com>:
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Otto Fowler <ot...@gmail.com>.
I would think you’d want to handle it, and then investigate the reason for
it in this instance
On April 12, 2019 at 08:51:05, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:
Hi Otto,
I think the English translation would be something like:
"Connection reset by remote" or "Connection reset by peer"
Not sure if this helps understand what's going on ... I always thought it
was related to
the PLC hanging up without following the correct procedure for doing that.
Sort of like
just hanging up the phone without saying goodbye.
Perhaps really implementing an exception handler and just swallowing the
exception
Because we know we're operating in "unpolite" environments ... but not sure
what
We could do to gracefully handle the situation.
@Julian ... would it be ok to catch that and simply log an "INFO" severity
message ("Remote hung up unexpectedly")
Chris
Am 12.04.19, 13:52 schrieb "Otto Fowler" <ot...@gmail.com>:
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Otto,
I think the English translation would be something like:
"Connection reset by remote" or "Connection reset by peer"
Not sure if this helps understand what's going on ... I always thought it was related to
the PLC hanging up without following the correct procedure for doing that. Sort of like
just hanging up the phone without saying goodbye.
Perhaps really implementing an exception handler and just swallowing the exception
Because we know we're operating in "unpolite" environments ... but not sure what
We could do to gracefully handle the situation.
@Julian ... would it be ok to catch that and simply log an "INFO" severity message ("Remote hung up unexpectedly")
Chris
Am 12.04.19, 13:52 schrieb "Otto Fowler" <ot...@gmail.com>:
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Christofer Dutz <ch...@c-ware.de>.
Oh .. I must apologize to you Julian,
Sitting in yet another meeting and viewing emails on my phone isn't that ideal. What I saw reminded me to normal log output, but after Otto's comment I had another look ... You are absolutely right ... We should fix that.
Unfortunately I'm a little lost at what's exactly causing the problem and have always been, because these entries have been there since the beginning :-(
Chris
Outlook für Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Otto Fowler <ot...@gmail.com>
Sent: Friday, April 12, 2019 1:52:34 PM
To: dev@plc4x.apache.org
Subject: Re: [Netty / S7] Many log messages although everything works
Maybe all the streams aren’t getting closed correctly?
On April 12, 2019 at 07:52:04, Otto Fowler (ottobackwards@gmail.com) wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Otto Fowler <ot...@gmail.com>.
Maybe all the streams aren’t getting closed correctly?
On April 12, 2019 at 07:52:04, Otto Fowler (ottobackwards@gmail.com) wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException
Re: [Netty / S7] Many log messages although everything works
Posted by Otto Fowler <ot...@gmail.com>.
The netty handlers don’t implement exceptionCaught so the default is to
spew to logs. I don’t speak german so I don’t know what the exception
message is.
Maybe the handlers should implement the method.
On April 12, 2019 at 04:56:40, Julian Feinauer (j.feinauer@pragmaticminds.de)
wrote:
An exceptionCaught() event was fired, and it reached at the tail of the
pipeline. It usually means the last handler in the pipeline did not handle
the exception. java.io.IOException