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
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
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
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
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
>
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