This blog describes the resource and size limits for JMS resources used in the JMS and AS2 adapter, that can be used in Cloud Platform Integration Enterprise Edition. It describes which limits apply and how to monitor them. It also gives some guidance on how to cleanup the resources.
JMS Resource and Size Limits
The connected JMS messaging instance, that is used in asynchronous messaging scenarios using with the JMS or AS2 Adapter has limited resources. The Enterprise License sets a limit on the queues, storage and connections that you can use in the messaging instance.
There are also technical restrictions on the size of the headers and exchange properties that can be stored in the JMS queue.
Resource Limits for CPI Enterprise Edition
In the CPI Enterprise Edition, a dedicated set of resources is available in the JMS instance. Keep this in mind when configuring and running your scenarios.
- Maximum number of queues: 30
- Queue Capacity: 5GB (will increase to 9GB)
- Transactions: 150
- Consumers: 150
- Providers: 150
- Message Volume: 150GB/month
Number of Queues
JMS queues are used by the JMS and AS2 adapter. When the first integration flow that uses a JMS queue is deployed, the queue is created in the messaging broker. The queue can then be used for sending messages into the queue and for consuming messages from the queue.
You can monitor the queues that are available in the broker in the Queue Monitor, in the Manage Storages section in the Operations view.
If you no longer need a specific queue, (for example if the integration flow has been undeployed), you have to delete the queue manually in the Queue Monitor.
If the queue limit has been reached, you can check for unused queues and delete them. For more information about checks for unused queues, see the blog ‘Checks in Queue Monitor’.
The total queue capacity used by all the scenarios can also be monitored in the Queue Monitor. At the top of the screen, you can see how much of the available capacity is being used.
The master view of the monitor shows how this capacity is distributed between the queues. The Size column displays the size of all messages in this queue.
If the capacity used reaches 80% of the total capacity available, the message appears as a yellow warning message. If 100% of the available capacity is used, it appears as a red error message.
If the limit is reached, messages can no longer be processed, so you need to keep an eye on this value. Make sure that there are no messages stuck in queues!
Transactions, Consumers and Providers
To process a message during runtime always a consumer or provider and an open transaction are required. If a message is stored to JMS queue (JMS Receiver channel) a provider is required, for polling a message from JMS queue (JMS sender channel) a consumer is required.
Note, that the status of transactions, consumers and providers is not yet shown in the Queue Monitor UI, but this will be available in one of the next updates. Currently you will see resource shortages only in runtime.
If you run into runtime errors you need to optimize the usage of transactions in consumers and providers. Think about the following technical details:
Consumers: Consumers are created in the JMS broker from JMS sender adapters to consume messages from the JMS queue. For each JMS queue used in a JMS sender channel as many consumers are created as concurrent processes are configured in the JMS sender channel in parameter Number of Concurrent Processes. If several runtime nodes are started in the Cloud Integration cluster those many consumers are created from each runtime node. To reduce the parallel consumers, you can either reduce the number of concurrent processes in the JMS sender channels or reduce the number of runtime nodes started in the cluster.
Providers: Providers are created by the JMS receiver adapter in the JMS broker to store messages in a JMS queue. As many providers are created as messages are send to the JMS queue in parallel. To reduce the parallel providers parallelism of the inbound processing is too high. You need to reduce the number of parallel inbound calls from sender systems sending messages to scenarios using JMS queues.
Transactions: To consistently process messages, JMS transactions are required in the JMS broker to be able to consistently roll back the processing in case of errors. As many transactions are created in the JMS broker as consumers and providers are under processing in parallel.
There are 150 open transactions available in the JMS broker, they can be used for a consumer or for a provider. The transactions are distributed dynamically to providers and consumers. This means, if lots of messages are consumed in parallel in consumers (polling messages form JMS queues via JMS sender channels) most of the transactions will be used for those and the number of available transactions to store message to JMS queues is lower.
If the limit for transactions is reached (if you get a runtime error) you need to reduce the parallelism for the consumers and/or providers (see above).
Size Limits for Messages, Headers, Properties and Attachments
The following size limits apply when saving messages to JMS queues.
- There are no size limits for the payload. The message is split internally when it is put into the queue
- There are no size limits for the attachements. The message and attachment are split internally when put into the queue
- Headers and exchange properties defined in the integration flow before the message is saved to queue must not exceed 4MB for headers and properties together.
Important: As mentioned, there are no hard size limits for payload and attachments, but you need to keep in mind that processing the message in the CPI runtime may limit the possible size of payload and attachments for your scenario. You as scenario developer have to test and restrict the limits your scenario can handle!