Reconnect with ongoing Subscriptions #3599
Labels
Component: Server
Issues related to the server code
Priority: Medium
Issue with medium priority
Status: Pending
Needs final decision if issue is valid or should be abandoned. Or if the issue needs to be discussed
Type: Bug
Bug in the code which needs to be fixed
Comments
|
Can you run in a debugger or with valgrind and send a stack trace? It seems you call UA_Client_connect a lot. Why? |
|
Thanks for the reply, jpfr! I have a loop in which the connect is run every second. Removing it doesn't change the issue. Here is the log. Interestingly after the BadInternalError, UA_Client_run_iterate(client, 1000) starts itterating like crazy without respecting the timeout (I had to put a sleep of 100 do limit the Client connect iterate). The output of |
|
The connection fails with this:
After this, Client_run_iterate will immediately bail every time. Can you reproduce the crash with Valgrind as well? |
yes, therefore I was calling Client_connect, although it didn't help. So far, I need to delete the client, and create a new one each time I get bad ConnectStatus (every 450 secs). Maybe there is some fundamental flaw in my code? Here is a minimal example that reproduces the BadConnectionClose error, without a crash: To reprodice the crash, one needs to change the callback function from |
|
Looking at UA_Variant *val = UA_Variant_new();
UA_Client_readValueAttribute(client, UA_NODEID_NUMERIC(3, 10202), val);
UA_LOG_INFO(UA_Log_Stdout, UA_LOGCATEGORY_USERLAND, "read value is %f (iter=%f",
*((float*)val->data), *(UA_Float *) value->value.data);When the client is disconnected, |
|
Yes, that's true, the reference to val is causing the crash. Thanks! |
jpfr
changed the title
|
Hi jpfr, I'm getting this nasty BadInternalError for any client actually, not just during subscrption. for building the library, I use then to compile the client below: Edit: as a workaround, placing |
|
I guess you meet the same issue as mine. It is about the secure channel session renewal, which caused by: And there is another issue about session renewal, which is about the tokenId. I am not sure about the logic of nextSecurityToken, so I have an dirty fix on following |
|
@jpfr |
|
Yes, you can send requests during the renewal. |
|
@kleskjr I tried out the code but could not reproduce the issue. |
jpfr
added a commit
to jpfr/open62541
that referenced
this issue
Jun 11, 2020
…annel is closed The solution was supplied by @srdgame in open62541#3599.
jpfr
added a commit
to jpfr/open62541
that referenced
this issue
Jun 11, 2020
…annel is closed The solution was supplied by @srdgame in open62541#3599.
jpfr
added a commit
to jpfr/open62541
that referenced
this issue
Jun 12, 2020
…annel is closed The solution was supplied by @srdgame in open62541#3599.
|
@jpfr build with: compiled with: versions: |
|
@jpfr If you set the serviceResult to be BADCONNECTIONCLOSED, will it generate an session closed state? In my case that the opcua service provided by an embedded device, which has pretty low performance on creating subscription. If we have more than 400 nodes to be subscribed, it takes more than 5 minutes which is the session timeout. If session renewal generates the session state 'CLOSED', it will break initialization process of my application Yes, the POOR device takes about one second to handle one 'SUB' request. |
|
@jpfr facing same issue while connecting with server without any security policy I get an error like this. |
NoelGraf
added
Component: Server
这段代码如果连接是正确的，返回超时错误导致的，我理解的 UA_Client_run_iterate 这个函数返回结果如果是 UA_STATUSCODE_GOOD 然后直接return retval; 版本 1.3.6 |
|
@aiweed added this comment:
I don't fully agree with the change. Since this issue was opened we have reworked the client logic and also tested against the Prosys simulation server. |
|
you are right. If I modify it like this, I find that the server restarts abnormally and the client cannot automatically connect. If the network is disconnected, it seems to be able to connect automatically, but if the server restarts, it cannot reconnect normally. Therefore, I have judged the timing of reconnection and can reconnect normally. |
|
We have different levels of "abort". You can solve this by having an "outer loop" that does a reset+reconnect if a connection has failed in a way that cannot be recovered. We could think of having automated retry with a delay. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The client keeps crashing during continous work. Usually, the problem arises during the renew of SecureChannel (~450 secs after initial connect. Maybe this duration comes from the 75% of 10 mins channel life-time). I experince this issue on various clients, client that writes periodically, or one that is subscribed to value changes.
Log of a client that is subscribed to a value change of 1 variable
Log of client that reads a value in a subscription callback:
Log of the writing client:
Background Information / Reproduction Steps
Used CMake options:
Checklist
Please provide the following information:
UA_LOGLEVELset as low as necessary) attachedThe text was updated successfully, but these errors were encountered: