OPCFoundation / UA-Java-Legacy

This repository is provided by OPC Foundation as legacy support for an Java version for OPC UA.
https://github.com/OPCFoundation/UA-.NETStandard
Other
354 stars 226 forks source link

Activate Session takes higher time around 40 seconds when reconnecting to OPC Server over LAN #202

Open pradeipk opened 4 years ago

pradeipk commented 4 years ago

Below is code snippet for reconnect when LAN or OPC Server goes down

sessionChannel.closeSecureChannel();
TransportChannelSettings settings = new TransportChannelSettings(); settings.getOpctcpSettings().setConnectTimeout(2000); settings.setDescription(this.endpoint);

// get a new secure channel to our already identified endpoint SecureChannel channel = client.createSecureChannel(getDiscoveryEndpointUri(), this.endpoint); // create a new SessionChannel from the old session and the new secure channel sessionChannel = sessionChannel.getSession().createSessionChannel(channel, this.client); sessionChannel.activate();

In the last step activate session is taking very high time around 40000 ms which is causing the other part of our client code breaking. This is happening when the client is connected to remote OPC Server . It works fine when the client and OPC Server are running on the same machine.

jouniaro commented 4 years ago

This either depends on the server (which server are you connecting to?) or your network, most probably. You should analyse the traffic with WireShark to see which messages are being sent and where the actual delay is. See https://www.prosysopc.com/blog/opc-ua-wireshark/ for details on how to do that

pradeipk commented 4 years ago

@jouniaro thanks for the quick reply, we will analyse the wireshark trace, meantime can you tell if it means that activate session has different turnaround time for different OPC Server. If this is true then in our client we need to tune different timeout for different servers. Can you also suggest a way to set shorter reconnect timeout, because reconnect in our client happens in synchronized block which keeps other threads in waiting state which is breaking the further functionality of our connector client.

jouniaro commented 4 years ago

Yes, it depends on the connection and server of course how quick you get the response.

pradeipk commented 4 years ago

Thanks @jouniaro, so we can not fix this issue at the client end by any means if the end server itself is delaying the response or do you suggest any workaround here ?

We are getting this issue for Prosys, Softing, Ua ansic OPC Simulation Servers. These are free versions do you see any improvement in turnaround time with paid versions of the same servers.

jouniaro commented 4 years ago

We have never experienced such delays with any of these servers ourselves, so you must have a problem in your network.

pradeipk commented 4 years ago

thanks @jouniaro