Log In
Register
Topic RSS
17:53, EEST
September 21, 2018
Offline
Hi,
in our application we offer the possibility to scan the local network for available OPC servers.
While scanning we’ve caught the following exception:
null thread: TcpConnection/Read
java.lang.NullPointerException
at com.prosysopc.ua.stack.utils.TimerUtil.schedule(SourceFile:112)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.d(SourceFile:1304)
at com.prosysopc.ua.stack.transport.tcp.io.SecureChannelTcp.onClosed(SourceFile:674)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.a(SourceFile:1835)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection.a(SourceFile:139)
at com.prosysopc.ua.stack.transport.tcp.io.TcpConnection$b.run(SourceFile:855)
The follwing is logged by prosys:
com.prosysopc.ua.stack.utils.StackUtils: Uncaught Exception in Thread: Thread[OPC-UA-Stack-Blocking-Work-Executor-54,6,main] java.lang.NullPointerException
When closing the Tcp connection, a problem seems to occur at another protocol level (SecureConnection). It seems that an attempt is made to start a TimerTask on a non-existent timer.
Questions
– Is this a known problem?
– Why is neither an UncaughtExceptionHandler installed nor are all RuntimeExceptions and Errors caught in the TcpConnection.ReadThread?
– Is there a workaround?
Best regards,
Manfred
11:48, EEST
April 3, 2012
Offline
Hi,
We are aware of a cosmetic-only-NPE scenario due to a potential race-condition when the connection closes. This could be the same as https://forum.prosysopc.com/fo…..mx-is-null or the root cause could be the same.
Did your case result in something else than a cosmetic problem?
11:56, EEST
September 21, 2018
Offline
Hi Bjarne,
for us, this is not just a cosmetic problem.
A DefaultExceptionHandler is registered in our application.
The DefaultExceptionHandler catches all exceptions from threads that do not have an exception handler.
All exceptions that are caught in the DefaultExceptionHandler result in an alarm.
Filtering out exceptions from the TcpConnection/Read thread could be done using a heuristic, but that would not be very nice.
Best regards,
Manfred
16:17, EEST
April 3, 2012
Offline
I’ll try to increase priority on fixing this, we can send a beta when done.
18:50, EEST
September 21, 2018
Offline
That would be very nice!
Thanks and best regards,
Manfred
14:46, EEST
April 3, 2012
Offline
I’ll note that now our beta should include a workaround; you should have received a link via email. Note that since we now have a proper ticking system for the mails, the sender is different from the old one. The sender should be jira@prosysopc.atlassian.net and the reply-to address is jsdk-support@prosysopc.com. If you haven’t received the mail, please send mail to jsdk-support@prosysopc.com.
P.S.
We will try to change so that it would also send the mails as jsdk-support@prosysopc.com, so to a future reader the sender might be ‘jsdk-support@prosysopc.com’.
1 Guest(s)
