Support adding config while creating a new DMap

[hasit]

Currently, as I see it, there is no way to pass config while creating a new DMap. That is, db.NewDMap(name string) uses the config specified while creating a new Olric instance or from map of custom DMap config.

For my usecase, I want to able to pass config at the DMap level instead of at Olric instance level like so:

...
dmapConfig := config.DMap{
	TTLDuration: ttl,
...
}

db.NewDmap(name, dmapConfig)
...

Am I missing something here? Is this something I could help add?

[buraksezer]

I'm so sorry for my late response. I considered this previously but I was doubtful about the feature. Olric is a shared-nothing system. Configuration inconsistencies between nodes and API calls may lead to subtle bugs.

I usually follow Hazelcast to get inspired. It seems that the guys at Hazelcast don't allow setting/overriding IMap configuration in a running cluster. It's a part of the overall Hazelcast configuration.

Here is some doc:

1. https://docs.hazelcast.com/hazelcast/5.1/data-structures/map-config
2. https://docs.hazelcast.com/imdg/4.2/data-structures/map

I like the idea of declaring DMap configuration at the time of initialization, but it can be dangerous. What do you think?

By the way, I wonder how you use Olric in your environment. What is your use case? Does it fix the problems? I would like to hear more if you can publicly talk about it.

[derekperkins]

To clarify, any changes to DMaps.Custom after calling olric.New, even if it's before calling NewDMap, doesn't do anything?

[buraksezer]

@derekperkins Currently, updating the configuration of a running Olric instance isn't possible by design but you can modify DMaps struct before calling NewDMap. The resulting DMap instance should reflect the new configuration. Unfortunately, this is not a feature. It's a design (or implementation) problem. I believe users shouldn't exploit this defect.

Currently, updating the configuration may lead to subtle bugs even if we deliberately build that feature because there is no golden source of truth in Olric's design. It's a loosely-coupled, shared-nothing system. Configuration differences may lead to undefined behaviors.

See this: https://github.com/buraksezer/olric/blob/master/internal/dmap/dmap.go#L96

[derekperkins]

Like the original poster, my intent is not to change the configuration of a running cluster, it's just moving where that configuration happens from an api perspective. In our case, we are instantiating olric.New in main.go, then passing the embedded client into the service as a dependency, and inside the service call NewDMap for as many as are required, and choosing options like max memory at that point.