You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an application that is running for prolonged periods of time (as a system service). This application is linked with ImageMagick and uses it through its API to process images that are supplied on input.
When policy.xml that is used by ImageMagick contains a time limit (e.g. a line like this: <policy domain="resource" name="time" value="240"/>), our application starts failing because ImageMagick reports errors of the time limit being exceeded. This is because the time limit effectively applies to the pixel cache lifetime (meaning the epoch is initialized on the first use of the cache), and the cache remains active while our application is running. Basically, this means that the time limit is incompatible with long-running applications, even if their use of ImageMagick is occasional and each such use does not take much time.
We feel that such a limitation is not obvious from the limit description in the policy.xml file or the documentation and should probably be better documented. It is also not clear whether this limitation is intentional or not, i.e. is the current behavior wrt. long-running processes intended?
Further, we feel that a different kind of limit would be more useful for long-running processes. More specifically, a time limit for a given operation (e.g. loading an image from a source or saving an image to a file) or a group of operations, which is tracked with user-defined points of start and stop (e.g. by calling APIs to denote the start and stop points). Such a time limit would be tracked on per-thread basis, meaning that there may be multiple threads using ImageMagick APIs concurrently, and each thread should be able to identify their groups of operations individually.
This bug asks to clarify whether the current behavior of the time limit is intended. If it is, we ask you to consider an alternative limit that would be more usable in long-running applications, similar to what is described above.
Steps to Reproduce
Configure a time limit in policy.xml.
Have a long-running application that is linked with ImageMagick and occasionally calls it through its API, e.g. to load an image from a file.
Keep that application running and loading images longer than the configured time limit.
Images
No response
The text was updated successfully, but these errors were encountered:
ImageMagick version
6.9.12-97
Operating system
Linux
Operating system, version and so on
Kubuntu 22.04
Description
We have an application that is running for prolonged periods of time (as a system service). This application is linked with ImageMagick and uses it through its API to process images that are supplied on input.
When
policy.xml
that is used by ImageMagick contains a time limit (e.g. a line like this:<policy domain="resource" name="time" value="240"/>
), our application starts failing because ImageMagick reports errors of the time limit being exceeded. This is because the time limit effectively applies to the pixel cache lifetime (meaning the epoch is initialized on the first use of the cache), and the cache remains active while our application is running. Basically, this means that the time limit is incompatible with long-running applications, even if their use of ImageMagick is occasional and each such use does not take much time.We feel that such a limitation is not obvious from the limit description in the
policy.xml
file or the documentation and should probably be better documented. It is also not clear whether this limitation is intentional or not, i.e. is the current behavior wrt. long-running processes intended?Further, we feel that a different kind of limit would be more useful for long-running processes. More specifically, a time limit for a given operation (e.g. loading an image from a source or saving an image to a file) or a group of operations, which is tracked with user-defined points of start and stop (e.g. by calling APIs to denote the start and stop points). Such a time limit would be tracked on per-thread basis, meaning that there may be multiple threads using ImageMagick APIs concurrently, and each thread should be able to identify their groups of operations individually.
This bug asks to clarify whether the current behavior of the time limit is intended. If it is, we ask you to consider an alternative limit that would be more usable in long-running applications, similar to what is described above.
Steps to Reproduce
policy.xml
.Images
No response
The text was updated successfully, but these errors were encountered: