Skip to content

[DP-100] Implement monitoring for registry values #212

Closed

Description

@qnikst

[Imported from JIRA. Reported by Alexander Vershilov @qnikst) as DP-100 on 2015-01-30 12:04:08]
Currently it's possible to store remote processes in registry, but such processes are not guaranteed to be monitored. So when remote process dies current node will never receive an event about process death so will never free value from registry and this could potentialy lead to memory leaks.

We need to elaborate a good solution for this issue.

Activity

  1. changed the title [-]Implement monitoring for registry values[/-] [+][DP-100] Implement monitoring for registry values[/+] on Jun 18, 2015
  2. qnikst commented on Jun 19, 2015

    @qnikst
    ContributorAuthor

    Addressed in PR #184.

  3. linked a pull request that will close this issueLean into static pointers #493on Oct 14, 2026
  4. hyperthunk commented on Oct 23, 2026

    @hyperthunk
    Member

    @LaurentRDC how does the removal of the remote table resolve this PR? I'm slowly reintroducing myself and not actively contributing at the moment, so I'm mostly just curious.

  5. LaurentRDC commented on Oct 23, 2026

    @LaurentRDC
    Member

    My understanding of the issue is that if the remote table is gone, the underlying issue of this ticket (storing a remote process in the remote table leaks) doesn't exist anymore.
    Maybe I misunderstood and this issue is worth solving separately?

  6. hyperthunk commented on Oct 26, 2026

    @hyperthunk
    Member

    I think there issue here was less the leaking process handle (thought that is clearly bad) and more than the notification wasn't arriving. I don't think the bug described here has been confirmed to be directly related to the use of the remote table, but it's quite possible I'm missing some nuance here about the changes your static pointers patch brings with it?

  7. hyperthunk commented on Oct 26, 2026

    @hyperthunk
    Member

    Hmmm, all of the linked / related issues are merged resolved. I wonder if this is a dangling record, and actually no fix is needed?

    I'll try and get a build environment set up over the weekend and see if I can raise a failing test case, otherwise this could be a non-issue!

  8. hyperthunk commented on Oct 26, 2026

    @hyperthunk
    Member

    Okay, I am pretty certain the original scenario was fixed in #322, but we have an already-dead case remaining here. Personally I think this should be closed, but I'm not a maintainer these days so I leave that to your judgement @LaurentRDC. I will submit a PR for the remaining bug shortly.

  9. LaurentRDC commented on Oct 27, 2026

    @LaurentRDC
    Member

    Thanks @hyperthunk ! I'll close this for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions