Question about ownership of Gerrit Trigger for Jenkins

Will Saxon

unread,

Jun 30, 2016, 11:34:14 AM6/30/16

to Repo and Gerrit Discussion

Hello,

We're trying to determine the best place to post questions, etc. related to the Gerrit trigger plugin for Jenkins. The plugin seems to be officially maintained by Cloudbees, but there's a pretty extensive issue list that only sporadically seems to get input from Cloudbees people.

It looks like the trigger plugin was written by Sony/Ericsson and I know several people from there are on this list - is discussion of the plugin appropriate here?

Thanks,

-Will

Luca Milanesio

unread,

Jun 30, 2016, 11:45:06 AM6/30/16

to Will Saxon, Repo and Gerrit Discussion

Nope, you should write to the Jenkins Users mailing list:

https://jenkins.io/content/mailing-lists/

Luca.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Will Saxon

unread,

Jun 30, 2016, 1:56:25 PM6/30/16

to Repo and Gerrit Discussion, sax...@gmail.com

OK. I posted last month and got zero replies. I will try again.

Will Saxon

unread,

Jul 8, 2016, 4:43:10 PM7/8/16

to Repo and Gerrit Discussion, sax...@gmail.com

We think we've tracked this down to some unexpected (by us) behavior with the replication plugin.

We have one replication remote where we set remote.NAME.replicationDelay to 0. It looks like this setting is also used as the reschedule delay in situations where a replication has to be rescheduled due to in-flight push (see replication/Destination.java 114-115, 380). The result is that the event can be rescheduled hundreds of times per second; we observed up to 11 reschedule operations per millisecond for a single replication on our system.

The other thing we noticed is that every time a replication is rescheduled, a ref-replicated failure event is emitted to stream-events. We're not 100% sure what the trigger is doing with replication events, but heap dumps show a correlation between high cpu usage and a data structure with tens or hundreds of thousands of those ref-replicated events. We later observed cpu usage spike right along with a ref-replicated event storm.

We're going to change the replicationDelay to 1s for this remote and we expect this will mostly resolve the problem.