Ön a következő verzió súgóját látja::
- 6.4
- 6.3
- 6.2
- Korábbi verziók
AEM forms (and earlier versions) used JMS queues to execute operations asynchronously. In AEM forms, JMS queues have been replaced by Work Manager. This document provides background information on Work Manager, and provides instructions on configuring Work Manager throttling options.
In AEM forms, operations performed by services can be either short-lived (synchronous) or long-lived (asynchronous). Short-lived operations complete synchronously on the same thread from which they were invoked. These operations wait for a response before continuing.
Long-lived operations may span systems or even extend beyond the organization, such as when a client must complete and submit a loan application form as part of a larger solution that integrates multiple automated and human tasks. Such operations must continue while awaiting a response. Long-lived operations perform their underlying work asynchronously, permitting resources to be otherwise engaged while awaiting completion. Unlike a short-lived operation, Work Manager does not consider a long-lived operation complete once it is invoked. An external trigger, such as a system requesting another operation on the same service or a user submitting a form, must occur to complete the operation.
AEM forms (and earlier versions) used JMS queues to execute operations asynchronously. AEM forms uses Work Manager to schedule and execute asynchronous operations via managed threads.
Asynchronous operations are handled in this manner:
-
Work Manager threads pull in work items when the threads become free. Before pulling in the work items, threads can check whether the required services are started, whether there is enough heap size to pull in the next work item, and whether there are enough CPU cycles to process the work item. Work Manager also evaluates attributes of the work item (such as its priority) when scheduling its execution.
AEM forms administrators can use Health Monitor to check Work Manager statistics, such as the number of work items in the queue and their statuses. You can also use Health Monitor to pause, resume, retry, or delete work items. (See View statistics related to Work Manager.)
You can configure throttling for Work Manager, so that work items are scheduled only when there are enough memory resources available. You configure throttling by setting the following JVM options in your application server.
Property |
Description |
|---|---|
| adobe.work-manager.queue-refill-interval | Specifies the time interval, in milliseconds, that Work Manager uses when checking for new items in its queue. The value for this option is an integer. The default value is 1000 milliseconds (1 second). If the volume of asynchronous invocations is low, you can increase this value. For example, you could increase it to somewhere between 2000 and 5000 (2 to 5 seconds). If the volume of asynchronous invocations is high, the default value should be sufficient, but you can use a lower value if necessary. Decreasing this value too much (for example, below 50, which results in a poll frequency of 20 times per second) causes a substantial overhead on the system. |
| adobe.workmanager.debug-mode-enabled | Set this option to true to enable debug mode, or to false to disable it. In debug mode, messages regarding Work Manager policy violations and Work Manager pause/resume actions are logged. Set this option to true only when troubleshooting. |
| adobe.workmanager.memory-control.enabled | Set this option to true to enable throttling based on the memory-control settings described below, or to false to disable throttling. |
| adobe.workmanager.memory-control.high-limit | Specifies the maximum percentage of memory that can be in use before Work Manager throttles incoming jobs. The default value for this option is 95. This value should be fine for most systems. Increase it only if your system needs to push through to its maximum capacity. But note that as you increase this value, the risk of Out of Memory issues also increases. If you are running AEM forms in a clustered environment, you may want to set the memory control limit settings differently on different nodes of the cluster. For example, you could have a lower high-limit on nodes A and B, which are programmed in your load balancer for interactive work. And you could have higher high-limits set on nodes C and D, which are not used by the load balancer, but reserved for asynchronous work. |
| adobe.workmanager.memory-control.low-limit | Specifies the maximum percentage of memory that can be in use before Work Manager stops throttling incoming jobs. The default value for this option is 20. This value should be fine for most systems. |
| Dadobe.workmanager.allocate.max-batch-size | Specifies the maximum batch size for workmanager. The default batch size is 10. If the status of a process in the workmanager is not updated even after the task is complete, then set the batch size to 1. |
A Twitter™ és Facebook közzétételeket a Creative Commons jogi feltételei nem szabályozzák.