In our app we use OPC Utgard library that is based on top of j-interop. There is an async mechanism of receiving values of OPC Server items. It simply registers a DCOM-callback wich is executed by the Server every pre-defined period, say 100 millis. When the app experience some load on non-OPC parts of the system (CPU usage is rather low), updates began to skip. Due to loosing changes we see gaps in value history.
Is there a way to avoid loosing callbacks or minimise it at least?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, I think it best if you would ask Utguard developers (Jens
Reinmann) , they would know better on how they have implemented callbacks.
In COM terms, there in't a way to minimize events to a registered callback.
In our app we use OPC Utgard library that is based on top of j-interop.
There is an async mechanism of receiving values of OPC Server items. It
simply registers a DCOM-callback wich is executed by the Server every
pre-defined period, say 100 millis. When the app experience some load on
non-OPC parts of the system (CPU usage is rather low), updates began to
skip. Due to loosing changes we see gaps in value history.
Is there a way to avoid loosing callbacks or minimise it at least?
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
Thanks Vikram, I've also asked Jens but no reply yet.
Also I've spent some time debugging the issue and found that it is likely j-interop that skips callbacks from the server. JIComOxidRuntimeHelper#startRemUnknown spawns a thread that executes JIComRuntimeEndpoint#processRequests. And it seems that at the process requests stage desired data is already lost.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Vikram, I've also asked Jens but no reply yet.
Also I've spent some time debugging the issue and found that it is likely
j-interop that skips callbacks from the server. JIComOxidRuntimeHelper#startRemUnknown
spawns a thread that executes JIComRuntimeEndpoint#processRequests. And
it seems that at the process requests stage desired data is already lost.
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
Sure I'll do, but could you point me to some instructions how to do this? Is some special filters should be enabled at Wireshark, or just the full traffic between two IPs will be enough?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Capture full traffic. For inspection you can use "dcerpc" but please make
sure there is no encryption on between client and server otherwise we will
not be able to inspect the packets.
Sure I'll do, but could you point me to some instructions how to do this?
Is some special filters should be enabled at Wireshark, or just the full
traffic between two IPs will be enough?
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
Here is the pcap. I've limited it to a destination IP.
There are 33 variable values received asynchronously via callbalck every 100 millis.
But indeed there are gaps with 200-300 millis.
Please tell me if you need more info. Thank you.
Can you also let me know which is the source machine and which is the
target (server) machine ? Amongst this timeline within this PCAP, when is
the call back initiated. As you might be able to infer, the entire
communication between client and server is encrypted ... this will make it
super hard to debug.
Here is the pcap. I've limited it to a destination IP.
There are 33 variable values received asynchronously via callbalck every
100 millis.
But indeed there are gaps with 200-300 millis.
Please tell me if you need more info. Thank you.
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
In our app we use OPC Utgard library that is based on top of j-interop. There is an async mechanism of receiving values of OPC Server items. It simply registers a DCOM-callback wich is executed by the Server every pre-defined period, say 100 millis. When the app experience some load on non-OPC parts of the system (CPU usage is rather low), updates began to skip. Due to loosing changes we see gaps in value history.
Is there a way to avoid loosing callbacks or minimise it at least?
Hi,
Unfortunately, I think it best if you would ask Utguard developers (Jens
Reinmann) , they would know better on how they have implemented callbacks.
In COM terms, there in't a way to minimize events to a registered callback.
best regards,
Vikram
On Wed, Aug 10, 2016 at 5:31 PM, Daniel gdaniq@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Thanks Vikram, I've also asked Jens but no reply yet.
Also I've spent some time debugging the issue and found that it is likely j-interop that skips callbacks from the server. JIComOxidRuntimeHelper#startRemUnknown spawns a thread that executes JIComRuntimeEndpoint#processRequests. And it seems that at the process requests stage desired data is already lost.
Hi,
Can you verify that with packet capture ? I can then have a look to see
what gives ...
best regards,
Vikram
On Wed, Aug 10, 2016 at 7:50 PM, Daniel gdaniq@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Sure I'll do, but could you point me to some instructions how to do this? Is some special filters should be enabled at Wireshark, or just the full traffic between two IPs will be enough?
Hi,
Capture full traffic. For inspection you can use "dcerpc" but please make
sure there is no encryption on between client and server otherwise we will
not be able to inspect the packets.
best regards,
Vikram
On Thu, Aug 11, 2016 at 1:25 PM, Daniel gdaniq@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Hi Vikram,
Here is the pcap. I've limited it to a destination IP.
There are 33 variable values received asynchronously via callbalck every 100 millis.
But indeed there are gaps with 200-300 millis.
Please tell me if you need more info. Thank you.
Hi,
Can you also let me know which is the source machine and which is the
target (server) machine ? Amongst this timeline within this PCAP, when is
the call back initiated. As you might be able to infer, the entire
communication between client and server is encrypted ... this will make it
super hard to debug.
thanks,
best regards,
Vikram
On Mon, Aug 15, 2016 at 7:15 PM, Daniel gdaniq@users.sf.net wrote:
--
The Mind is a place of its own. It can make a heaven out of hell or a hell
out of heaven. Attitude is everything. No matter how adverse conditions
maybe, one has the capacity to turn things around by one's Determination,
Perseverance and Hardwork.
John Milton
(Paradise Lost)
Hi Vikram,
Seems it was a false alarm. We've re-examined our data flow and found no data loss at this time.
j-interop works nice, thank you for your afforts!
Daniel.