[DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-07 Thread jun liu 
Hi, All

I’ve just posted some blogs[4] on Github issues relating to the design 
principles and implementations of V2.7.0,  the content are based mainly on my 
own understanding of the 2.7.0 codebase (hosted on branch dev-metadata[1]) and 
the previous discussions[2][3].

Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on 
metadata refactoring, I am happy to see that v2.7.0 is on a right direction to 
meet community requirements and keeps evolving. The main changes or features 
already included in v2.7.0 branch are:

* Config Center: Zookeeper, Apollo, Nacos
* Externalized Configuration
* Service governance enhancement: dynamic configuration & routing rule
* Repackage to 'org.apache.dubbo'
* Java 8 support
* Async programming support

Most of the features above have been mentioned or discussed on the mailing list 
or Github issues days or months ago. But during the design and coding process, 
more details come up that need to be further discussed and decided. The design 
principles and implementations on v2.7.0 branch now are far from the the final 
decision, they may be not the best choice or even turn to be unreasonable, so 
you can think them as a prototype implementation provided for your reference. 
Now, we need to know your opinions on v2.7.0, please help to review the designs 
and codes, whenever you have better ideas or suggestions, please don’t hesitate 
to let the community know.

FYI: If you want to know more implementation details and try to read the codes 
or commits directly, you may find it hard to follow, because there’re too much 
file changes in there. So I would suggest you read the summaries I wrote in the 
blogs first and then dive into the code related to the part you interest one by 
one.

1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
2. https://github.com/apache/incubator-dubbo/issues/2030
3. https://github.com/apache/incubator-dubbo/issues/2341
4. https://github.com/apache/incubator-dubbo/issues/2919

Jun

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-13 Thread victory 
All of this features are the biggest concert in the community.
I have some questions：
1.中心化配置的优先级
2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
3.Tag路由改造了，和原来的兼容性怎么样？
4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
--
1. Prioritization of centralized configuration
2. The logic of the route is more complicated, and the compatibility with
the original low version is guaranteed.
3.Tag routing has been modified, how is the compatibility with the original?
4. How does the Environment clear responsibility? It is best to have an
independent description.


jun liu  于2018年12月7日周五 下午8:11写道：

> Hi, All
>
> I’ve just posted some blogs[4] on Github issues relating to the design
> principles and implementations of V2.7.0,  the content are based mainly on
> my own understanding of the 2.7.0 codebase (hosted on branch
> dev-metadata[1]) and the previous discussions[2][3].
>
> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
> to meet community requirements and keeps evolving. The main changes or
> features already included in v2.7.0 branch are:
>
> * Config Center: Zookeeper, Apollo, Nacos
> * Externalized Configuration
> * Service governance enhancement: dynamic configuration & routing rule
> * Repackage to 'org.apache.dubbo'
> * Java 8 support
> * Async programming support
>
> Most of the features above have been mentioned or discussed on the mailing
> list or Github issues days or months ago. But during the design and coding
> process, more details come up that need to be further discussed and
> decided. The design principles and implementations on v2.7.0 branch now are
> far from the the final decision, they may be not the best choice or even
> turn to be unreasonable, so you can think them as a prototype
> implementation provided for your reference. Now, we need to know your
> opinions on v2.7.0, please help to review the designs and codes, whenever
> you have better ideas or suggestions, please don’t hesitate to let the
> community know.
>
> FYI: If you want to know more implementation details and try to read the
> codes or commits directly, you may find it hard to follow, because there’re
> too much file changes in there. So I would suggest you read the summaries I
> wrote in the blogs first and then dive into the code related to the part
> you interest one by one.
>
> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
> 2. https://github.com/apache/incubator-dubbo/issues/2030
> 3. https://github.com/apache/incubator-dubbo/issues/2341
> 4. https://github.com/apache/incubator-dubbo/issues/2919
>
> Jun
>
>

-- 

Best Regard!
cvitory

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-20 Thread jun liu 
> 1. Prioritization of centralized configuration

Now, the centralized configuration or externalized configuration is implemented 
to has the highest priority by default. For flexible concerns, a switch is 
designed and opened to users so that they can override the default value, for 
example, you can use the following JVM property to give centralized 
configuration a lower priority than the local one: 
dubbo.configCenter.highestPriority=false.

> 2. The logic of the route is more complicated, and the compatibility with
> the original low version is guaranteed.

When saying of complexity, I guess you mainly refer to the routing module, 
because this module is one of the most evident parts that has changed in this 
version and is also newly introduced. Its main purpose is to improve the 
performance of the runtime. After all, there will be some performance loss when 
routing is executed for address filtering every time an RPC is executed. 
However, I agree we should be really careful about this cache part since it 
works as an crucial path on the RPC wire. Some possible drawbacks I can come up 
with it now are: excessive resource usage, priority guarantee of routers in 
chain, etc. I think we can discuss more about the technical details of this 
part, give it more test and then decide whether to release it this time or wait 
until it’s mature enough.

> 3.Tag routing has been modified, how is the compatibility with the original?

It has full backward compatibility with the original implementation with only 
the supporting of of DynamicConfiguration added.

> 4. How does the Environment clear responsibility? It is best to have an
> independent description.

Sorry, I don’t understand this one. Basically, you can think Environment as the 
counterpart of that in Spring. I agree we should add a document describing the 
design purpose and how to use it.

Jun

> On Dec 14, 2018, at 12:26 PM, victory  wrote:
> 
> All of this features are the biggest concert in the community.
> I have some questions：
> 1.中心化配置的优先级
> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> 3.Tag路由改造了，和原来的兼容性怎么样？
> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> --
> 1. Prioritization of centralized configuration
> 2. The logic of the route is more complicated, and the compatibility with
> the original low version is guaranteed.
> 3.Tag routing has been modified, how is the compatibility with the original?
> 4. How does the Environment clear responsibility? It is best to have an
> independent description.
> 
> 
> jun liu  于2018年12月7日周五 下午8:11写道：
> 
>> Hi, All
>> 
>> I’ve just posted some blogs[4] on Github issues relating to the design
>> principles and implementations of V2.7.0,  the content are based mainly on
>> my own understanding of the 2.7.0 codebase (hosted on branch
>> dev-metadata[1]) and the previous discussions[2][3].
>> 
>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
>> to meet community requirements and keeps evolving. The main changes or
>> features already included in v2.7.0 branch are:
>> 
>> * Config Center: Zookeeper, Apollo, Nacos
>> * Externalized Configuration
>> * Service governance enhancement: dynamic configuration & routing rule
>> * Repackage to 'org.apache.dubbo'
>> * Java 8 support
>> * Async programming support
>> 
>> Most of the features above have been mentioned or discussed on the mailing
>> list or Github issues days or months ago. But during the design and coding
>> process, more details come up that need to be further discussed and
>> decided. The design principles and implementations on v2.7.0 branch now are
>> far from the the final decision, they may be not the best choice or even
>> turn to be unreasonable, so you can think them as a prototype
>> implementation provided for your reference. Now, we need to know your
>> opinions on v2.7.0, please help to review the designs and codes, whenever
>> you have better ideas or suggestions, please don’t hesitate to let the
>> community know.
>> 
>> FYI: If you want to know more implementation details and try to read the
>> codes or commits directly, you may find it hard to follow, because there’re
>> too much file changes in there. So I would suggest you read the summaries I
>> wrote in the blogs first and then dive into the code related to the part
>> you interest one by one.
>> 
>> 1. https://github.com/apache/incubator-dubbo/tree/dev-metadata
>> 2. https://github.com/apache/incubator-dubbo/issues/2030
>> 3. https://github.com/apache/incubator-dubbo/issues/2341
>> 4. https://github.com/apache/incubator-dubbo/issues/2919
>> 
>> Jun
>> 
>> 
> 
> -- 
> 
> Best Regard!
> cvitory

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-20 Thread jun liu 
Two more things to mention:

1. I am thinking of merge this dev-metadata branch back to the master. Both 
these two branches have the same version 2.7.0-SNAPSHOT and they together 
consist of v2.7’s release candidates. While they are evolving at the same time 
concurrently, conflicts keep happening. I have been kept merging the master 
branch to dev-metadata to try to avoid conflicts to the most extend during the 
development of dev-metadata. Now, since the changes in dev-metadata are stable 
enough, at least it won’t be a block for the development in master (which is 
also the biggest concern why we created this new branch), I think it’s time for 
us to merge the changes back and work on the unified master branch.

2. Is there any plan for the release of OPS? Most of the new features 
introduced in v2.7 are service governance related abilities and most users have 
get used to using Dubbo OPS to do interoperability with their Dubbo services. 
Thus I think it would be great if an OPS version supporting these features can 
be released at the same time as v2.7 or slightly after it .
@Minxuan @Majinkai, I know you guys are working on OPS project, any news to 
update?

Jun

> On Dec 21, 2018, at 10:35 AM, jun liu  wrote:
> 
>> 1. Prioritization of centralized configuration
> 
> Now, the centralized configuration or externalized configuration is 
> implemented to has the highest priority by default. For flexible concerns, a 
> switch is designed and opened to users so that they can override the default 
> value, for example, you can use the following JVM property to give 
> centralized configuration a lower priority than the local one: 
> dubbo.configCenter.highestPriority=false.
> 
>> 2. The logic of the route is more complicated, and the compatibility with
>> the original low version is guaranteed.
> 
> When saying of complexity, I guess you mainly refer to the routing module, 
> because this module is one of the most evident parts that has changed in this 
> version and is also newly introduced. Its main purpose is to improve the 
> performance of the runtime. After all, there will be some performance loss 
> when routing is executed for address filtering every time an RPC is executed. 
> However, I agree we should be really careful about this cache part since it 
> works as an crucial path on the RPC wire. Some possible drawbacks I can come 
> up with it now are: excessive resource usage, priority guarantee of routers 
> in chain, etc. I think we can discuss more about the technical details of 
> this part, give it more test and then decide whether to release it this time 
> or wait until it’s mature enough.
> 
>> 3.Tag routing has been modified, how is the compatibility with the original?
> 
> It has full backward compatibility with the original implementation with only 
> the supporting of of DynamicConfiguration added.
> 
>> 4. How does the Environment clear responsibility? It is best to have an
>> independent description.
> 
> Sorry, I don’t understand this one. Basically, you can think Environment as 
> the counterpart of that in Spring. I agree we should add a document 
> describing the design purpose and how to use it.
> 
> Jun
> 
>> On Dec 14, 2018, at 12:26 PM, victory > > wrote:
>> 
>> All of this features are the biggest concert in the community.
>> I have some questions：
>> 1.中心化配置的优先级
>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>> 3.Tag路由改造了，和原来的兼容性怎么样？
>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>> --
>> 1. Prioritization of centralized configuration
>> 2. The logic of the route is more complicated, and the compatibility with
>> the original low version is guaranteed.
>> 3.Tag routing has been modified, how is the compatibility with the original?
>> 4. How does the Environment clear responsibility? It is best to have an
>> independent description.
>> 
>> 
>> jun liu mailto:ken.lj...@gmail.com>> 于2018年12月7日周五 
>> 下午8:11写道：
>> 
>>> Hi, All
>>> 
>>> I’ve just posted some blogs[4] on Github issues relating to the design
>>> principles and implementations of V2.7.0,  the content are based mainly on
>>> my own understanding of the 2.7.0 codebase (hosted on branch
>>> dev-metadata[1]) and the previous discussions[2][3].
>>> 
>>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
>>> metadata refactoring, I am happy to see that v2.7.0 is on a right direction
>>> to meet community requirements and keeps evolving. The main changes or
>>> features already included in v2.7.0 branch are:
>>> 
>>> * Config Center: Zookeeper, Apollo, Nacos
>>> * Externalized Configuration
>>> * Service governance enhancement: dynamic configuration & routing rule
>>> * Repackage to 'org.apache.dubbo'
>>> * Java 8 support
>>> * Async programming support
>>> 
>>> Most of the features above have been mentioned or discussed on the mailing
>>> list or Github issues days or months ago. But during the design and coding
>>> process, more details come up that need to be further discussed and
>>

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-20 Thread Minxuan Zhuang 
Dubbo OPS is about to release the first version, it supports service
governance features in Dubbo2.7, including tag route, application scope
rules, metadata report, etc. I've deployed a demo here:
http://47.91.207.147/#/service.
the code locates here:
https://github.com/apache/incubator-dubbo-ops/tree/metadata, and I'll merge
it to develop branch later.

On Fri, Dec 21, 2018 at 11:37 AM jun liu  wrote:

> Two more things to mention:
>
> 1. I am thinking of merge this dev-metadata branch back to the master.
> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> together consist of v2.7’s release candidates. While they are evolving at
> the same time concurrently, conflicts keep happening. I have been kept
> merging the master branch to dev-metadata to try to avoid conflicts to the
> most extend during the development of dev-metadata. Now, since the changes
> in dev-metadata are stable enough, at least it won’t be a block for the
> development in master (which is also the biggest concern why we created
> this new branch), I think it’s time for us to merge the changes back and
> work on the unified master branch.
>
> 2. Is there any plan for the release of OPS? Most of the new features
> introduced in v2.7 are service governance related abilities and most users
> have get used to using Dubbo OPS to do interoperability with their Dubbo
> services. Thus I think it would be great if an OPS version supporting these
> features can be released at the same time as v2.7 or slightly after it .
> @Minxuan @Majinkai, I know you guys are working on OPS project, any news
> to update?
>
> Jun
>
> > On Dec 21, 2018, at 10:35 AM, jun liu  wrote:
> >
> >> 1. Prioritization of centralized configuration
> >
> > Now, the centralized configuration or externalized configuration is
> implemented to has the highest priority by default. For flexible concerns,
> a switch is designed and opened to users so that they can override the
> default value, for example, you can use the following JVM property to give
> centralized configuration a lower priority than the local one:
> dubbo.configCenter.highestPriority=false.
> >
> >> 2. The logic of the route is more complicated, and the compatibility
> with
> >> the original low version is guaranteed.
> >
> > When saying of complexity, I guess you mainly refer to the routing
> module, because this module is one of the most evident parts that has
> changed in this version and is also newly introduced. Its main purpose is
> to improve the performance of the runtime. After all, there will be some
> performance loss when routing is executed for address filtering every time
> an RPC is executed.
> > However, I agree we should be really careful about this cache part since
> it works as an crucial path on the RPC wire. Some possible drawbacks I can
> come up with it now are: excessive resource usage, priority guarantee of
> routers in chain, etc. I think we can discuss more about the technical
> details of this part, give it more test and then decide whether to release
> it this time or wait until it’s mature enough.
> >
> >> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >
> > It has full backward compatibility with the original implementation with
> only the supporting of of DynamicConfiguration added.
> >
> >> 4. How does the Environment clear responsibility? It is best to have an
> >> independent description.
> >
> > Sorry, I don’t understand this one. Basically, you can think Environment
> as the counterpart of that in Spring. I agree we should add a document
> describing the design purpose and how to use it.
> >
> > Jun
> >
> >> On Dec 14, 2018, at 12:26 PM, victory  shenglic...@gmail.com>> wrote:
> >>
> >> All of this features are the biggest concert in the community.
> >> I have some questions：
> >> 1.中心化配置的优先级
> >> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >> 3.Tag路由改造了，和原来的兼容性怎么样？
> >> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >> --
> >> 1. Prioritization of centralized configuration
> >> 2. The logic of the route is more complicated, and the compatibility
> with
> >> the original low version is guaranteed.
> >> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >> 4. How does the Environment clear responsibility? It is best to have an
> >> independent description.
> >>
> >>
> >> jun liu mailto:ken.lj...@gmail.com>>
> 于2018年12月7日周五 下午8:11写道：
> >>
> >>> Hi, All
> >>>
> >>> I’ve just posted some blogs[4] on Github issues relating to the design
> >>> principles and implementations of V2.7.0,  the content are based
> mainly on
> >>> my own understanding of the 2.7.0 codebase (hosted on branch
> >>> dev-metadata[1]) and the previous discussions[2][3].
> >>>
> >>> Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
> >>> metadata refactoring, I am happy to see that v2.7.0 is on a right
> direction
> >>> to meet community requirements and keeps evolving. The main changes or
> >>> features already include

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread jun liu 
> Dubbo OPS is about to release the first version, it supports service
> governance features in Dubbo2.7, including tag route, application scope
> rules, metadata report, etc. I've deployed a demo here:
> http://47.91.207.147/#/service .

Great! 
I have tried and encountered some problems when adding and updating governance 
rules yesterday, I will report Github issues later.

Jun

> On Dec 21, 2018, at 3:08 PM, Minxuan Zhuang  wrote:
> 
> Dubbo OPS is about to release the first version, it supports service
> governance features in Dubbo2.7, including tag route, application scope
> rules, metadata report, etc. I've deployed a demo here:
> http://47.91.207.147/#/service .
> the code locates here:
> https://github.com/apache/incubator-dubbo-ops/tree/metadata 
> , and I'll merge
> it to develop branch later.
> 
> On Fri, Dec 21, 2018 at 11:37 AM jun liu  > wrote:
> 
>> Two more things to mention:
>> 
>> 1. I am thinking of merge this dev-metadata branch back to the master.
>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>> together consist of v2.7’s release candidates. While they are evolving at
>> the same time concurrently, conflicts keep happening. I have been kept
>> merging the master branch to dev-metadata to try to avoid conflicts to the
>> most extend during the development of dev-metadata. Now, since the changes
>> in dev-metadata are stable enough, at least it won’t be a block for the
>> development in master (which is also the biggest concern why we created
>> this new branch), I think it’s time for us to merge the changes back and
>> work on the unified master branch.
>> 
>> 2. Is there any plan for the release of OPS? Most of the new features
>> introduced in v2.7 are service governance related abilities and most users
>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>> services. Thus I think it would be great if an OPS version supporting these
>> features can be released at the same time as v2.7 or slightly after it .
>> @Minxuan @Majinkai, I know you guys are working on OPS project, any news
>> to update?
>> 
>> Jun
>> 
>>> On Dec 21, 2018, at 10:35 AM, jun liu  wrote:
>>> 
 1. Prioritization of centralized configuration
>>> 
>>> Now, the centralized configuration or externalized configuration is
>> implemented to has the highest priority by default. For flexible concerns,
>> a switch is designed and opened to users so that they can override the
>> default value, for example, you can use the following JVM property to give
>> centralized configuration a lower priority than the local one:
>> dubbo.configCenter.highestPriority=false.
>>> 
 2. The logic of the route is more complicated, and the compatibility
>> with
 the original low version is guaranteed.
>>> 
>>> When saying of complexity, I guess you mainly refer to the routing
>> module, because this module is one of the most evident parts that has
>> changed in this version and is also newly introduced. Its main purpose is
>> to improve the performance of the runtime. After all, there will be some
>> performance loss when routing is executed for address filtering every time
>> an RPC is executed.
>>> However, I agree we should be really careful about this cache part since
>> it works as an crucial path on the RPC wire. Some possible drawbacks I can
>> come up with it now are: excessive resource usage, priority guarantee of
>> routers in chain, etc. I think we can discuss more about the technical
>> details of this part, give it more test and then decide whether to release
>> it this time or wait until it’s mature enough.
>>> 
 3.Tag routing has been modified, how is the compatibility with the
>> original?
>>> 
>>> It has full backward compatibility with the original implementation with
>> only the supporting of of DynamicConfiguration added.
>>> 
 4. How does the Environment clear responsibility? It is best to have an
 independent description.
>>> 
>>> Sorry, I don’t understand this one. Basically, you can think Environment
>> as the counterpart of that in Spring. I agree we should add a document
>> describing the design purpose and how to use it.
>>> 
>>> Jun
>>> 
 On Dec 14, 2018, at 12:26 PM, victory >>>  > shenglic...@gmail.com >> wrote:
 
 All of this features are the biggest concert in the community.
 I have some questions：
 1.中心化配置的优先级
 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
 3.Tag路由改造了，和原来的兼容性怎么样？
 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
 --
 1. Prioritization of centralized configuration
 2. The logic of the route is more complicated, and the compatibility
>> with
 the original low version is guaranteed.
 3.Tag routing has been modified, how is the compatibility with the
>> original?
 4. How does the E

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread jun liu 
Hi, All

I have just merged dev-metadata branch into master, from now on, the master 
branch will work as the develop and release codebase of v2.7.0. Branch 
dev-metadata does not need to be kept anymore, I will delete dev-metadata later 
today if there’re no more PRs come to it.

Jun

> On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
> 
> Two more things to mention:
> 
> 1. I am thinking of merge this dev-metadata branch back to the master. Both 
> these two branches have the same version 2.7.0-SNAPSHOT and they together 
> consist of v2.7’s release candidates. While they are evolving at the same 
> time concurrently, conflicts keep happening. I have been kept merging the 
> master branch to dev-metadata to try to avoid conflicts to the most extend 
> during the development of dev-metadata. Now, since the changes in 
> dev-metadata are stable enough, at least it won’t be a block for the 
> development in master (which is also the biggest concern why we created this 
> new branch), I think it’s time for us to merge the changes back and work on 
> the unified master branch.
> 
> 2. Is there any plan for the release of OPS? Most of the new features 
> introduced in v2.7 are service governance related abilities and most users 
> have get used to using Dubbo OPS to do interoperability with their Dubbo 
> services. Thus I think it would be great if an OPS version supporting these 
> features can be released at the same time as v2.7 or slightly after it .
> @Minxuan @Majinkai, I know you guys are working on OPS project, any news to 
> update?
> 
> Jun
> 
>> On Dec 21, 2018, at 10:35 AM, jun liu > > wrote:
>> 
>>> 1. Prioritization of centralized configuration
>> 
>> Now, the centralized configuration or externalized configuration is 
>> implemented to has the highest priority by default. For flexible concerns, a 
>> switch is designed and opened to users so that they can override the default 
>> value, for example, you can use the following JVM property to give 
>> centralized configuration a lower priority than the local one: 
>> dubbo.configCenter.highestPriority=false.
>> 
>>> 2. The logic of the route is more complicated, and the compatibility with
>>> the original low version is guaranteed.
>> 
>> When saying of complexity, I guess you mainly refer to the routing module, 
>> because this module is one of the most evident parts that has changed in 
>> this version and is also newly introduced. Its main purpose is to improve 
>> the performance of the runtime. After all, there will be some performance 
>> loss when routing is executed for address filtering every time an RPC is 
>> executed. 
>> However, I agree we should be really careful about this cache part since it 
>> works as an crucial path on the RPC wire. Some possible drawbacks I can come 
>> up with it now are: excessive resource usage, priority guarantee of routers 
>> in chain, etc. I think we can discuss more about the technical details of 
>> this part, give it more test and then decide whether to release it this time 
>> or wait until it’s mature enough.
>> 
>>> 3.Tag routing has been modified, how is the compatibility with the original?
>> 
>> It has full backward compatibility with the original implementation with 
>> only the supporting of of DynamicConfiguration added.
>> 
>>> 4. How does the Environment clear responsibility? It is best to have an
>>> independent description.
>> 
>> Sorry, I don’t understand this one. Basically, you can think Environment as 
>> the counterpart of that in Spring. I agree we should add a document 
>> describing the design purpose and how to use it.
>> 
>> Jun
>> 
>>> On Dec 14, 2018, at 12:26 PM, victory >> > wrote:
>>> 
>>> All of this features are the biggest concert in the community.
>>> I have some questions：
>>> 1.中心化配置的优先级
>>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>>> 3.Tag路由改造了，和原来的兼容性怎么样？
>>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>>> --
>>> 1. Prioritization of centralized configuration
>>> 2. The logic of the route is more complicated, and the compatibility with
>>> the original low version is guaranteed.
>>> 3.Tag routing has been modified, how is the compatibility with the original?
>>> 4. How does the Environment clear responsibility? It is best to have an
>>> independent description.
>>> 
>>> 
>>> jun liu mailto:ken.lj...@gmail.com>> 于2018年12月7日周五 
>>> 下午8:11写道：
>>> 
 Hi, All
 
 I’ve just posted some blogs[4] on Github issues relating to the design
 principles and implementations of V2.7.0,  the content are based mainly on
 my own understanding of the 2.7.0 codebase (hosted on branch
 dev-metadata[1]) and the previous discussions[2][3].
 
 Recently, I spent plenty of my spare times on 2.7.0, mainly focusing on
 metadata refactoring, I am happy to see that v2.7.0 is on a right direction
 to meet community requirements and keeps evolving. The main changes or
 features already included in v2.7.0 branch

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread Xin Wang 
>I have just merged dev-metadata branch into master, from now on, the
master branch will work as the develop and release codebase of v2.7.0.
Branch dev-metadata does not need to be kept anymore, I will delete
dev-metadata later today if there’re no more PRs come to it.

Great work, looking forward to the new features!

jun liu  于2018年12月24日周一 下午4:33写道：

> Hi, All
>
> I have just merged dev-metadata branch into master, from now on, the
> master branch will work as the develop and release codebase of v2.7.0.
> Branch dev-metadata does not need to be kept anymore, I will delete
> dev-metadata later today if there’re no more PRs come to it.
>
> Jun
>
> > On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
> >
> > Two more things to mention:
> >
> > 1. I am thinking of merge this dev-metadata branch back to the master.
> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> together consist of v2.7’s release candidates. While they are evolving at
> the same time concurrently, conflicts keep happening. I have been kept
> merging the master branch to dev-metadata to try to avoid conflicts to the
> most extend during the development of dev-metadata. Now, since the changes
> in dev-metadata are stable enough, at least it won’t be a block for the
> development in master (which is also the biggest concern why we created
> this new branch), I think it’s time for us to merge the changes back and
> work on the unified master branch.
> >
> > 2. Is there any plan for the release of OPS? Most of the new features
> introduced in v2.7 are service governance related abilities and most users
> have get used to using Dubbo OPS to do interoperability with their Dubbo
> services. Thus I think it would be great if an OPS version supporting these
> features can be released at the same time as v2.7 or slightly after it .
> > @Minxuan @Majinkai, I know you guys are working on OPS project, any news
> to update?
> >
> > Jun
> >
> >> On Dec 21, 2018, at 10:35 AM, jun liu  ken.lj...@gmail.com>> wrote:
> >>
> >>> 1. Prioritization of centralized configuration
> >>
> >> Now, the centralized configuration or externalized configuration is
> implemented to has the highest priority by default. For flexible concerns,
> a switch is designed and opened to users so that they can override the
> default value, for example, you can use the following JVM property to give
> centralized configuration a lower priority than the local one:
> dubbo.configCenter.highestPriority=false.
> >>
> >>> 2. The logic of the route is more complicated, and the compatibility
> with
> >>> the original low version is guaranteed.
> >>
> >> When saying of complexity, I guess you mainly refer to the routing
> module, because this module is one of the most evident parts that has
> changed in this version and is also newly introduced. Its main purpose is
> to improve the performance of the runtime. After all, there will be some
> performance loss when routing is executed for address filtering every time
> an RPC is executed.
> >> However, I agree we should be really careful about this cache part
> since it works as an crucial path on the RPC wire. Some possible drawbacks
> I can come up with it now are: excessive resource usage, priority guarantee
> of routers in chain, etc. I think we can discuss more about the technical
> details of this part, give it more test and then decide whether to release
> it this time or wait until it’s mature enough.
> >>
> >>> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >>
> >> It has full backward compatibility with the original implementation
> with only the supporting of of DynamicConfiguration added.
> >>
> >>> 4. How does the Environment clear responsibility? It is best to have an
> >>> independent description.
> >>
> >> Sorry, I don’t understand this one. Basically, you can think
> Environment as the counterpart of that in Spring. I agree we should add a
> document describing the design purpose and how to use it.
> >>
> >> Jun
> >>
> >>> On Dec 14, 2018, at 12:26 PM, victory  shenglic...@gmail.com>> wrote:
> >>>
> >>> All of this features are the biggest concert in the community.
> >>> I have some questions：
> >>> 1.中心化配置的优先级
> >>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
> >>> 3.Tag路由改造了，和原来的兼容性怎么样？
> >>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
> >>> --
> >>> 1. Prioritization of centralized configuration
> >>> 2. The logic of the route is more complicated, and the compatibility
> with
> >>> the original low version is guaranteed.
> >>> 3.Tag routing has been modified, how is the compatibility with the
> original?
> >>> 4. How does the Environment clear responsibility? It is best to have an
> >>> independent description.
> >>>
> >>>
> >>> jun liu mailto:ken.lj...@gmail.com>>
> 于2018年12月7日周五 下午8:11写道：
> >>>
>  Hi, All
> 
>  I’ve just posted some blogs[4] on Github issues relating to the design
>  principles and implementations of V2.7.0,  the content are based
> mainly on
>  my own

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread Xin Wang 
hi, Jun

Now the travis ci of master branch faile， I create an issue
https://github.com/apache/incubator-dubbo/issues/3052
Please take a look at it

Xin Wang  于2018年12月24日周一 下午4:38写道：

> >I have just merged dev-metadata branch into master, from now on, the
> master branch will work as the develop and release codebase of v2.7.0.
> Branch dev-metadata does not need to be kept anymore, I will delete
> dev-metadata later today if there’re no more PRs come to it.
>
> Great work, looking forward to the new features!
>
> jun liu  于2018年12月24日周一 下午4:33写道：
>
>> Hi, All
>>
>> I have just merged dev-metadata branch into master, from now on, the
>> master branch will work as the develop and release codebase of v2.7.0.
>> Branch dev-metadata does not need to be kept anymore, I will delete
>> dev-metadata later today if there’re no more PRs come to it.
>>
>> Jun
>>
>> > On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
>> >
>> > Two more things to mention:
>> >
>> > 1. I am thinking of merge this dev-metadata branch back to the master.
>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>> together consist of v2.7’s release candidates. While they are evolving at
>> the same time concurrently, conflicts keep happening. I have been kept
>> merging the master branch to dev-metadata to try to avoid conflicts to the
>> most extend during the development of dev-metadata. Now, since the changes
>> in dev-metadata are stable enough, at least it won’t be a block for the
>> development in master (which is also the biggest concern why we created
>> this new branch), I think it’s time for us to merge the changes back and
>> work on the unified master branch.
>> >
>> > 2. Is there any plan for the release of OPS? Most of the new features
>> introduced in v2.7 are service governance related abilities and most users
>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>> services. Thus I think it would be great if an OPS version supporting these
>> features can be released at the same time as v2.7 or slightly after it .
>> > @Minxuan @Majinkai, I know you guys are working on OPS project, any
>> news to update?
>> >
>> > Jun
>> >
>> >> On Dec 21, 2018, at 10:35 AM, jun liu > ken.lj...@gmail.com>> wrote:
>> >>
>> >>> 1. Prioritization of centralized configuration
>> >>
>> >> Now, the centralized configuration or externalized configuration is
>> implemented to has the highest priority by default. For flexible concerns,
>> a switch is designed and opened to users so that they can override the
>> default value, for example, you can use the following JVM property to give
>> centralized configuration a lower priority than the local one:
>> dubbo.configCenter.highestPriority=false.
>> >>
>> >>> 2. The logic of the route is more complicated, and the compatibility
>> with
>> >>> the original low version is guaranteed.
>> >>
>> >> When saying of complexity, I guess you mainly refer to the routing
>> module, because this module is one of the most evident parts that has
>> changed in this version and is also newly introduced. Its main purpose is
>> to improve the performance of the runtime. After all, there will be some
>> performance loss when routing is executed for address filtering every time
>> an RPC is executed.
>> >> However, I agree we should be really careful about this cache part
>> since it works as an crucial path on the RPC wire. Some possible drawbacks
>> I can come up with it now are: excessive resource usage, priority guarantee
>> of routers in chain, etc. I think we can discuss more about the technical
>> details of this part, give it more test and then decide whether to release
>> it this time or wait until it’s mature enough.
>> >>
>> >>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>> >>
>> >> It has full backward compatibility with the original implementation
>> with only the supporting of of DynamicConfiguration added.
>> >>
>> >>> 4. How does the Environment clear responsibility? It is best to have
>> an
>> >>> independent description.
>> >>
>> >> Sorry, I don’t understand this one. Basically, you can think
>> Environment as the counterpart of that in Spring. I agree we should add a
>> document describing the design purpose and how to use it.
>> >>
>> >> Jun
>> >>
>> >>> On Dec 14, 2018, at 12:26 PM, victory > shenglic...@gmail.com>> wrote:
>> >>>
>> >>> All of this features are the biggest concert in the community.
>> >>> I have some questions：
>> >>> 1.中心化配置的优先级
>> >>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>> >>> 3.Tag路由改造了，和原来的兼容性怎么样？
>> >>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>> >>> --
>> >>> 1. Prioritization of centralized configuration
>> >>> 2. The logic of the route is more complicated, and the compatibility
>> with
>> >>> the original low version is guaranteed.
>> >>> 3.Tag routing has been modified, how is the compatibility with the
>> original?
>> >>> 4. How does the Environment clear responsibility? It is best to have
>> an
>> >>> indepen

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread jun liu 
> Now the travis ci of master branch faile， I create an issue
> https://github.com/apache/incubator-dubbo/issues/3052
> Please take a look at it

Thanks, I noticed too, I’ll take care of it.

Jun

> On Dec 24, 2018, at 5:25 PM, Xin Wang  wrote:
> 
> hi, Jun
> 
> Now the travis ci of master branch faile， I create an issue
> https://github.com/apache/incubator-dubbo/issues/3052
> Please take a look at it
> 
> Xin Wang  于2018年12月24日周一 下午4:38写道：
> 
>>> I have just merged dev-metadata branch into master, from now on, the
>> master branch will work as the develop and release codebase of v2.7.0.
>> Branch dev-metadata does not need to be kept anymore, I will delete
>> dev-metadata later today if there’re no more PRs come to it.
>> 
>> Great work, looking forward to the new features!
>> 
>> jun liu  于2018年12月24日周一 下午4:33写道：
>> 
>>> Hi, All
>>> 
>>> I have just merged dev-metadata branch into master, from now on, the
>>> master branch will work as the develop and release codebase of v2.7.0.
>>> Branch dev-metadata does not need to be kept anymore, I will delete
>>> dev-metadata later today if there’re no more PRs come to it.
>>> 
>>> Jun
>>> 
 On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
 
 Two more things to mention:
 
 1. I am thinking of merge this dev-metadata branch back to the master.
>>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
>>> together consist of v2.7’s release candidates. While they are evolving at
>>> the same time concurrently, conflicts keep happening. I have been kept
>>> merging the master branch to dev-metadata to try to avoid conflicts to the
>>> most extend during the development of dev-metadata. Now, since the changes
>>> in dev-metadata are stable enough, at least it won’t be a block for the
>>> development in master (which is also the biggest concern why we created
>>> this new branch), I think it’s time for us to merge the changes back and
>>> work on the unified master branch.
 
 2. Is there any plan for the release of OPS? Most of the new features
>>> introduced in v2.7 are service governance related abilities and most users
>>> have get used to using Dubbo OPS to do interoperability with their Dubbo
>>> services. Thus I think it would be great if an OPS version supporting these
>>> features can be released at the same time as v2.7 or slightly after it .
 @Minxuan @Majinkai, I know you guys are working on OPS project, any
>>> news to update?
 
 Jun
 
> On Dec 21, 2018, at 10:35 AM, jun liu >> ken.lj...@gmail.com>> wrote:
> 
>> 1. Prioritization of centralized configuration
> 
> Now, the centralized configuration or externalized configuration is
>>> implemented to has the highest priority by default. For flexible concerns,
>>> a switch is designed and opened to users so that they can override the
>>> default value, for example, you can use the following JVM property to give
>>> centralized configuration a lower priority than the local one:
>>> dubbo.configCenter.highestPriority=false.
> 
>> 2. The logic of the route is more complicated, and the compatibility
>>> with
>> the original low version is guaranteed.
> 
> When saying of complexity, I guess you mainly refer to the routing
>>> module, because this module is one of the most evident parts that has
>>> changed in this version and is also newly introduced. Its main purpose is
>>> to improve the performance of the runtime. After all, there will be some
>>> performance loss when routing is executed for address filtering every time
>>> an RPC is executed.
> However, I agree we should be really careful about this cache part
>>> since it works as an crucial path on the RPC wire. Some possible drawbacks
>>> I can come up with it now are: excessive resource usage, priority guarantee
>>> of routers in chain, etc. I think we can discuss more about the technical
>>> details of this part, give it more test and then decide whether to release
>>> it this time or wait until it’s mature enough.
> 
>> 3.Tag routing has been modified, how is the compatibility with the
>>> original?
> 
> It has full backward compatibility with the original implementation
>>> with only the supporting of of DynamicConfiguration added.
> 
>> 4. How does the Environment clear responsibility? It is best to have
>>> an
>> independent description.
> 
> Sorry, I don’t understand this one. Basically, you can think
>>> Environment as the counterpart of that in Spring. I agree we should add a
>>> document describing the design purpose and how to use it.
> 
> Jun
> 
>> On Dec 14, 2018, at 12:26 PM, victory >> shenglic...@gmail.com>> wrote:
>> 
>> All of this features are the biggest concert in the community.
>> I have some questions：
>> 1.中心化配置的优先级
>> 2.路由的逻辑比较复杂，和原来低版本的兼容性怎么保证
>> 3.Tag路由改造了，和原来的兼容性怎么样？
>> 4.Environment这个东西是怎么明确职责的？最好能有个独立的说明。
>> --
>> 1. Prioritization of

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-24 Thread yuhang xiu 
Hi, all

I also found out that the master ci has failed.
This caused some misunderstanding for me to deal with a pending pr[1].
After observing the log, I found that the issue[2] with @xin wang feedback
is the same problem.
Since the ci of the module of the cluster has passed and the code is well,
I will merge the pr first.

[1] https://github.com/apache/incubator-dubbo/pull/2822
[2] https://github.com/apache/incubator-dubbo/issues/3052

jun liu  于2018年12月24日周一 下午5:27写道：

> > Now the travis ci of master branch faile， I create an issue
> > https://github.com/apache/incubator-dubbo/issues/3052
> > Please take a look at it
>
> Thanks, I noticed too, I’ll take care of it.
>
> Jun
>
> > On Dec 24, 2018, at 5:25 PM, Xin Wang  wrote:
> >
> > hi, Jun
> >
> > Now the travis ci of master branch faile， I create an issue
> > https://github.com/apache/incubator-dubbo/issues/3052
> > Please take a look at it
> >
> > Xin Wang  于2018年12月24日周一 下午4:38写道：
> >
> >>> I have just merged dev-metadata branch into master, from now on, the
> >> master branch will work as the develop and release codebase of v2.7.0.
> >> Branch dev-metadata does not need to be kept anymore, I will delete
> >> dev-metadata later today if there’re no more PRs come to it.
> >>
> >> Great work, looking forward to the new features!
> >>
> >> jun liu  于2018年12月24日周一 下午4:33写道：
> >>
> >>> Hi, All
> >>>
> >>> I have just merged dev-metadata branch into master, from now on, the
> >>> master branch will work as the develop and release codebase of v2.7.0.
> >>> Branch dev-metadata does not need to be kept anymore, I will delete
> >>> dev-metadata later today if there’re no more PRs come to it.
> >>>
> >>> Jun
> >>>
>  On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
> 
>  Two more things to mention:
> 
>  1. I am thinking of merge this dev-metadata branch back to the master.
> >>> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> >>> together consist of v2.7’s release candidates. While they are evolving
> at
> >>> the same time concurrently, conflicts keep happening. I have been kept
> >>> merging the master branch to dev-metadata to try to avoid conflicts to
> the
> >>> most extend during the development of dev-metadata. Now, since the
> changes
> >>> in dev-metadata are stable enough, at least it won’t be a block for the
> >>> development in master (which is also the biggest concern why we created
> >>> this new branch), I think it’s time for us to merge the changes back
> and
> >>> work on the unified master branch.
> 
>  2. Is there any plan for the release of OPS? Most of the new features
> >>> introduced in v2.7 are service governance related abilities and most
> users
> >>> have get used to using Dubbo OPS to do interoperability with their
> Dubbo
> >>> services. Thus I think it would be great if an OPS version supporting
> these
> >>> features can be released at the same time as v2.7 or slightly after it
> .
>  @Minxuan @Majinkai, I know you guys are working on OPS project, any
> >>> news to update?
> 
>  Jun
> 
> > On Dec 21, 2018, at 10:35 AM, jun liu  >>> ken.lj...@gmail.com>> wrote:
> >
> >> 1. Prioritization of centralized configuration
> >
> > Now, the centralized configuration or externalized configuration is
> >>> implemented to has the highest priority by default. For flexible
> concerns,
> >>> a switch is designed and opened to users so that they can override the
> >>> default value, for example, you can use the following JVM property to
> give
> >>> centralized configuration a lower priority than the local one:
> >>> dubbo.configCenter.highestPriority=false.
> >
> >> 2. The logic of the route is more complicated, and the compatibility
> >>> with
> >> the original low version is guaranteed.
> >
> > When saying of complexity, I guess you mainly refer to the routing
> >>> module, because this module is one of the most evident parts that has
> >>> changed in this version and is also newly introduced. Its main purpose
> is
> >>> to improve the performance of the runtime. After all, there will be
> some
> >>> performance loss when routing is executed for address filtering every
> time
> >>> an RPC is executed.
> > However, I agree we should be really careful about this cache part
> >>> since it works as an crucial path on the RPC wire. Some possible
> drawbacks
> >>> I can come up with it now are: excessive resource usage, priority
> guarantee
> >>> of routers in chain, etc. I think we can discuss more about the
> technical
> >>> details of this part, give it more test and then decide whether to
> release
> >>> it this time or wait until it’s mature enough.
> >
> >> 3.Tag routing has been modified, how is the compatibility with the
> >>> original?
> >
> > It has full backward compatibility with the original implementation
> >>> with only the supporting of of DynamicConfiguration added.
> >
> >> 4. How does the Environmen

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-27 Thread jun liu 
Hi, All

Good news. All UTs in master has passed the Travis CI. 
The next goal would be to push this branch to release ready, I suggest we focus 
on code/design review and feature test. I’ll start a new thread to summary 
current status, todos and discuss about possible release schedules.

Jun

> On Dec 25, 2018, at 10:29 AM, yuhang xiu  wrote:
> 
> Hi, all
> 
> I also found out that the master ci has failed.
> This caused some misunderstanding for me to deal with a pending pr[1].
> After observing the log, I found that the issue[2] with @xin wang feedback
> is the same problem.
> Since the ci of the module of the cluster has passed and the code is well,
> I will merge the pr first.
> 
> [1] https://github.com/apache/incubator-dubbo/pull/2822
> [2] https://github.com/apache/incubator-dubbo/issues/3052
> 
> jun liu  于2018年12月24日周一 下午5:27写道：
> 
>>> Now the travis ci of master branch faile， I create an issue
>>> https://github.com/apache/incubator-dubbo/issues/3052
>>> Please take a look at it
>> 
>> Thanks, I noticed too, I’ll take care of it.
>> 
>> Jun
>> 
>>> On Dec 24, 2018, at 5:25 PM, Xin Wang  wrote:
>>> 
>>> hi, Jun
>>> 
>>> Now the travis ci of master branch faile， I create an issue
>>> https://github.com/apache/incubator-dubbo/issues/3052
>>> Please take a look at it
>>> 
>>> Xin Wang  于2018年12月24日周一 下午4:38写道：
>>> 
> I have just merged dev-metadata branch into master, from now on, the
 master branch will work as the develop and release codebase of v2.7.0.
 Branch dev-metadata does not need to be kept anymore, I will delete
 dev-metadata later today if there’re no more PRs come to it.
 
 Great work, looking forward to the new features!
 
 jun liu  于2018年12月24日周一 下午4:33写道：
 
> Hi, All
> 
> I have just merged dev-metadata branch into master, from now on, the
> master branch will work as the develop and release codebase of v2.7.0.
> Branch dev-metadata does not need to be kept anymore, I will delete
> dev-metadata later today if there’re no more PRs come to it.
> 
> Jun
> 
>> On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
>> 
>> Two more things to mention:
>> 
>> 1. I am thinking of merge this dev-metadata branch back to the master.
> Both these two branches have the same version 2.7.0-SNAPSHOT and they
> together consist of v2.7’s release candidates. While they are evolving
>> at
> the same time concurrently, conflicts keep happening. I have been kept
> merging the master branch to dev-metadata to try to avoid conflicts to
>> the
> most extend during the development of dev-metadata. Now, since the
>> changes
> in dev-metadata are stable enough, at least it won’t be a block for the
> development in master (which is also the biggest concern why we created
> this new branch), I think it’s time for us to merge the changes back
>> and
> work on the unified master branch.
>> 
>> 2. Is there any plan for the release of OPS? Most of the new features
> introduced in v2.7 are service governance related abilities and most
>> users
> have get used to using Dubbo OPS to do interoperability with their
>> Dubbo
> services. Thus I think it would be great if an OPS version supporting
>> these
> features can be released at the same time as v2.7 or slightly after it
>> .
>> @Minxuan @Majinkai, I know you guys are working on OPS project, any
> news to update?
>> 
>> Jun
>> 
>>> On Dec 21, 2018, at 10:35 AM, jun liu  ken.lj...@gmail.com>> wrote:
>>> 
 1. Prioritization of centralized configuration
>>> 
>>> Now, the centralized configuration or externalized configuration is
> implemented to has the highest priority by default. For flexible
>> concerns,
> a switch is designed and opened to users so that they can override the
> default value, for example, you can use the following JVM property to
>> give
> centralized configuration a lower priority than the local one:
> dubbo.configCenter.highestPriority=false.
>>> 
 2. The logic of the route is more complicated, and the compatibility
> with
 the original low version is guaranteed.
>>> 
>>> When saying of complexity, I guess you mainly refer to the routing
> module, because this module is one of the most evident parts that has
> changed in this version and is also newly introduced. Its main purpose
>> is
> to improve the performance of the runtime. After all, there will be
>> some
> performance loss when routing is executed for address filtering every
>> time
> an RPC is executed.
>>> However, I agree we should be really careful about this cache part
> since it works as an crucial path on the RPC wire. Some possible
>> drawbacks
> I can come up with it now are: excessive resource usage, priority
>> guarantee
> of routers in chain, etc. I think we can discuss more about the
>> technical
> d

Re: [DISCUSSION] Call for ideas and suggestions on v2.7.0 designs and implementations.

2018-12-27 Thread Ian Luo 
This is really a milestone to get all UTs pass. Since it is now officially
on the master branch, I am expecting more eyes on the code quality and the
design.

Cheers,
-Ian.

On Thu, Dec 27, 2018 at 11:07 PM jun liu  wrote:

> Hi, All
>
> Good news. All UTs in master has passed the Travis CI.
> The next goal would be to push this branch to release ready, I suggest we
> focus on code/design review and feature test. I’ll start a new thread to
> summary current status, todos and discuss about possible release schedules.
>
> Jun
>
> > On Dec 25, 2018, at 10:29 AM, yuhang xiu  wrote:
> >
> > Hi, all
> >
> > I also found out that the master ci has failed.
> > This caused some misunderstanding for me to deal with a pending pr[1].
> > After observing the log, I found that the issue[2] with @xin wang
> feedback
> > is the same problem.
> > Since the ci of the module of the cluster has passed and the code is
> well,
> > I will merge the pr first.
> >
> > [1] https://github.com/apache/incubator-dubbo/pull/2822
> > [2] https://github.com/apache/incubator-dubbo/issues/3052
> >
> > jun liu  于2018年12月24日周一 下午5:27写道：
> >
> >>> Now the travis ci of master branch faile， I create an issue
> >>> https://github.com/apache/incubator-dubbo/issues/3052
> >>> Please take a look at it
> >>
> >> Thanks, I noticed too, I’ll take care of it.
> >>
> >> Jun
> >>
> >>> On Dec 24, 2018, at 5:25 PM, Xin Wang 
> wrote:
> >>>
> >>> hi, Jun
> >>>
> >>> Now the travis ci of master branch faile， I create an issue
> >>> https://github.com/apache/incubator-dubbo/issues/3052
> >>> Please take a look at it
> >>>
> >>> Xin Wang  于2018年12月24日周一 下午4:38写道：
> >>>
> > I have just merged dev-metadata branch into master, from now on, the
>  master branch will work as the develop and release codebase of v2.7.0.
>  Branch dev-metadata does not need to be kept anymore, I will delete
>  dev-metadata later today if there’re no more PRs come to it.
> 
>  Great work, looking forward to the new features!
> 
>  jun liu  于2018年12月24日周一 下午4:33写道：
> 
> > Hi, All
> >
> > I have just merged dev-metadata branch into master, from now on, the
> > master branch will work as the develop and release codebase of
> v2.7.0.
> > Branch dev-metadata does not need to be kept anymore, I will delete
> > dev-metadata later today if there’re no more PRs come to it.
> >
> > Jun
> >
> >> On Dec 21, 2018, at 11:37 AM, jun liu  wrote:
> >>
> >> Two more things to mention:
> >>
> >> 1. I am thinking of merge this dev-metadata branch back to the
> master.
> > Both these two branches have the same version 2.7.0-SNAPSHOT and they
> > together consist of v2.7’s release candidates. While they are
> evolving
> >> at
> > the same time concurrently, conflicts keep happening. I have been
> kept
> > merging the master branch to dev-metadata to try to avoid conflicts
> to
> >> the
> > most extend during the development of dev-metadata. Now, since the
> >> changes
> > in dev-metadata are stable enough, at least it won’t be a block for
> the
> > development in master (which is also the biggest concern why we
> created
> > this new branch), I think it’s time for us to merge the changes back
> >> and
> > work on the unified master branch.
> >>
> >> 2. Is there any plan for the release of OPS? Most of the new
> features
> > introduced in v2.7 are service governance related abilities and most
> >> users
> > have get used to using Dubbo OPS to do interoperability with their
> >> Dubbo
> > services. Thus I think it would be great if an OPS version supporting
> >> these
> > features can be released at the same time as v2.7 or slightly after
> it
> >> .
> >> @Minxuan @Majinkai, I know you guys are working on OPS project, any
> > news to update?
> >>
> >> Jun
> >>
> >>> On Dec 21, 2018, at 10:35 AM, jun liu   > ken.lj...@gmail.com>> wrote:
> >>>
>  1. Prioritization of centralized configuration
> >>>
> >>> Now, the centralized configuration or externalized configuration is
> > implemented to has the highest priority by default. For flexible
> >> concerns,
> > a switch is designed and opened to users so that they can override
> the
> > default value, for example, you can use the following JVM property to
> >> give
> > centralized configuration a lower priority than the local one:
> > dubbo.configCenter.highestPriority=false.
> >>>
>  2. The logic of the route is more complicated, and the
> compatibility
> > with
>  the original low version is guaranteed.
> >>>
> >>> When saying of complexity, I guess you mainly refer to the routing
> > module, because this module is one of the most evident parts that has
> > changed in this version and is also newly introduced. Its main
> purpose
> >> is
> > to improve the performance of the runtime. After all, there will