Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Roberto Cortez
    @radcortez
    what would happen if I resolve a property first to a dynamic source (so it can change over time), but later on it gets resolved to a fixed source? in that case my initial dynamic config it not dynamic anymore?
    Jan Bernitt
    @jbee
    if a property is resolved to a dynamic source it is not cachable
    end of story
    David M. Lloyd
    @dmlloyd
    is that aspect actually effectively different from what is there today?
    Roberto Cortez
    @radcortez
    well not end of the story
    David M. Lloyd
    @dmlloyd
    non-dynamic config sources are already generally fast
    backed by maps mostly, so effectively already cached
    Roberto Cortez
    @radcortez
    because they dynamic config may be invoked multiple times
    Jan Bernitt
    @jbee
    you still have to go through sources each time currently
    Roberto Cortez
    @radcortez
    so what if I remove the config name in that dynamic config source that make my name to now be resolved by a non dynamic config source?
    Jan Bernitt
    @jbee
    that can go away with the proposed change
    then it is bound to that non dynamic source forever
    David M. Lloyd
    @dmlloyd
    not all sources, just the ones that are higher priority than the one which defines the property
    Jan Bernitt
    @jbee
    which still might be some
    we have about 10-20
    it depends
    Roberto Cortez
    @radcortez
    as for profiles, I see this more being associated to the actual config than the config source
    Jan Bernitt
    @jbee
    the issue here is that this is a operation done very often - even things that usually would not be considered as "much work" start to become noticeable
    Roberto Cortez
    @radcortez
    it might be more interesting to state that a particular config name is or not dynamic or cacheable
    Jan Bernitt
    @jbee
    that would help already
    David M. Lloyd
    @dmlloyd
    or that certain config sources are restricted to certain namespaces
    (to avoid cataloging large numbers of config keys)
    Jan Bernitt
    @jbee
    would also help
    Roberto Cortez
    @radcortez
    in the end you just care about the key, not the config source. the issue with the config source is that is just an overlaying buckets of data, so it is hard to implement behaviour on top to make it consistent across all buckets
    Jan Bernitt
    @jbee
    as I say: narrow semantics
    Roberto Cortez
    @radcortez
    the config itself is where we have more control
    David M. Lloyd
    @dmlloyd
    we care about the config source to the extent that it may be slow
    only specific config sources are problematic, theoretically
    therefore it makes sense to wrap only specific config sources in these cases, so they only respond to keys which they are able to contain
    Jan Bernitt
    @jbee
    and the overall "having to check many sources each time"
    David M. Lloyd
    @dmlloyd
    that shouldn't be a problem in theory; the individual config sources' efficiencies would dominate the operation
    if you have 10 map-backed config sources, it's a constant number of constant-time lookups
    Jan Bernitt
    @jbee
    in theory
    David M. Lloyd
    @dmlloyd
    once you hit (for example) a database, that's when things may get expensive
    Jan Bernitt
    @jbee
    you cannot think like that here
    David M. Lloyd
    @dmlloyd
    is the problem not computational cost per operation?
    Jan Bernitt
    @jbee
    say you use MP metrics to probe the time of a fairly simple operation - some ms - with 20 map lookups on top because of MP config the probe becomes the thing dominating the time making the feature useless
    David M. Lloyd
    @dmlloyd
    I would first argue that this is not an MP config problem, since MP config specifically and explicitly trades away maximum run time performance in favor of flexibility
    and tells you specifically not to do the thing that MP metrics is apparently doing
    that's already a spec feature today :)
    but again, at least two different existent spec features allow for this problem to be mitigated despite that
    Jan Bernitt
    @jbee
    again, we can patch out of any situation and in worse case decide to simply be non compliant but it would be nice to address the source instead
    David M. Lloyd
    @dmlloyd
    the source of the problem IMO is that the specification originally went for flexibility over performance
    and everything is built off of that assumption
    the upside is that you can use that flexibility to gain back performance
    providing a config source interceptor (using the proposed spec mechanism) is not in any way "patching it out", but using a spec feature for its designed purpose
    and I suspect it will solve your issue perfectly
    Jan Bernitt
    @jbee
    it gives me new issues TBH - anyhow, I think you know and understand the issue I have and I'll see if the future brings any solutions
    Emily Jiang
    @Emily-Jiang
    @jbee Thanks for bringing up the issues! MP Config did not offer the caching. In Open Liberty, we does caching ourselves for the known static config sources. As for the custom config sources, they should cache the config value. As you know, the map of getProperties are not fully populated as the backed config sources might be huge e.g. database. I think Payara prefers getValue() to return the value for the specified config property anyway. Feel free to raise an issue so that we can discuss further for a better solution!
    Jan Bernitt
    @jbee
    :+1: