Hi,

In the world OPC UA and our SDK, that is old. But functionality-wise should not matter in this case.

Is the server also made with our SDK or with something else?

The only thing the XXXAsync methods do is that instead on blocking the calling thread until the server returned a response is that they instead call the callback (on internal worker thread pool) once the server responds. If the server does not respond, we also cannot call the callback. That is to say, if the server choses to process them sequentially with the first one blocking, then it would not start on the second one before the first one completed.

Assuming you could use NONE or just SIGN messagesecuritymode, you can verify this via https://www.prosysopc.com/blog/opc-ua-wireshark/ to see when the actual network traffic happens. You should see both WriteRequests be sent to the server (i.e. one whenever you did call the writeAsync). After server responds with WriteResponse you should see your callback being called.

Some extra notes based on some investigations. Note that the actual internal low-level message sending logic is very old and sort of “battle-tested” in the stack layer. Anyway, it seems due to it the writeAsync could also block if any other message is being sent (just the sending part), i.e. if you would call the method twice, they might both return only after both messages were pushed to the tcp stream. But I would not complete rule out possible bugs there, just that we most likely would have heard them by now if they would be “that major”.