You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@dubbo.apache.org by Jun Liu <li...@apache.org> on 2019/06/12 02:01:57 UTC
[DISCUSS] Observation of performance degradation of 2.7.2 under JDK
1.8.
Hi, All
Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
What do others think?
1. https://github.com/apache/dubbo/issues/4279
2. https://github.com/apache/dubbo/issues/4213
3. https://github.com/apache/dubbo-website/pull/388
Jun
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Huxing Zhang <hu...@apache.org>.
Hi,
On Fri, Jun 14, 2019 at 1:02 PM Jason Joo <hb...@163.com> wrote:
>
> Hi, Huxing
>
> In my view generally one release is followed after Alpha, Beta, RC is a quite normal workflow. And it keeps the stability, steady and seriousness to the final release. Especially for common users they can not recognize where 2.7.3 is a release for RC purpose in name "2.7.3" but things could be clear if name it "2.7.3-RC1" or "2.7.3-BETA".
I think normally for project following the semantic versioning
spec[1], where X.Y.Z means major version, minor version, and bugfix,
it is rare for a bugfix version to have release candidate versions.
The problem is that current versioning does not follow semantic
versioning. There is too much new features added in 2.7.2, which
caused the instability.
My suggestion is to make sure 2.7.x only contains bugfix, so that the
bugs will converge eventually. New features should be added by bumping
minor version to 2.8.x or later.
[1] https://semver.org/
>
> Sure it's a personal opinion.
>
> best regards,
>
> Jason
>
> > On Jun 14, 2019, at 12:50, Huxing Zhang <hu...@apache.org> wrote:
> >
> > Hi,
> >
> > On Fri, Jun 14, 2019 at 11:42 AM Jason Joo <hblzxsj@163.com <ma...@163.com>> wrote:
> >>
> >> Hi, Huxing
> >>
> >> Something you may misunderstand that the versions in descriptions from Jun should like:
> >>
> >> 2.7.3-RC1
> >> 2.7.3-RC2
> >> 2.7.3-RC3
> >> 2.7.3
> >
> > This naming looks weird to me. If 2.7.3-RC1 is not production ready,
> > what does 2.7.2 mean? They are inconsistent.
> >
> > What I am proposing is:
> >
> > 2.7.3 (Not production ready)
> > 2.7.4 (Not production ready)
> > ...
> > 2.7.N (mark as production ready)
> >
> >
> >
> >>
> >>
> >> best regards,
> >>
> >> Jason
> >>
> >>> On Jun 14, 2019, at 11:26, Huxing Zhang <huxing@apache.org <ma...@apache.org>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <liujun@apache.org <ma...@apache.org> <mailto:liujun@apache.org <ma...@apache.org>>> wrote:
> >>>>
> >>>>> I am +1 on marking current release NOT production ready.
> >>>>
> >>>> Do you think several rounds of beta or RC is necessary before every formal release?
> >>>
> >>> Given that 2.7.0-2.7.2 has already been published. I think it is weird
> >>> that the next version is 2.7.3-RC1.
> >>> Instead of that I think keep bumping the version to 2.7.3 is ok, as
> >>> long as we let the community know that it is not production ready
> >>> until the community formally announce it.
> >>>
> >>>>
> >>>> Other people have different opinions?
> >>>>
> >>>> Jun
> >>>>
> >>>>> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
> >>>>>>
> >>>>>> Hi, All
> >>>>>>
> >>>>>> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
> >>>>>>
> >>>>>> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
> >>>>>>
> >>>>>> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
> >>>>>>
> >>>>>> What do others think?
> >>>>>
> >>>>> I am +1 on marking current release NOT production ready.
> >>>>> It is necessary for users to try out the new features and provide
> >>>>> feedback, I think after several iterations, the 2.7.x will enter into
> >>>>> stability eventually.
> >>>>>
> >>>>>>
> >>>>>> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
> >>>>>> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
> >>>>>> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
> >>>>>>
> >>>>>> Jun
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Best Regards！
> >>>>> Huxing
> >>>>
> >>>
> >>>
> >>> --
> >>> Best Regards！
> >>> Huxing
> >>
> >
> >
> > --
> > Best Regards！
> > Huxing
>
--
Best Regards！
Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Jason Joo <hb...@163.com>.
Hi, Huxing
In my view generally one release is followed after Alpha, Beta, RC is a quite normal workflow. And it keeps the stability, steady and seriousness to the final release. Especially for common users they can not recognize where 2.7.3 is a release for RC purpose in name "2.7.3" but things could be clear if name it "2.7.3-RC1" or "2.7.3-BETA".
Sure it's a personal opinion.
best regards,
Jason
> On Jun 14, 2019, at 12:50, Huxing Zhang <hu...@apache.org> wrote:
>
> Hi,
>
> On Fri, Jun 14, 2019 at 11:42 AM Jason Joo <hblzxsj@163.com <ma...@163.com>> wrote:
>>
>> Hi, Huxing
>>
>> Something you may misunderstand that the versions in descriptions from Jun should like:
>>
>> 2.7.3-RC1
>> 2.7.3-RC2
>> 2.7.3-RC3
>> 2.7.3
>
> This naming looks weird to me. If 2.7.3-RC1 is not production ready,
> what does 2.7.2 mean? They are inconsistent.
>
> What I am proposing is:
>
> 2.7.3 (Not production ready)
> 2.7.4 (Not production ready)
> ...
> 2.7.N (mark as production ready)
>
>
>
>>
>>
>> best regards,
>>
>> Jason
>>
>>> On Jun 14, 2019, at 11:26, Huxing Zhang <huxing@apache.org <ma...@apache.org>> wrote:
>>>
>>> Hi,
>>>
>>> On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <liujun@apache.org <ma...@apache.org> <mailto:liujun@apache.org <ma...@apache.org>>> wrote:
>>>>
>>>>> I am +1 on marking current release NOT production ready.
>>>>
>>>> Do you think several rounds of beta or RC is necessary before every formal release?
>>>
>>> Given that 2.7.0-2.7.2 has already been published. I think it is weird
>>> that the next version is 2.7.3-RC1.
>>> Instead of that I think keep bumping the version to 2.7.3 is ok, as
>>> long as we let the community know that it is not production ready
>>> until the community formally announce it.
>>>
>>>>
>>>> Other people have different opinions?
>>>>
>>>> Jun
>>>>
>>>>> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
>>>>>>
>>>>>> Hi, All
>>>>>>
>>>>>> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
>>>>>>
>>>>>> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
>>>>>>
>>>>>> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
>>>>>>
>>>>>> What do others think?
>>>>>
>>>>> I am +1 on marking current release NOT production ready.
>>>>> It is necessary for users to try out the new features and provide
>>>>> feedback, I think after several iterations, the 2.7.x will enter into
>>>>> stability eventually.
>>>>>
>>>>>>
>>>>>> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
>>>>>> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
>>>>>> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
>>>>>>
>>>>>> Jun
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards！
>>>>> Huxing
>>>>
>>>
>>>
>>> --
>>> Best Regards！
>>> Huxing
>>
>
>
> --
> Best Regards！
> Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Huxing Zhang <hu...@apache.org>.
Hi,
On Fri, Jun 14, 2019 at 11:42 AM Jason Joo <hb...@163.com> wrote:
>
> Hi, Huxing
>
> Something you may misunderstand that the versions in descriptions from Jun should like:
>
> 2.7.3-RC1
> 2.7.3-RC2
> 2.7.3-RC3
> 2.7.3
This naming looks weird to me. If 2.7.3-RC1 is not production ready,
what does 2.7.2 mean? They are inconsistent.
What I am proposing is:
2.7.3 (Not production ready)
2.7.4 (Not production ready)
...
2.7.N (mark as production ready)
>
>
> best regards,
>
> Jason
>
> > On Jun 14, 2019, at 11:26, Huxing Zhang <hu...@apache.org> wrote:
> >
> > Hi,
> >
> > On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
> >>
> >>> I am +1 on marking current release NOT production ready.
> >>
> >> Do you think several rounds of beta or RC is necessary before every formal release?
> >
> > Given that 2.7.0-2.7.2 has already been published. I think it is weird
> > that the next version is 2.7.3-RC1.
> > Instead of that I think keep bumping the version to 2.7.3 is ok, as
> > long as we let the community know that it is not production ready
> > until the community formally announce it.
> >
> >>
> >> Other people have different opinions?
> >>
> >> Jun
> >>
> >>> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>>
> >>> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
> >>>>
> >>>> Hi, All
> >>>>
> >>>> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
> >>>>
> >>>> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
> >>>>
> >>>> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
> >>>>
> >>>> What do others think?
> >>>
> >>> I am +1 on marking current release NOT production ready.
> >>> It is necessary for users to try out the new features and provide
> >>> feedback, I think after several iterations, the 2.7.x will enter into
> >>> stability eventually.
> >>>
> >>>>
> >>>> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
> >>>> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
> >>>> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
> >>>>
> >>>> Jun
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards！
> >>> Huxing
> >>
> >
> >
> > --
> > Best Regards！
> > Huxing
>
--
Best Regards！
Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Jason Joo <hb...@163.com>.
Hi, Huxing
Something you may misunderstand that the versions in descriptions from Jun should like:
2.7.3-RC1
2.7.3-RC2
2.7.3-RC3
2.7.3
best regards,
Jason
> On Jun 14, 2019, at 11:26, Huxing Zhang <hu...@apache.org> wrote:
>
> Hi,
>
> On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
>>
>>> I am +1 on marking current release NOT production ready.
>>
>> Do you think several rounds of beta or RC is necessary before every formal release?
>
> Given that 2.7.0-2.7.2 has already been published. I think it is weird
> that the next version is 2.7.3-RC1.
> Instead of that I think keep bumping the version to 2.7.3 is ok, as
> long as we let the community know that it is not production ready
> until the community formally announce it.
>
>>
>> Other people have different opinions?
>>
>> Jun
>>
>>> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
>>>>
>>>> Hi, All
>>>>
>>>> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
>>>>
>>>> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
>>>>
>>>> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
>>>>
>>>> What do others think?
>>>
>>> I am +1 on marking current release NOT production ready.
>>> It is necessary for users to try out the new features and provide
>>> feedback, I think after several iterations, the 2.7.x will enter into
>>> stability eventually.
>>>
>>>>
>>>> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
>>>> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
>>>> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
>>>>
>>>> Jun
>>>
>>>
>>>
>>> --
>>> Best Regards！
>>> Huxing
>>
>
>
> --
> Best Regards！
> Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Huxing Zhang <hu...@apache.org>.
Hi,
On Fri, Jun 14, 2019 at 10:01 AM Jun Liu <li...@apache.org> wrote:
>
> > I am +1 on marking current release NOT production ready.
>
> Do you think several rounds of beta or RC is necessary before every formal release?
Given that 2.7.0-2.7.2 has already been published. I think it is weird
that the next version is 2.7.3-RC1.
Instead of that I think keep bumping the version to 2.7.3 is ok, as
long as we let the community know that it is not production ready
until the community formally announce it.
>
> Other people have different opinions?
>
> Jun
>
> > On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
> >
> > Hi,
> >
> >
> > On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
> >>
> >> Hi, All
> >>
> >> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
> >>
> >> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
> >>
> >> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
> >>
> >> What do others think?
> >
> > I am +1 on marking current release NOT production ready.
> > It is necessary for users to try out the new features and provide
> > feedback, I think after several iterations, the 2.7.x will enter into
> > stability eventually.
> >
> >>
> >> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
> >> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
> >> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
> >>
> >> Jun
> >
> >
> >
> > --
> > Best Regards！
> > Huxing
>
--
Best Regards！
Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Jun Liu <li...@apache.org>.
> I am +1 on marking current release NOT production ready.
Do you think several rounds of beta or RC is necessary before every formal release?
Other people have different opinions?
Jun
> On Jun 12, 2019, at 2:46 PM, Huxing Zhang <hu...@apache.org> wrote:
>
> Hi,
>
>
> On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <liujun@apache.org <ma...@apache.org>> wrote:
>>
>> Hi, All
>>
>> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
>>
>> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
>>
>> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
>>
>> What do others think?
>
> I am +1 on marking current release NOT production ready.
> It is necessary for users to try out the new features and provide
> feedback, I think after several iterations, the 2.7.x will enter into
> stability eventually.
>
>>
>> 1. https://github.com/apache/dubbo/issues/4279 <https://github.com/apache/dubbo/issues/4279>
>> 2. https://github.com/apache/dubbo/issues/4213 <https://github.com/apache/dubbo/issues/4213>
>> 3. https://github.com/apache/dubbo-website/pull/388 <https://github.com/apache/dubbo-website/pull/388>
>>
>> Jun
>
>
>
> --
> Best Regards！
> Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Huxing Zhang <hu...@apache.org>.
Hi,
On Wed, Jun 12, 2019 at 10:02 AM Jun Liu <li...@apache.org> wrote:
>
> Hi, All
>
> Recently, Jeff and I and some other volunteers from the community are trying to improve the performance of Dubbo. When doing benchmark, we found that the usage of CompletableFuture in the 2.7.2 has a significant performance degradation (both QPS and RT) when running under the JDK 1.8 version (but performs ok under JDK 11), check this issue[1] for more details. Thinking of some other problems found recently, the service registration discovery problem in 2.7.1[2], the configuration model unification problem[3], etc. I think we need to reconsider the evolution plan and stability guarantee of 2.7.
>
> From my point of view, version 2.7 is releasing in a relatively fast pace, with each version containing lots of features and refactoring changes, I think this is a good sign for the community. But this also brings us new problems, especially when we don't have enough infrastructures and time to test each version, it is very difficult to ensure the functional stability and well performance of each version. Considering our roadmap in the near future, this situation seems to be even worse. According to our draft roadmap released in last meetup in Beijing, we will release the native cloud service discovery model in version 2.7.3 or 2.7.4, which is almost a complete refactoring of Dubbo's current service discovery functionality, I doubt the both the API and feature stability is hard to guarantee without several releases.
>
> So my main concern is the stability of the 2.7.x version. Maybe the released or the following several releases should be marked as non-production available from the community level officially, or consider add beta, RC, etc. tags to some version numbers if necessary. What do others think?
>
> What do others think?
I am +1 on marking current release NOT production ready.
It is necessary for users to try out the new features and provide
feedback, I think after several iterations, the 2.7.x will enter into
stability eventually.
>
> 1. https://github.com/apache/dubbo/issues/4279
> 2. https://github.com/apache/dubbo/issues/4213
> 3. https://github.com/apache/dubbo-website/pull/388
>
> Jun
--
Best Regards！
Huxing
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Jun Liu <li...@apache.org>.
> Because as some discussions in some issues we indeed need a performance test before releasing, merging PRs and i think the problems will be disappeared after that.
Agree.
The community is working on making the Integration Test[1] automatically, hopefully, it would be able to service before the next major release. Of course, after IT, we can also make report benchmark statistics regularly using our benchmark project[2].
1. https://github.com/apache/incubator-dubbo-samples
2. https://github.com/apache/dubbo-benchmark
Jun
> On Jun 12, 2019, at 10:18 AM, Jason Joo <hb...@163.com> wrote:
>
> Hi, jun
>
>> Take milestones with big features included as "RC" versions.
>
> Totally agree with you and that's my previous suggestion that we should release several RC into repository enabling limited production tests.
> But in my opinion we shouldn't worry too much on the issues happening currently. Because as some discussions in some issues we indeed need a performance test before releasing, merging PRs and i think the problems will be disappeared after that.
>
> So is it in process? Anyone know it?
>
> best regards,
>
> Jason
>
>> On Jun 12, 2019, at 10:01, Jun Liu <li...@apache.org> wrote:
>>
>>
>
Re: [DISCUSS] Observation of performance degradation of 2.7.2 under
JDK 1.8.
Posted by Jason Joo <hb...@163.com>.
Hi, jun
> Take milestones with big features included as "RC" versions.
Totally agree with you and that's my previous suggestion that we should release several RC into repository enabling limited production tests.
But in my opinion we shouldn't worry too much on the issues happening currently. Because as some discussions in some issues we indeed need a performance test before releasing, merging PRs and i think the problems will be disappeared after that.
So is it in process? Anyone know it?
best regards,
Jason
> On Jun 12, 2019, at 10:01, Jun Liu <li...@apache.org> wrote:
>
>