[
https://issues.apache.org/jira/browse/OFBIZ-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14096751#comment-14096751
]
Adrian Crum commented on OFBIZ-5710:
------------------------------------
Thanks Jacopo. I wasn't clear on the operation of Commons Daemon, but now I
understand. Patch has been updated.
I know the methods added to Start.java to get it to work with Commons Daemon
are necessary, but they break the singleton design pattern. From my experience,
if you give developers the ability to create more than one instance, they will.
> 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: R13_Start.java.patch, 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
(v6.2#6252)
