ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Crum (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-5710) Running OFBIZ with jsvc (Commons Daemon) Breaks JobPoller
Date Thu, 14 Aug 2014 06:47:12 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096662#comment-14096662

Adrian Crum commented on OFBIZ-5710:

FYI: The Job Poller code is critical to keep the Job Scheduler reliable. In the past, an arbitrary
thread wait value was used, and in some slower systems it wasn't long enough - so the Job
Scheduler would try to run jobs before the service engine finished loading, causing unpredictable

> Running OFBIZ with jsvc (Commons Daemon) Breaks JobPoller
> ---------------------------------------------------------
>                 Key: OFBIZ-5710
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-5710
>             Project: OFBiz
>          Issue Type: Bug
>          Components: framework
>    Affects Versions: Release Branch 13.07, Trunk
>            Reporter: Justen Walker
>              Labels: jsvc
>         Attachments: daemon-start.png, static-start.png
> h2. Symptoms
> All jobs in JobSandbox are stuck in SERVICE_PENDING even though they should be run.
> h2. Root Cause
> {{org.ofbiz.base.start.Start}} implements a Singleton pattern but Commons Daemon breaks
the singleton contract by instantiating it through reflection.  This means that there are
2 instances of {{Start}} in a running application using {{jsvc}}
> When running a heap dump of an OFBiz server running with {{jsvc}}; I noticed two instances
of {{Start}} are present: *#1* (which was created by {{DaemonLoader}}) and *#2* (created during
static init)
> From the attached screenshots, you can see that the static {{instance}} variable points
to *#2* instead of *#1*.
> h3. Daemon Start
> !daemon-start.png|width=900,height=500!
> h3. Static Start
> !static-start.png|width=900,height=500!
> This is a problem because *#1* actually contains the correct application state, but anyone
using {{Start.getInstance()}} will get *#2* which has not been initialized.  
> At least one service suffering from this is the {{JobPoller}} which has a few lines in
the polling code:
> {code:java}
> while (Start.getInstance().getCurrentState() != Start.ServerState.RUNNING) {
>   Thread.sleep(1000);
> }
> {code}
> Which will never be able to exit - thus all scheduled jobs will never be run.
> I noticed this in 13.07 but it could affect other versions - I have not checked them.

This message was sent by Atlassian JIRA

View raw message