DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Who called my request?



5 years ago when I started using DQMH, I also needed this to help debug and started to put an 'origin' string in the request arguments' cluster and in practice would put the name of the module calling the request.


Well I guess it makes us two. And I assume that this can't be automated and the "origin" string (or other reference) can not be obtained from the event reference itself in the EHL 😞

 

Adding an "origin" to the arguments is quite painful cause it adds complexity and I only need it extremely rarely.

0 Kudos
Message 11 of 15
(517 Views)

@TiTou  a écrit :

@1984  a écrit :

Hi,

 

Is there a way to know who called a given request? We found that knowing that could help a lot debugging certain bugs, but at this point the only way I could program it is to add a "call-chain" string argument to the request which is passed to the DQMH module where I could log this to a file (or whatever). This doesnt look too much of an elegant solution as for each requests I'd like to track I need to add an extra - otherwise useless - input.

 

Is there a more sophisticated way?

 

Thanks.


5 years ago when I started using DQMH, I also needed this to help debug and started to put an 'origin' string in the request arguments' cluster and in practice would put the name of the module calling the request.
Basic, works well enough for me.
Also sometimes, for request with reply, I add a timestamp in the request argument cluster so that the caller call indicate at which time it sent the request, then the receiver can check reception latency, this is useful when using the network module from HSE 😉


That's what you will get with the sequence diagram displayed by Lumos.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 12 of 15
(509 Views)

@1984  a écrit :


Adding an "origin" to the arguments is quite painful cause it adds complexity and I only need it extremely rarely.


Really? I mean... i understand that if you have to add 'origin' in the messages you want to trace in a large app it may become annoying.

But when you create a module that exposes public API request for others, if you have the slightest guess that request will be called from many other modules it would be crazy to not include 'origin' in the request argument.
I usually do it this way :

TiTou_0-1703057967751.png

`origin` is optional, this way, i can either put the calling module name of event go further add info about the reason why the calling module is using the request.


We have two ears and one mouth so that we can listen twice as much as we speak.

Epictetus

Antoine Chalons

0 Kudos
Message 13 of 15
(478 Views)

@TiTou wrote:

 

Really? I mean... i understand that if you have to add 'origin' in the messages you want to trace in a large app it may become annoying.

Yes, really. I dont think one has any chance to know upfront if a certain module / request whatever will cause a problem so its pretty much impossible to determine if an origin argument is needed or not. Your implementation takes an extra tunnel off of the connector pane which most likely will be unused for 99.9% of the times.

 

When we needed we did it in a way that we indeed added the origin to the arguments, but we simply passed the callchain to the request as a flattened string. This is not equivalent to yours cause yours might have different information but worked for us.

 

I dont know if lumos is the answer to this, cause here the key is not constantly monitoring who sends a message to who but that we recognized that we have a problem and we like to capture a rare occurence not to constantly monitor everything. Of course lumos might have a clever API we can use for this purpose.

 

I filed a feature request, will see if it gets accepted.

 

 

0 Kudos
Message 14 of 15
(468 Views)

I think part of this we handle with our HSE Logger. If (and that's of course a bit of work) we have the log VIs in the right place, the logfile will tell us the order of events and thus allows us to deduce who called a request (amongst other things). 




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 15 of 15
(452 Views)