| Summary: | Document usage of org.kie.server.sync.deploy property | ||
|---|---|---|---|
| Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Jiri Locker <jlocker> |
| Component: | Documentation | Assignee: | Dawn Eisner <deisner> |
| Status: | CLOSED EOL | QA Contact: | Lukáš Petrovický <lpetrovi> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3.0 | CC: | brms-docs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-27 20:11:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jiri Locker
2016-04-05 14:48:16 UTC
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! |