Who called my request?

[1984]

---

---

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.

[Olivier-JOURDAN]

---

@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.

[TiTou]

---

@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 :

`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.

[1984]

---

@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.

[joerg.hampel]

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).