Skip to content

Support adding config while creating a new DMap #169

Description

@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?

Activity

  1. self-assigned this
    on Jun 28, 2022
  2. buraksezer commented on Jul 12, 2022

    @buraksezer
    Collaborator

    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.

  3. derekperkins commented on Dec 20, 2022

    @derekperkins
    Contributor

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

  4. buraksezer commented on Dec 27, 2022

    @buraksezer
    Collaborator

    @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

  5. derekperkins commented on Dec 28, 2022

    @derekperkins
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

ConfigurationReleated with Olric configurationenhancementNew feature or request

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions