|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
Hello Robert,
This issue is quite painful for our users, so I would like to fix it. This issue has been reproduced at the latest plugin version (Jenkins version – 1.480.3, java version "1.7.0_19", OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) and several previous versions as well.
According to the stacktraces, P4 hangs at BufferedReader::readLine(), which is infinitely waits for new line or EOF. I suppose that P4 command-line client finishes before call of readLine() or somehow enters interactive mode and waits till user’s input. However, I can’t reproduce issue at my testing stand with slaves with debugger. Restart of the slave fixes the problem.
There are 84 BufferedReader::readLine() calls in p4 plugin, so we can’t just fix getPerforceResponse() function.
Possible solutions:
• We can add something like timeouts to the checkout() and other top-level overrides. BTW, it’s just a workaround for operative notification, because only restart can fix issue’s origin.
• Add timeout to the getPerforceResponse() only and wait for other errors (yeah, just fix the known issue)
• Replace BufferedReaders by wrapper, which knows how to handle issue.
I’m going to implement second approach. It will be possible to configure timeout via perforce global configuration.
Best regards,
Oleg Nenashev
R&D Engineer, Synopsys Inc.
www.synopsys.com