5

In our storage configuration we have the following: 

<RemoteSynchronization Queuesize="128" .... />

When publishing, we see the following error:

Did not process cache event because communication queue size 128 was exceeded ([CacheEvent eventType=Invalidate regionPath=/com.tridion.storage.ItemMeta key=93:166339] was dropped).

What factors should we take into account when calculating the queue size? What calculation do people typically use for this? (Other than simply accepting the default, which no doubt is the commonest approach.)

Improve this question

2 Answers 2

Reset to default
3

We are connecting with a JMS (Tibco) from Deployer Extension and the size limit specified for the queue in EMS is called as the queue build up size. This size is in MBs. It means that the EMS will continue to receive messages till the time this limit is not reached.

For example if the publisher (in this case Deployer) keeps sending messages while the subscriber does not receives any messages, the queue will start dropping message based on either LRU or FIFO once the limit of queue build up is reached. The other alternative offered by Tibco as EMS was to stop receiving any message till the time the subscriber picks up the message which means on the publisher side you will see error to send messages.

There is one more attribute which is message build up limit, post which EMS can send alerts but will continue to receive messages.

We also tried connecting with JMS (Tibco) from Deployers directly to remove SPOF of CCS and this Remote Sync Queue Size was the size of the queue (the queue build up size in MBs)

The factors I have used to arrive at 512 MB size was the number of publishes I expected at the max (for which I took a multiplying factor with our rough current max to ensure queue will have no issues in next few years) in a day clubbed with considering worst case scenario that my subscriber is down during the same time. I also considered the size of each message that I send to JMS. The factor also had inputs from the Tibco team for standard size and configuration.

Improve this answer
2

I'd say the answer depends on how you clean your JMS queue. Tridion doesn't do it by itself, which means your JMS provider has to do it (or alternatively be cleaned by a restart often enough).

I'd say that if your publishing peak is 1k items per hour, and your JMS queue has a time to live of an hour, then i'd use something like 2k queue size.

Improve this answer
2
  • Nice. Would queue size be the sum of the sizes of packages (i.e. average package size x average package in the queue)?
    – Alvin Reyes
    Jun 22, 2015 at 17:50
  • Alvin - I think it's more likely to be the number of messages. In this case, they are cache invalidation messages, so they will be more or less the same size as each other.
    – Dominic Cronin
    Jun 22, 2015 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.