-
1. Re: Behavior with selector and fullSize cache
gaohoward May 26, 2009 9:43 AM (in response to mclu)Hi,
Using fullSize you can limit the max number of messages in memory of a queue. If the queue's messages (not delivered) reaches fullSize, any more messages that are routed to the queue will be 'paged' to DB. As messages in memory are delivered, more messages are 'fetched' from the DB into memory for delivery.
So if you have 120 messages in queue while the fullSize is 100, 20 messages will be paged to DB.
You also need to notice that once Bridge X is deployed, it will always create a consumer X even the target X is not reachable for the moment. -
2. Re: Behavior with selector and fullSize cache
mclu May 27, 2009 4:13 AM (in response to mclu)Hi !
Thx for explanation. But this basics I know already.
I did the test with a limit of 50 and added a lot of messages for x y and z to my queue. I also undeployed all bridges.
Then I deploy bridge x. All messages in the memory which contains the header property destination=x are bridged then. Some messages are reloaded but after a short time the memory queue contains only messages for y and z. The messages which are paged to db for x are NOT delivered.
If I then deploy Bridge Y some messages of Y and (because of reload) some X are bridged. Then the Queue stopped again because only Z messages are in the memory queue.
If I deploy Z the queue is completely bridged to all destinations.
This behaviour of course makes sense! Paged messages are somehow invisible for the JMS system.
But I think there should be a section in the bridge documentation (user guide) or somewhere else which points to this behaviour. Otherwise users maybe wonder why the queue "stops".
I my case I think I have to create onle queue per destination. Otherwise I can not prevent memory problems if one or more destinations are not reachable. -
3. Re: Behavior with selector and fullSize cache
timfox May 27, 2009 5:03 AM (in response to mclu)Yes selectors do not work well with paged messages.
To implement it otherwise would be difficult - we'd have to scan the entire file store for matching messages every time a consumer is added.
If you find yourself needing functionality like this, then it sounds like you need a database not a messaging system!
Databases are designed to do exactly this kind of thing: Large tables of data which can't all fit in memory and "select" subsets of rows matching a criteria.
Messaging systems support this kind of functionality to some extent, but it is not their primary purpose!