Change Map config on the fly?

[syg6]

Is it possible to change the TTL, concurrency level, etc., on an
existing Map? In other words, take an already created Map ("myMap"),
change its config, and then call Hazelcast.getMap("myMap") and have it
use the new config?

It doesn't seem to be possible currently. When I call getMap() it just
gives me the same Map with the old config. I've also tried calling
destroy() first but it doesn't seem to do anything ...

Thanks!
Bob

[Talip Ozturk]

You cannot change the config of running map but you can shutdown the
Hazelcast instance and init with the new config. This is quite
expensive so not recommended.
Config config = ...
//change config

Hazelcast.shutdown();
Hazelcast.init(config);


-talip

> --
>
> You received this message because you are subscribed to the Google Groups "Hazelcast" group.
> To post to this group, send email to haze...@googlegroups.com.
> To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/hazelcast?hl=.
>
>
>

[syg6]

Yea, I was hoping you weren't going to say that. :(

Any chance of this becoming a feature?

I had another related question - is there any way you can make certain
elements in a Map have a different TTL from the rest? In other words,
have the Map get its TTL from its config but ALSO have a put() that
accepted TTL?

Thanks!
Bob

[Talip Ozturk]

you mean something like

Object put (key, value, ttl);

right?
-talip

[syg6]

Yea, that would be great!

Currently every time we stick some data in our cache we call
ScheduledThreadPoolExecutor.scheduleAtFixedRate(Runnable,
initialDelay, period, timeUnit), passing it a Runnable Eraser class to
remove the data after a pre-defined amount of time has passed.

Looking at your code you seem to do something similar (I think ...).
Your ServiceThread continually polls to see what data needs to be
removed, based on its TTL. The only difference would be to get the TTL
as a parameter of put() instead of from MapConfig.

Fyi, this is the way Infinispan does it as well ...

Should I add this over in Issues?

Thanks!
Bob

[Talip Ozturk]

> Currently every time we stick some data in our cache we call
> ScheduledThreadPoolExecutor.scheduleAtFixedRate(Runnable,
> initialDelay, period, timeUnit), passing it a Runnable Eraser class to
> remove the data after a pre-defined amount of time has passed.

An Eraser Task per entry is costly. Hazelcast only have one Eraser for
all maps, all entries. It will be a good gain.

> Should I add this over in Issues?

Yes please. Add it as a new feature. This way all comments/updates for
this issue will be auto-emailed to you.

-talip

[syg6]

Ok, I created an issue (179):

http://code.google.com/p/hazelcast/issues/detail?id=179

On Nov 25, 10:36 am, Talip Ozturk <ta...@hazelcast.com> wrote:
> > Currently every time we stick some data in our cache we call
> > ScheduledThreadPoolExecutor.scheduleAtFixedRate(Runnable,
> > initialDelay, period, timeUnit), passing it a Runnable Eraser class to
> > remove the data after a pre-defined amount of time has passed.
>
> An Eraser Task per entry is costly. Hazelcast only have one Eraser for
> all maps, all entries. It will be a good gain.

Yes, I can see it can get quite costly. But if Hazelcast continues to
have only 1 Eraser per Map, how would you implement an Eraser for
elements of a Map that were put() with a different TTL? I am just
curious ...

[Talip Ozturk]

> Yes, I can see it can get quite costly. But if Hazelcast continues to
> have only 1 Eraser per Map, how would you implement an Eraser for
> elements of a Map that were put() with a different TTL? I am just
> curious ...

Hazelcast has 1 Eraser for all maps and it does actually run every
second.. fixed. when it runs it cleans up all entries that are either
marked as removed and/or invalid (timed-out). So actual cleaning
happens with a tiny delay but if you try to get/read timed-out entry
in the meantime, Hazelcast will return you NULL of course.

-talip

[syg6]

Wicked. The way we did it originally doesn't *seem* to go slow at all.
In fact our app is lightening-fast. But I agree that it's a lot of
overhead and your way of doing it is better.

That said, will adding the put() with TTL slow things down? I imagine
that currently what you do for each map is:

1. Get its TTL from MapConfig FOR ALL ELEMENTS IN MAP
2. Iterate over each of the Map's elements
3. Get each one's creationTime
4. If current time - creationTime > TTL ==> remove/evict

But if each element can have a distinct TTL you'll have to do step 1
(get TTL) for each element, not just once for the whole Map.

Will this not slow things down? Or am I wrong about how the code
works? Either way, you know more than I do about how Hazelcast works,
I guess if it's not doable, you won't do it. :)

Cheers,
Bob

[Talip Ozturk]

> That said, will adding the put() with TTL slow things down? I imagine
> that currently what you do for each map is:
>
> 1. Get its TTL from MapConfig FOR ALL ELEMENTS IN MAP
> 2. Iterate over each of the Map's elements
> 3. Get each one's creationTime
> 4. If current time - creationTime > TTL ==> remove/evict
>
> But if each element can have a distinct TTL you'll have to do step 1
> (get TTL) for each element, not just once for the whole Map.
>
> Will this not slow things down?

If you use mapA.put (key, value, ttl, timeunit) then mapA will be
marked as ttlPerRecord = true

so we will have to iterate and evict for the maps with
ttlPerRecord=true, and yes we may slow down a bit but for other maps
no difference at all.

I just committed the implementation. IMap now have:

V put (K key, V value, long ttl, TimeUnit timeunit);

V putIfAbsent (K key, V value, long ttl, TimeUnit timeunit);

You can download the latest snapshot containing these API at
http://code.google.com/p/hazelcast/wiki/Downloads?tm=2

-talip

[syg6]

Awesome, this will make my life a lot easier!

Thanks for implementing it so quickly.

Cheers,
Bob