From 12:00 AM CDT Sunday, October 17 - 11:30 AM CDT Sunday, October 17, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

DQMH Consortium Toolkits Feature Requests

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Eric_BOB

Added a watchdog mechanism (optional) to automatically kill a lonely clones when the launcher is dead

Status: Declined

We think that this kind of feature would hide issues from the developers.

Sometimes you can lose communication with clones and can't send any "Stop" request.

In this case, those clones stay in memory in a running state, and it is very hard to kill them. Stop or Kill launcher have no effect. The only way I have found is to close the project but it's not very usefull.

It will be good to have a watchdog mechanism to kill lonely clones

As discussed here  JKI SMO and drjdpowell messenger library, have this kind of mechanism.

12 Comments
Enrique_Noe_Arias
Member

Hi Eric, the way I solve this issue is by opening the API Tester, then click the refresh button to list the active clones, and send to all a Stop Request.

 

Enrique Noé.

CLA Enrique Noé Arias

I'm attending the GLA Summit!

Olivier-JOURDAN
Active Participant

I make the same as Enrique, and it works in most cases.

When it's not working, it's basically myself doing wrong things in module code.

 

Can you tell us more about the cases you have ghost clones?

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | Certified LabVIEW Architect |
Eric_BOB
Member

Hello Enrique and Olivier.
You are right, the tester often allows you to re-access lost modules. But in my case, I had several crashes during the development phase and I found myself in the situation of not being able to communicate with these module clones.
Even if they stop works well, I find that a self-destruct mechanism would be a plus. I see this as an additional level of security.

Eric

drjdpowell
Trusted Enthusiast

With Messenger Library, I find the biggest advantage of the automatic shutdown feature is not needing to write (and debug) shutdown code.

 

But I'm not sure how well this would work with DQMH, which is more a "group of peers" architecture, than a "call hierarchy" one (like Messenger Library, AF or SMO).  Do DQMH modules have a well defined "Caller" who they should not outlive?

 

 

Olivier-JOURDAN
Active Participant

Do DQMH modules have a well defined "Caller" who they should not outlive?

 


No, nothing can prevent a user to start a module and then stop this part of the code. I never dive into Messenger, AF, or SMO, but how they can enforce that? 

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | Certified LabVIEW Architect |
drjdpowell
Trusted Enthusiast

It's like Queues and most other LabVIEW references.  Nothing stops you creating a Queue and then stopping that part of the code, but the Queue is automatically destroyed as well.  Queues are not independent of the code that created them, and do not outlive their creator.

joerg.hampel
Active Participant

With DQMH, you can choose to design a tree-like structure, or go with a flat one. So I think it would be hard to make that kind of „garbage collection“ part of the framework itself 🤷‍♂️


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

drjdpowell
Trusted Enthusiast

You could make it on optionally, based on an input to the vi that starts the module.  Then users could decide to use it if this module shouldn't outlive its creator.

Eric_BOB
Member

Thanks, Drjdpowell

It's exactly what I'm proposing.

joerg.hampel
Active Participant

After giving this some more thought, I have ambivalent feelings to be honest:

 

Not having to care about where and when to stop "child modules" is definitely handy for experienced software developers, and especially if you're implementing a strict actor tree structure. Without having tried it out myself, I feel like I would still recommend to our less proficient customers to not use the auto-shutdown option but consciously implement the shutdown code where they think it should go.

 

Also, what Eric seems to be describing ("Sometimes you can lose communication with clones") sounds to me not so much like a request for an additional design tool, but rather a helping hand when things go wrong and clones end up orphaned. For the current implementation of DQMH, not stopping modules is not an accepted scenario - you have to stop your clones, so losing the communication/reference constitutes an error.

 

Please don't get me wrong: I totally agree that this happens sometime, and that it would be handy to have a way to stop 'em all. I'm just not sure if the option that you describe, James, is the solution to the problem that Eric describes.

 

Looking forward to your thoughts!


DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)