|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
My memory of diagnosing the networking issues for some other issue previously is that it turned out our network was just unreliable. We have already gone to extreme lengths to do stuff about that - we replaced the entire Windows master with a Linux master and moved all the builds across to that, but the issues persist and it appears to be unrelated to which kind of slave is being contacted.
So at the moment, we're assuming it's just the nature of networks being unreliable.
The core problem from our point of view is Jenkins' reaction to this sort of thing.
What should happen:
What actually happens:
The first fallacy of distributed computing is "The network is reliable." Jenkins' behaviour today embraces this fallacy quite strongly and we're basically saying that we think it would be better if it didn't make that sort of assumption. The network is not reliable, and Jenkins is doing a pretty bad job of coping with that.
(As an aside, we also think that Jenkins causing failed builds just because jobs after a "successful" build failed is unreasonable, as it means fingers get pointed as us, when it's simply not us to blame. There should be a different status for "the build system fucked up" so that we don't get prodded via IM every time Jenkins screws something up. I'm sick of getting floods of "you broke the build" and "you fixed the build" notices which are simply not true because the build itself was never broken in the first place.)