You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@servicecomb.apache.org by "wujimin (JIRA)" <ji...@apache.org> on 2019/02/13 01:56:00 UTC

[jira] [Resolved] (SCB-638) create mechanism for read config item by priority

     [ https://issues.apache.org/jira/browse/SCB-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

wujimin resolved SCB-638.
-------------------------
       Resolution: Done
    Fix Version/s: java-chassis-1.2.0

> create mechanism for read config item by priority 
> --------------------------------------------------
>
>                 Key: SCB-638
>                 URL: https://issues.apache.org/jira/browse/SCB-638
>             Project: Apache ServiceComb
>          Issue Type: Task
>          Components: Java-Chassis
>            Reporter: wujimin
>            Assignee: wujimin
>            Priority: Major
>             Fix For: java-chassis-1.2.0
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> currently, we have so many config item need to read by priority.
> 1.read operation level
> 2.if operation level not exist, then read schema level
> 3.if schema level not exist, then read microservice level
> 4.if microservice level not exist, then read global level  (only for consumer)
>  
> everyone repeated the logic, and try all the level for every invocation
> we can provide a mechanism to handle this logic, eg:
>  
> {code:java}
> class XxxConfig{
>   @Config(prefix="servicecomb.request.time")
>   private int timeout;
> ......
> }
> OperationMeta.extData changed from ConcurrentHashMap to ConcurrentHashMapEx
> XxxConfig config = operationMeta.getExtData().computeIfAbsent("...", k->ConfigFactory.create(operationMeta));
> config.getTimeout()           // this is what we want. all try logic is triggered by config change callback, not run for every invocation.{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)