[WFLY-4133] Hanging EJB threads because of a persistent timer and failed deployment #7006
Conversation
deployment TimerServiceImpl gets a new state (active). This avoids getting stuck during failed deployments when the TimerService starts before the EJBComponent, causing an unrecoverable lock in BasicComponent.waitForComponentStart
|
Can one of the admins verify this patch? |
| @@ -539,6 +540,9 @@ public synchronized void start() { | |||
| if (this.controlPoint != null) { | |||
| this.controlPoint.resume(); | |||
| } | |||
| if(this.timerService instanceof TimerServiceImpl) { | |||
There was a problem hiding this comment.
Probably better to change the type of the field timerService from TimerService to TimerServiceImpl.
There was a problem hiding this comment.
Sometimes it will be a NonFunctionalTimerService if the EJB has no timeout methods.
|
This is ok to test |
|
Linux Build 5586 is now running using a merge of bfef1c3 |
|
Linux Build 5586 outcome was SUCCESS using a merge of bfef1c3 |
|
I added the ee-review label, because I'm merging a bunch of PRs but don't plan to deal with this one; needs a +1 from someone more familiar with the ee details. |
stuartwdouglas
added
ready-for-merge
|
retest this please |
|
Linux Build 5660 is now running using a merge of bfef1c3 |
|
Linux Build 5660 outcome was SUCCESS using a merge of bfef1c3 |
[WFLY-4133] Hanging EJB threads because of a persistent timer and failed deployment
BZ 6.x https://bugzilla.redhat.com/show_bug.cgi?id=1147948
JIRA upstream: https://issues.jboss.org/browse/WFLY-4133
TimerServiceImpl gets a new state (active). This avoids getting stuck
during failed deployments when the TimerService starts before the
EJBComponent, causing an unrecoverable lock in
BasicComponent.waitForComponentStart