On Thu, Dec 4, 2014 at 12:20 PM, <[email protected]> wrote: > when the job configuration is 1) reloaded from > disk, 2) updated via the jenkins API (HTTP POST method), or 3) updated with > jenkins job builder. In these cases it seems that the stop method is never > called
Yes, a core bug, probably not filed. Currently Trigger.stop is called only from the UI-driven configure method. Perhaps the same for .start, not sure. Feel free to file the bug, especially if you have concrete cases that reproduce it. Fixing that bug would help with certain cases of JENKINS-23152, though probably not all, hence my comment; if you file it, link to JENKINS-23152. > It seems as though an entirely new trigger object > has been created without destroying the old one Correct. Objects like builders and triggers are freely recreated from JSON form submissions, disk deserialization, and so on, and so should generally not have any mutable state. > I can't figure out how to reference the old one so I can clean up. I would try using a WeakHashMap keyed off the job to keep track of what connections you have outstanding. Just take care that the value (whatever that is—a connection, perhaps) does not strongly refer to the key, directly or indirectly, or the entry will never be collected. And remember that there is no absolute guarantee that Trigger.stop will ever be called, since the whole project could simply be deleted, for example. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2tGHNkVURwCj6Kn1V%2BGQmo3prtMCkYrTWFV8kDMBSxAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
