Improve map re-config capabilities

[davidkarlsen]

I define/configure the maps dynamically from a client (using client/server model), but there are two places it could be improved:

• Allow for changing the same parameters programatically which are allowed from the mancenter ui, e.g. TTL, eviction policy etc
• If destroy()'ing and creating the map - it still fails due to configuration mismatch

hazelcastInstance.getMap(CorsAccountServiceImpl.CORS_ACCOUNT_LIST_CACHE).destroy();
// will still fail:
          var corsAccountListCacheConfig = new MapConfig()
              .setTimeToLiveSeconds(60*30)
              //.setMaxSizeConfig(new MaxSizeConfig().setSize(10000))
              .setName(CorsAccountServiceImpl.CORS_ACCOUNT_LIST_CACHE)
              .setEvictionPolicy(EvictionPolicy.LRU);
          hazelcastInstance.getConfig().addMapConfig(corsAccountListCacheConfig );

[burakcelebi]

Hi @davidkarlsen! Thanks for your enhancement request! I'm now monitoring this type of requests closely. I have just reviewed your request with @ahmetmircik. He is going to ask you a few questions to clarify your use case. Stay tuned! :)

[ahmetmircik]

Hi @davidkarlsen,

I agree that re-configuration is a good addition. You can do it for imap from mancenter ui but only for a subset of imap configuration as you already knew.

We will keep this issue open as an enhancement request. Let's see what we can do with it.

Regarding this:

If destroy()'ing and creating the map - it still fails due to configuration mismatch

Destroying map and destroying map-config are two separate things. There can be other maps that uses same config. All dynamic configs are using config-name to identify themselves atm. So you need a new map-config with a new name.

[davidkarlsen]

Yeah - I know we can click around in the mancenter - but we want a CI/CD driven workflow with few or no buttons to click - so we get a separation of concerns between hz ops and app ops