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