[JIRA] (JENKINS-50260) lock step interacts badly with timeout step

2020-02-13 Thread tomas.bjerr...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Tomas Bjerre commented on  JENKINS-50260  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: lock step interacts badly with timeout step   
 

  
 
 
 
 

 
 I tried using: Build Timeout Plugin 1.19 Lockable Resource Plugin 2.8-SNAPSHOT And with pipeline:   

 

lock('myresource') {
 println "locked"
 timeout(time: 2, unit: 'SECONDS') {
  println "sleep..."
  sleep 10
  println "sleep done !!"
 }
 println "leaving timeout"
}
println "after lock"
timeout(time: 2, unit: 'SECONDS') {
 println "locking..."
 lock('myresource') {
  println "locked, sleeping..."
  sleep 10
  println "sleep done !!"
 }
 println "left lock"
}
println "left timeout"
 

 The log shows:     

 

Started by user unknown or anonymous
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] lock
Trying to acquire lock on [myresource]
Resource [myresource] did not exist. Created.
Lock acquired on [myresource]
[Pipeline] {
[Pipeline] echo
locked
[Pipeline] timeout
Timeout set to expire in 2 sec
[Pipeline] {
[Pipeline] echo
sleep...
[Pipeline] sleep
Sleeping for 10 sec
Cancelling nested steps due to timeout
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
Lock released on resource [myresource]
[Pipeline] // lock
[Pipeline] End of Pipeline
Timeout has been exceeded
Finished: ABORTED
 

     Would help if anyone can reproduce it with a sample pipeline and plugin versions.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

  

[JIRA] (JENKINS-50260) lock step interacts badly with timeout step

2019-07-17 Thread tobias.getr...@web.de (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Tobias Getrost commented on  JENKINS-50260  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: lock step interacts badly with timeout step   
 

  
 
 
 
 

 
 It looks as if the timeout is the reason why the lock is not released. I created a test to reproduce the behaviour: https://github.com/getrostt/lockable-resources-plugin/tree/jenkins-50260  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.189292.1521479252000.13597.1563347220392%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-50260) lock step interacts badly with timeout step

2018-04-12 Thread andrew.ba...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Andrew Bayer updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-50260  
 
 
  lock step interacts badly with timeout step   
 

  
 
 
 
 

 
Change By: 
 Andrew Bayer  
 
 
Component/s: 
 workflow-basic-steps-plugin  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-50260) lock step interacts badly with timeout step

2018-03-19 Thread jacob.kel...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Jacob Keller commented on  JENKINS-50260  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: lock step interacts badly with timeout step   
 

  
 
 
 
 

 
   This is with Lockable Resource Plugin 2.0 I'm not 100% sure if the issue is a timeout() killing the lock() or not. I looked at the pipeline graph, and I see a timeout set to 15 minutes and the lock is blocked for 13 minutes, so it's possible this isn't the issue. I also had 2 other branches of parallel pipeline that ended up blocking for 4 days before we killed the job. Specifically, the lock is only used inside a single build to limit parallelism of a section that cannot be run concurrently during a parallel{} chunk. Since the lockable resource name includes the BUILD_TAG, it should be a resource unique to the individual build, and thus the only places it should become locked are in other parallel threads. Any other ideas what might cause the deadlock?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-50260) lock step interacts badly with timeout step

2018-03-19 Thread jacob.kel...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Jacob Keller created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-50260  
 
 
  lock step interacts badly with timeout step   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 lockable-resources-plugin, workflow-basic-steps-plugin  
 
 
Created: 
 2018-03-19 17:07  
 
 
Priority: 
  Blocker  
 
 
Reporter: 
 Jacob Keller  
 

  
 
 
 
 

 
 I have a job which takes a lock {} inside of a timeout {} block. If the timeout expires, then the lock {} is not freed, which results in future taking of the lock becoming a deadlock. It seems like timeout {} should properly free the lock when forcing an exit from the lock() step? Is this just a bad pipeline/workflow pattern?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment