Hide Forgot
Document URL: http://documentation-devel.engineering.redhat.com/site/documentation/en-US/Red_Hat_JBoss_BRMS/6.2/html/User_Guide/ Section Number and Name: 10.3. Realtime Decision Server Setup Describe the issue: Decision server startup behaviour changed in 6.3.0.ER2 [1]. Now kie-server.war deployment doesn't complete until the server successfully connects to its controller. It may be necessary to turn this deployment synchronization off in case both kie-server and business-central are deployed to the same application server. In such scenario kie-server will block server startup and so business-central (controller) won't become available and kie-server won't complete its deployment, creating a deadlock. Suggestions for improvement: 1) org.kie.server.sync.deploy property should be included in "Table 10.1. Realtime Decision Server Bootstrap Switches" at least for being complete, 2) a note/warning may be added, explaining the necessity to turn deployment synchronization off in the scenario with business-central and kie-server running in the same container (@mswiderski to confirm this, please). Additional information:
[1] https://issues.jboss.org/browse/JBPM-5022
the idea with this sync deployment is that it will not start the kie server when running in managed mode as it might cause race condition for example timer nodes can be triggered before containers are loaded which can lead to several attempts being made and then marking timer as failed - this means process won't move forward anymore. Expectation from application servers are that deployments are done concurrently, If that's not the case sync deployment then should be disabled by default.
I observed the deployment deadlock on all supported containers (although I would appreciate another pair of eyes to confirm this, at least on EAP) so it will hit any user trying the single container scenario. Those would welcome having the sync deployment turned off by default. On the other hand, users that deploy kie-server to a different container than business-central may hit the failing timer nodes unless they turn the sync deployment on. Hard to say what is worse.
I'd say since timer nodes issue is jBPM only and this is just one of three major extensions I'd vote for having it disabled by default and then documented.
There is a couple of other bootstrap switches that were added recently and not included in documentation: org.jbpm.ui.server.ext.disabled org.optaplanner.server.ext.disabled org.kie.server.persistence.schema org.kie.server.controller.token Each deserves at least a brief description. The documentation text is missing in community, too, so you may need developers' help. You can take a look at this blame view [1] to see committers of the 4 properties. [1] https://github.com/droolsjbpm/droolsjbpm-integration/blame/def5e3ded2024cbd721cf8a7e2de820ed51ca851/kie-server-parent/kie-server-api/src/main/java/org/kie/server/api/KieServerConstants.java
I changed the default value for the property to be false so it does not affect all users and allows to have workbench and kie server on same server. So when it comes to overall documentation of this property: org.kie.server.sync.deploy - instructs kie server at deploy time to hold the deployment until it collects configuration (most important containers to be deployed) from the controller. Main reason is that it should not allow any requests (both http or from within container such as timers) until containers are fully deployed. This affects kie servers running in managed mode (with controller) only. Possible values for this property are: - false - to use async way of connecting to controller - meaning application starts and in background it connects to controller and once successful will deploy containers - already accepting requests before containers are available - this is the default setting - true - runs in sync mode that holds deploy of the kie server application by joining controller connection thread with main deployment thread and awaits its completion. This can lead to potential hangs or deadlock in case more applications are on same server instance. So recommendation is when using this property set to true to use only single app (kie server) on that server instance. @Jiri, does this explain it good enough?
Thanks Maciej, that looks perfect!