Hola, I'll try to explain a little bit more, I just open sourced the plugin and I can show the source code. So to define my problem again. I have a QueueDecisionHandler like this, https://github.com/zeroturnaround/cluster-stats/blob/master/src/main/java/org/zeroturnaround/stats/QueingScheduler.java
There I store all scheduled items into some data structure. Then I have another listener, a RunListener<Run>, like this, https://github.com/zeroturnaround/cluster-stats/blob/master/src/main/java/org/zeroturnaround/stats/StartCompleteListener.java When a Run is completed I try to match it to a previously scheduled item by run.getParent().getDisplayName(). After that I was hoping to have a data structure that holds information [scheduled start, build start, build completed, node name]. And then I show stats based on that, something like this: http://cl.ly/image/2d1W450P333m My local tests show that most of the time my logic holds but I've discovered some bugs when ran in a larger cluster with more plugins enabled * I think that although my QueingScheduler returns true some other scheduler returns false and my Eden space grows unnecessarily * There are cases when retrieving from the Eden space based on the run.getParent().getDisplayName() gives me the wrong result. See previous point why I have some stale data there. So my question * Any better ways how to get [scheduled start, build start, build completed, node name] tuple? * Any better extension points to use? * Any better way how to get these stats? Maybe existent plugin? Cheers, Toomas On Wednesday, March 13, 2013 5:50:28 PM UTC+2, Toomas Römer wrote: > > Hi guys, > > I've been trying to write a Jenkins plugin that gives me statistics about > my Jenkins cluster in terms as which jobs sit in the queue the longest, > which nodes have the longest queues, build duration and little bit more. > > I approached the problem by implementing a QueueDecisionHandler and > remembering Tasks that got queued and then implementing RunListener<Run> > to see when Run's started and completed. > > Today I noticed that my logic is flawed. QueueDecisionHandler is not the > best place to record the start of queuing because if I remember a Task > there some other DescisionHandler my cancel it but I wont' get an event > about it. Another reason is that even if I remember a Task then later on in > RunListener putting together a Run with a Task is very heuristic. > > Any better ideas how to approach this problem? Maybe some other good > extension point that I have not found yet or maybe a premade plugin? :) > > Cheers, > Toomas > -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
