bzr xmllog process continues even when build is stopped.

[Craig Hewetson]

To reproduce:
Start a build for a large project.
Make sure that the change log is very large and that bzr-hudson is configured to fetch the entire history.
While the entire history is being fetched (bzr xmllog), cancel the build using hudson's "red x" next to the build progress bar.

Open the OS's process monitor and note the bzr is running at almost 100%. (of a single cpu). This will continue like this until it finishes or the user manually kill's this process.

Expected behaviour:
The bzr xmllog should stop when the build is stopped.

Recommended solution:
Listen to the cancel event from hudson and stop the logTask.
Besides the above, an extra solution should be in place for other component's using bzr-java-lib or bzr-xmloutput (not sure which of the two are responsible.)
The bzr xmllog process should ping or poll its parent every N seconds to determine whether or not is should continue with its operation. This would be useful since the process spawning (parent) bzr xmllog might die unexpectedly and cause it to run unnecessarily.

[Guillermo Gonzalez (verterok)]

Craig,
Thanks for poiting this out.
This is an issue in bzr-java-lib, that it's reflected as this weird behaviour in bzr-hudson.
The main issue is that the xmllog command is executed in the xmlprc service, so the request keeps executing in the server.
I think the xmlrpc service in bzr-xmloutput should handle this, but the current implementation just delegated to the bzr command so it block and can't do much about it.
So, as temporary workaround I propose to handle this in bzr-java-lib, from the top of my head, two options to fix this:
 1) get the changelog in chunks using IBazaarClient.log
 2) change bzr-hudson to use a "custom" version of IBazaarClient.logAsync instead of IBazaarClient.loginterrupt

I think 2) is the easiest way to get things going, this imply some code duplication if it's implemented in bzr-hudson but we could add a variant of IBazaarClient.logAsync in bzr-java-lib that returns the List of Future's instead of waiting for the execution ofo each runnable to avoid code duplication.

Let me know what you think.

Regards,

[Craig Hewetson (craighewetson-deactivatedaccount)]

I've got a feeling that bzr-hudson will not be the only project to benefit
from this.

Is it possible to send a request to the xmlrpc service to interrupt the bzr
command? ctrl+c etc

Also do you know how one can hook into the "cancel build" event in hudson?

[Craig Hewetson (craighewetson-deactivatedaccount)]

I might have an easier solution.
Why not startup a server for each build and kill it after the build has completed, cancelled or failed.

Got from test code in bzr-xmloutput:
        response = self.client.quit() // this method
        self.thread.join()

One might have to think of what would have to be done for simultaneous builds. Don't know what would happen if there are multiple servers running. Maybe the server can only get killed if there are no other bazaar "enabled" build's running when it gets cancelled, completed or failed. Therefore maintaining a single instance of the xmlrpc server

[Guillermo Gonzalez (verterok)]

Hi,
Yes. that might work, but as you mention if you have two builds with the same xmlrpc server port, the one that finish first will stop the server.
Maybe we could just use the command line client instead of the xmlrpc client (and server) from bzr-java-lib, it's a bit slower (due to proccess startup) but should be fine for the bzr-hudson use case.