On Thursday, December 4, 2014, Jesse Glick <[email protected]> wrote:
> On Thu, Dec 4, 2014 at 12:20 PM, <[email protected] <javascript:;>> > 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. This is where the Node vs Computer parallel object trees come in. I would have an Extension that holds these "persistent mutable" objects in say a Map<String,Connection> Then the Trigger uses that extension to look up connections for items (the key being the item path). The extension would have an item listener to catch renames and deletes (watch your synchronisation there, you will need to use good locking patterns... Ignore the crazy over-use of volatile demonstrated in the jenkins code... Lots of bugs come from how jenkins incorrectly handles multi-threading) The extension would also have a periodic work that walks the map purging (and stopping) and connections for items that no-longer exist IOW the extension is responsible for creating, maintaining, and stopping the connections. The trigger is responsible for linking the items to the connections managed by the extension. HTH > > > 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] <javascript:;>. > 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. > -- Sent from my phone -- 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/CA%2BnPnMzDA_yktSLaC6GkaTiewKqbOu9Qz1cOOtRQ4t_5t6RuaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
