Re: Need help designing a fix for JENKINS-50504

There are some tests in `workflow-durable-task-step` which simulate broken connections as well as restarts, so if the issue is indeed reliably reproducible, you could probably do it that way. A test case would certainly be a valuable contribution. I doubt there is a straightforward, localized

Re: Need help designing a fix for JENKINS-50504

I meant "Thanks for pointing out JENKINS-41854" below. On Tuesday, April 10, 2018 at 5:42:20 PM UTC-7, m...@basilcrow.com wrote: > > Thanks for pointing out JENKINS-45294. That is exactly what I am facing, > at least twice a month. It causes severe disruption to my users, so I need > to come up

Re: Need help designing a fix for JENKINS-50504

Thanks for pointing out JENKINS-45294. That is exactly what I am facing, at least twice a month. It causes severe disruption to my users, so I need to come up with a plan. I see that the bug is unassigned. If it isn't fixed soon, I might have to try to fix it myself by necessity. I suppose the

Re: Need help designing a fix for JENKINS-50504

On Wed, Apr 4, 2018 at 4:26 AM, Oleg Nenashev wrote: > WorkspaceList#inUse should be reacquired by Pipeline for sure when it > reconnects to a new agent. I would guess it happens even now (or not?) No, currently a lock is acquired only when a `node` (or `ws`) body is

Re: Need help designing a fix for JENKINS-50504

This issue seems to be Pipeline-specific (actually DueableTask-Specific). Standard Freestyle jobs should abort immediately on the agent disconnection, but Pipeline jobs may recover and continue using the workspace. However, it seems ugly to use the new channel in the "in use" map, because >

Re: Need help designing a fix for JENKINS-50504

Hi Ivan, Thanks for your reply. I'm not exactly sure how my proposed workaround would necessarily cause concurrency issues. Doesn't that depend on how it's implemented? I agree that it's strange that the agent wasn't disconnected and still keeps the old connection to the master, even though