Re: [JIRA] Commented: (CC-1010) being able to build a set of projects from inside a project

Antoine Levy-Lambert <[email protected]> Fri, 25 Feb 2011 17:47:44 -0500
Newsgroups gmane.comp.java.cruise-control.devel
Message-ID <[email protected]>
Hello Dan,

I am coming back to a relatively old thread because I got a "push" at work.

We are building a series of projects with a fork of CruiseControl 2.8.4 
where we have restored some APIs as described in CC-1010 in order to be 
able to have a builder build children projects without JMX.
In fact we are not invoking "build()" but "execute()" on the 
ProjectInterface class so that if the source controls find no change on 
a child project this child project does not get built.

There are two pain points :
- one is that it is not desirable to remain on a fork of CruiseControl
- another, the most immediate is that sometimes the same label gets 
generated twice - this happens often for one child project which takes a 
long time to build, not sure whether there is a relation. I never found 
out whether the non incrementation of the label was caused by the 
project building in two different threads or by something else.

Another symptom of "wrong behavior" is that the data concerning the 
children projects in the JMX console is not refreshed. What I see in the 
JMX console is the state of the child project as per the last time 
CruiseControl was restarted. If I stop CruiseControl, the .ser files of 
the children projects are persisted and when it restarts CruiseControl 
remembers the proper build numbers ... So it looks like the memory of 
CruiseControl is split between a JMX world and the world of the API 
invocation of the subprojects. What is causing this "split mind" 
syndrome ? Maybe just one method call would resolve the issue.

Best regards,

Antoine

On 12/20/2010 6:40 AM, Dan Rollo (JIRA) wrote:
>      [ http://jira.public.thoughtworks.org/browse/CC-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_18982 ]
>
> Dan Rollo commented on CC-1010:
> -------------------------------
>
> Re: JMX calls generating native threads - I think we have that issue fixed (it had to do with not closing connections...).
>
> My concern about having builders invoke other project builds is it is not safe. By that I mean, the JMX approach does not violate the current guarantee that a given project will NEVER be building in two different threads at the same time.
How does the JMX approach guarantee that the same project will not be 
building in two different threads ? Maybe this can be used also without 
JMX ?
> Even if you force a build, the current scheduling ensures a project will only be building one one thread. For example: What will happen if the "child" project you wish to build is already building?
>
> I realize the JMX approach "heavy", but maybe there is some other way to get the "child" project queued safely?
I would be interested to find another way to get the "child" project 
queued safely. Can you suggest an approach ?

Regards,

Antoine


------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev