Dynamic policy update problems
There are several reasons why you might experience problems and unexpected behavior when you dynamically update your messaging policies.
Are your subscriptions not being dynamically updated when you update your messaging policy?
If you are using global-shared durable subscriptions, see Are your global-shared durable subscriptions not being dynamically updated when you update your subscription policy?. If your subscriptions are not being dynamically updated, you must ensure that you are updating the topic policy that is associated with the subscription.
You can use the REST API GET method with the URI http://<admin-endpoint-IP:Port>/ima/v1/monitor/Subscription
or the Monitoring page in the Amlen WebUI to determine the topic policy that is associated with the subscription. If the topic policy that is associated with the subscription is not one that you expect, see Dynamic updates to messaging policies for possible reasons why.
Does your subscription sometimes have different values for Max Messages, Max Messages Behavior, and Disconnected client notification?
Your application might be using different messaging policies at different times when it is connecting. See Dynamic updates to messaging policies for possible reasons why.
Does your application sometimes receive a disconnected client notification, and sometimes not?
Your application might be using different messaging policies at different times when it is connecting. See Dynamic updates to messaging policies for possible reasons why.
Have you set or updated MaxMessageTimeToLive on your messaging policy but messages are not expiring as you expect them to?
- MaxMessageTimeToLive must be set on the topic policy that is in use by the producer or publisher when it connected.
- MaxMessageTimeToLive is specified in seconds. Verify that the value that is specified for MaxMessageTimeToLive is correct.
- The MaxMessageTimeToLive value for a message is the value that is specified in the topic policy when the message is sent. If there are already messages in the subscription when you set or updated the value of MaxMessageTimeToLive, these messages might have might have different values than the value currently shown on the topic policy.
- In JMS, does your producer application specify a value for
time-to-live
that is different from the value of MaxMessageTimeToLive on the topic policy? In this situation, the lower of the two values is used.
MaxMessageTimeToLive varies on different connections of your publisher
Are you connecting and using different messaging policies? For more information, see Dynamic updates to messaging policies.
Your consumer is receiving messages after their expiration time
Check the value of the application time-to-live
parameter and the value of MaxMessageTimeToLive on the topic policy. The lower of the two values is used.
- Messages might expire while they are cached on the client of your JMS consumer.
- In JMS, messages might expire while they are in the client message cache of your JMS consumer. By setting clientMessageCache on your JMS receiver and immediately processing messages that are received, you can ensure that fewer expired messages are delivered.