Couple of things we ran into with our current customer who’s using UM 9.7.
The maximum size of a message that UM can handle is controlled by the Connection Config> MaxBufferSize property. I believe this is an environment property and not configurable down to the queue/topic level. Something else to be aware of… in the event a message larger than the MaxBufferSize is published, UM drops the message and does not throw an exception to the IS. In fact, the IS connection to UM is actually temporarily dropped as well. This is a known “feature” for any UM version prior to 9.10 and is well documented on Empower: KB Article - 1772248. With version 9.10+, there’s a property called MaxBufferSizeClientSideCheck which controls the behavior when the message exceeds the MaxBufferSize.
Regarding fml2’s comment: "There should be no limit on how large a queue can get, just the disc space (since messages are held in files). " This is not entirely true. With version 9.7 we saw some odd behavior and performance issues regarding the .mem files associated with a queue stored here: UniversalMessaging\UniversalMessaging\server\umserver\data\namedsubqueues. In our scenario we had multiple publishers (native pub/sub - not JMS) of the same doctype and multiple triggers using “Provider Filters”. The trigger filters were mutually exclusive so one publish would fire only one trigger. What we noticed over time was that UM performance would degrade in relationship with the volume flowing through these integrations. Upon further inspection we discovered that when a trigger filter was NOT satisfied, a copy of the message was kept inside of the .mem file. Similar to a dead-letter queue. Furthermore, as these .mem files grew, OOM errors became more and more frequent. After consulting with SAG support, it was determined that the .mem files are in fact loaded into memory when provider-side filtering was used, and there is no built-in mechanism to purge these files. Again this was 9.7 native pub/sub. The only solution we were left with was to move to client-side filtering on the IS, which prevents the .mem files from growing.