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.