Currently there are max-size-bytes and global-max-size-bytes that trigger the blocking policy. These are based on memory usage for cached messages, they don't cover paged messages on an address.

If a user wants to resource constrain an address, whether the messages are paged or not is orthogonal to the limit. 

Having max-size-bytes encompass both paged an in-memory messages for an address seems intuitive.

Having max-size-in-memory configure the limits for paging (the current behaviour) may make sense.

That could also make page-cache-max-size obsolete, use max-size-in-memory.

naming is hard and there is an argument for adding new config rather than changing the meaning of an existing value. However in this case, the current configuration item, max-size-bytes could easily be inferred to be a limit, independent of paging. Paging is really an implementation detail from the outside. 

The requirement is to be able to limit the resources allocated to an address. If you have a "small" address, there is only so much you can backlog there. 

comments welcome!