[
https://issues.apache.org/jira/browse/OFBIZ-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justen Walker updated OFBIZ-5710:
---------------------------------
Description:
{{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}} 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 and doesn't contain any relevant data.
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.
was:
{{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}} 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!
h3. Static Start
!static-start.png!
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 and doesn't contain any relevant data.
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.
> 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
> Reporter: Justen Walker
> Labels: jsvc
> Attachments: daemon-start.png, static-start.png
>
>
> {{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}} 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 and doesn't contain any relevant data.
> 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)
