-
Notifications
You must be signed in to change notification settings - Fork 664
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get client connection state #521
Comments
What worked for me as a workaround is |
I think that with the current implementation, you get a crash is connection is not succesfull. BUT as with any networking system, things may hang for along time depending on timeouts. |
Thing is, yes, I get a crash, but how can I react to it programmatically? The exception occurs in another thread.. |
I do not know you application, but usually, people have a kind of ua thread that fetch/push data under a big try/except and restart connection if there is any exception
I know that some libraries do that kind of things for you, but from my experience this is very fragile so I thought it was better to let people do what works for them |
I am working with subscriptions. In your example the exception would be raised from get_value(), right? I can catch that, since it occurred in my own thread. |
for the subscriptions callback this should not change anything, but you need to recreate your subscritions after connecting, since they are lost when disconnecting (ua does allow to reconnect to a subcription, but we do not support that currently, we close them when disconnecting) |
but if you want to know is connection is lost, you need a kind of polling anyway. This is what clients like uaexpert do. We could have added it into the KeepAlice class, although it is probably more complicated to configure it than just just implementing it |
Yes it does. The exception is raised within your thread, which is then ended. The rest of my program doesn't notice and so I am not able to handle the situation. Just as in the example below. The prgram will run to it's end and not react to the raised exception.
What I am doing right now is checking if your internal thread is alive. If there was some exception as described above it will have died and I can try to reconnect. However, that's a hacky solution. Much nicer would be either a method of the client as requested by @daniel-brosche, or maybe the possiblity to register a callback. |
This is a general issue in multi processing. If a thread dies you need a way to communicate the info to the others, isn'it?
I know a lot of people seems to want that kind of things. I think it is broken since it is much easier to have my own thread as shown above that monitors the connection and clean up things if necessary. But is someone make a class for that I am open to merge it (It migth be possible to add that functionnality to the "KeepAlive" class). it should simply be a class started with a polling interval and the possibility to register callbacks to be called if connection is lost, and maybe if connection is remade. It could also have a is_connected attribute if some people want to add one more layer of polling It has also been propose once to make a ClientForDummies class that automatically reconnects. It iis more work since it needs to keep track of all subscriptions, etc,... |
and if someone has even more time: The entire client/server API should be ported to the async module to offer an async api. This is more work... an attempte started there: #558 |
This issue is ancient, but still a legitimate concern. Suggested a small update to include a simple connection test (based on the thread check shown above) to check for dropped connections. This is particularly useful when you are only subscribing to the OPC - you don't get the opportunity to catch exceptions on connection failure if you're not actively polling. I also considered sending 'hello' requests occasionally, but Hello doesn't appear to be supported by some OPCUA servers. |
Hi! |
I use this in my solution:
because default timeout is 1 hour. |
I did not find a possibility to check that a client connection has been successfully established like
client.is_connected
.The text was updated successfully, but these errors were encountered: