Currently we have hazelcast.xml like this:
In our case we are putting many objects to MessageStatesLog queue, which is MapStore'd in the database.
JMX-console definitely shows me invalid size of this queue - it is never decreases, only increases. Also i see correct counters for backed map - q:MessageStatesLog -it's size is increases and decreases during load.
This issue is a real problem for usage closely with "max-size-per-jvm" property - if queue size goes to this, then all next 'puts/offers' is never be done.
We need some kind of "black hole" functionality - queue with MapStore, max-size-per-jvm and TTL specified. I expect that all objects that was putted will be sent to MapStore and Queue and backing-map will forget about them.
Maybe this case is not trivial, but i don't see any limitations to this from the documentation.
Hazelcast version is 2.1 (02.05.2012), OS Windows Server 2008 R2
I could not understand the actual problem here;
Do you mean
We have a Queue with backing-map. In backing-map we have 5 seconds TTL and MapStore.
I expect that items will be removed from the Queue and backing-map after 5 seconds.
Currently in JMX stats for queue i didn't see that - queue size is only increasing.
Maps have dedicated cleanup threads periodically cleaning invalid/expired/removed entries. But queues do not have, expired items are removed from queue during poll/take operations. (Queue items are just long keys, actual data are stored in map.)
Do you poll/take from this queue ever?
Maybe it's possible to remove from queue on server-side when item is expiring on the backing-map and we know that this map has an queue 'owner'?
As i said in issue description - i'm trying to create some kind of 'black hole', so there is no component doing poll/take for this 'black hole' queue.
Sure, some enhancements can be done. But continuously adding items without polling/taking is not a common use case for a queue.
I don't think this works for Map either. We have a map backed by persistence with TTL. I see that the item is not removed from persistence storage after the TTL. Worse is that when I call get() on the map, hazelcast doesn't have it but it loads from the persistence storage so the effect of TTL became void essentially.
If TTL is suppposed to work with persistnce storage also, then its a bug.
TTL causes item to be evicted. Evictions don't trigger map-store.
Only explicit remove call make item to be removed from map-store.
Can you try with version 3? Reopen the issue if needed.