We are working with version 2.2.5.Final in JBoss-6.1.0.Final.
Our appliction requires a durable JMS topic with mutliple durable subscribers connected to it. Our clients occassionally disappear for extended periods, so we are sure to set message expiration parameters on each message we send in order to properly time out the messages.
This all works just fine until we enable paging. Without paging, the messages are automatically expired and removed from consideration once the expiration window has been exceeded - the journal files shrink up nicely in accordance with that. However, we must enable paging as our subscriber count, message load and expiration window could potentially easily overrun the JVM memory size. In such cases, we cannot afford to BLOCK and prevent presently attached subscribers from receiving new messages.
Unfortunately, when we enable PAGE, it appears that messages for presently non-connected subscribers will NOT expire and be removed from the paging directory. They will get expired/removed upon re-connection of ALL of the previously subscribed durable connections. However, we do not control if or when this may happen. An ocassional client may never connect again. This results in appranently boundless growth of paging files on the disk. This would obviously jepordize the entire functionality if the disk partition becomes full.
Is there any way to have those expired messages removed from the paging area so that growth is no longer boundless for potentially abandoned durable subscriptions? Alternatively, is there anyway to combine both a PAGE and DROP policy for this seemingly common scenario to affectively address the same concerns? Is there a better way to handle this situation?
We have configured our address to include PAGEing as follows:
<!--default for catch all-->
<!-- Removed as we do not need to know about expired messages
We also have out connection-factory configured to inlcude:
Our test case is fairly simple:
- Create a JMS topic
- Attach two durable subscribers to the JMS topic
- Attach s single durable producer to the topic that continuously sends durable messages to the topic with an expiration window (30 seconds) and client acknowldegment
- temporarily stop (but not unsubscribe) one of the 2 clients - simulating client failure which we must account for
- As time progresses, the system will begin to page
- As further time progresses and the expiration window has been clearly exceeded, the paging files continue to grow unbounded
- Paging files will not be removed until the client disconnected in #4 is re-attached (but this may never happen)
I would appreciate any and all help with this as it is critical to our needs and seems like it must be a fairly common need.