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)