Is this a good idea?
I have heard editing the GUI from threads isn’t a good idea, but how about webthreads? I have been using webthreads as session based timers quite happily for a while. However, our production environment is now spewing all sorts of ambiguous errors like:
...
Runtime Error
Please report what caused this error along with the information below.
Common/ClassLib/RuntimeThread.cpp: 1426
Failure Condition: !sCurrentThread->mCurrentException
...
...
An exception of class NilObjectException was not handled. The application must shut down.Runtime Error
Please report what caused this error along with the information below.
Common/ClassLib/RuntimeThread.cpp: 1426
Failure Condition: !sCurrentThread->mCurrentException
...
...
Exception Message:
Exception Error Number: 0
...
Any Ideas?
Greg will probably chime in, but at first glance, although it happens in the thread, the errors may not be related to the thread itself.
Runtime Error and NilObjectException can occur for many reasons. For instance NilObjectException may be the control you tried to access is already gone, perhaps because the WebContainer that it was instantiated into has been closed.
Are you building in 64-bit? Then try building in 32 bit and see if the crashes happen there as well. There are known bugs with 64 bit and Exceptions in Threads or killing them (which is essentially an Exception). At least one of them seems to be fixed for the upcoming release, likely the one you are encountering: <https://xojo.com/issue/48021> It seems possible to work around them, but this is quite cumbersome…
Keep in mind that all of your code runs in a WebThread when it comes right down to it. Whenever a request comes in and needs to be processed for a particular session, its in a WebThread.
As for accessing the GUI, technically you shouldnt have an issue as the polling mechanism for sending responses to the browser is already on the main thread.
Thanks Michel, that could be the right track as this issue usually comes up when connecting to the app from a high latency networks. But surely this shouldn’t cause the entire app to crash right?
Some more information…
I am also making Async calls using a subclassed Xojo.Net.HTTPSocket. They have given me grief in the past, perhaps they are related.
To run code in the main thread and in session context from Xojo.Net.HTTPSocket events I have been using webthreads.
I’ll implement some better code to let the threads scope out instead of killing them as mentioned in other posts. Perhaps that will solve the issue. If not, I may have to wait till 2018r1. As for now our production system is impaired!
As always Greg, thanks for the clarification. Does this mean it is safe to access the GUI from a standard thread provided you get the session context?
If you have no error handling, a nil object exception for instance can most certainly crash the entire app. And a runtime exception could probably as well. It is usually pretty low in the program.
I would try to implement WebSession.UnhandledException
http://documentation.xojo.com/index.php/WebSession.UnhandledException
That would allow you to trap all unmanaged errors and prevent a crash of the entire app. It is not a cure, though.
Maybe Greg can help tracing these errors more finely.
I wouldnt. Just use a WebThread. The system automatically keeps track of the session and will do the right thing.
Just to clarify it’s a proof of concept not a production system so no panic.
Daniel has implemented HTTP/2 + HTTPS on AWS load balancer which has helped reduce high-latency network related errors somewhat, and is trying more robust exception handling for the rest. Seems to be working so far.
Thanks very much for all your help!