On 12/04/2014 01:14 PM, Daniel Beck wrote:
Looks a lot like the problem Gerrit Trigger had (has?).

https://issues.jenkins-ci.org/browse/JENKINS-23152

Yes, I saw that bug. And specifically this comment:

> @rsandell as noted in the PR comments, while expanding the calls made to Trigger.stop > from core might fix the bug as produced by Reload Configuration from Disk, other problematic > cases will likely remain—folder moves, etc.—and you will be tracking them all down for a > long time. The root problem is that GerritTrigger and related classes hold references to > AbstractProject yet are used in global static state, which is inherently risky and a design > problem: items are intended by held only from their ItemGroup (ultimately via the Jenkins > singleton). I believe my PR corrects that problem, or at least gives the general idea, but
> the plugin tests would need extensive edits to keep up.

This was back in May, and I can't tell if this change actually would fix my problem - it appears the fix
was to GerritTrigger and not the core so I suspect not.

-- Greg

On 04.12.2014, at 18:20, [email protected] wrote:
I have a plugin that extends the Trigger class. It creates a JMS connection and 
consumes messages from a queue, scheduling a job if a particular message is 
received.

Both the connection and consumer are declared as private, transient variables 
in the class. The connection and consumer are initialized in the start method 
and destroyed in the stop method.

This works fine when the job configuration is updated via the UI.

However, I run into problems 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, which causes me to get a connection exists errors in the start method 
(which does get called).

I've made my start method smart enough to check to see if the private variables 
are non-null. In these cases, however, they are null - but the connection still 
exists. It seems as though an entirely new trigger object has been created 
without destroying the old one, and I can't figure out how to reference the old 
one so I can clean up.

I'm pretty sure I'm missing something basic here, but I don't know what. This 
seems like a problem others would have hit, but I haven't been able to find 
anything similar.

Can anyone help?

Thanks,

-- Greg

--
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/399f4fb0-217b-4d0a-94cf-de8573fb0424%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/5480B1C0.7010309%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to