Re: [ANN] New PPMC member: Shang Zonghai

[jun liu]

Congratulations!

Best regards,
Jun

> On Nov 1, 2018, at 8:58 PM, Huxing Zhang  wrote:
> 
> Hi, Community,
> 
> On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
> 
> Please join me to say congratulations to him!
> 
> [1] https://github.com/zonghaishang
> -- 
> Best Regards！
> Huxing

Re: Fix disable provider does’t work.

[Zonghai Shang]

Hi,

> Isn’t that a protective mechanism Dubbo deliberately made? For example,
to protect a `disable=true` policy from working if it disables the last
provider that’s available.

If the user wants to call it can be prohibited, Similarly, if the user
explicitly disables, the call should be disabled.

> Will this problem happen when explicitly offline or unregister all
provider from the registry?

The main scenario here is the scenario where the override policy is sent.
Override polocy has restricted all providers（> 1, ip: 0.0.0.0） from being
disabled.

-yiji

jun liu  于2018年11月2日周五 上午11:44写道：

> Isn’t that a protective mechanism Dubbo deliberately made? For example, to
> protect a `disable=true` policy from working if it disables the last
> provider that’s available.
>
> Will this problem happen when explicitly offline or unregister all
> provider from the registry?
>
> I will dive into the code later.
>
> Best regards,
> Jun
>
> > On Nov 1, 2018, at 8:58 PM, Zonghai Shang  wrote:
> >
> > Hi,
> >
> > I found that the dubbo service was still called after it was disabled. I
> > analyzed and fixed this problem.
> >
> > This is my pull request:
> > https://github.com/apache/incubator-dubbo/pull/2729
> >
> > Please help me check again, thanks.
> >
> > -yiji
>
>

Re: [DISCUSS] should we include gson support in main trunk

[jun liu]

Great to have a new serialization extension!

> I'm hesitate to move it in
> since we've already had fastjson serialization support which serves the
> same purpose.

Thanks to Dubbo’s SPI, we can extend as many serialization protocol as we want. 
I think the existing fastjson should never be the reason to block this one from 
being accepted into the eco-system.

Best regards,
Jun

> On Nov 1, 2018, at 1:25 PM, Ian Luo  wrote:
> 
> I've checked in gson support to
> https://github.com/dubbo/dubbo-serialization-gson. I also left message on
> the original pull request to invite the original author to join. Hope he
> can give me a reply soon.
> 
> Regards,
> -Ian.
> 
> On Thu, Nov 1, 2018 at 10:46 AM Ian Luo  wrote:
> 
>> I failed to get response from the original author. I plan to revise his
>> impl and put it in eco system, to provide community an alternative on json
>> support. I hope the original author can come back to work with me together
>> later.
>> 
>> -Ian.
>> 
>> On Thu, Nov 1, 2018 at 10:21 AM yuhang xiu  wrote:
>> 
>>> Agree with u.
>>> The serialization method of json is also much slower than hessian and
>>> kryo,
>>> and the data is relatively large. We don't have to support all json
>>> serialization. But just put it into ecosystem.
>>> 
>>> YunKun Huang  于2018年11月1日周四 上午10:17写道：
>>> 
 For same purpose I prefer to have only one implement.
 
 And for fastjson and gson, it's hard to make decision which one is
>>> better,
 since we already had fastjson in master, gson support can be part of
 ecosystem but not in master
 
 
 On 2018/10/29 09:46:26, Ian Luo  wrote:
> Hi folks,
> 
> Today I noticed there's one pull request 2699 (dubbo Add a new
> serialization -gson) [1] pending for review. I'm hesitate to move it
>>> in
> since we've already had fastjson serialization support which serves
>>> the
> same purpose.
> 
> I'd like to hear your opinion on this.
> 
> Thanks,
> -Ian.
> 
> 
> 1. https://github.com/apache/incubator-dubbo/pull/2699
> 
 
>>> 
>> 

Re: Fix disable provider does’t work.

[jun liu]

Isn’t that a protective mechanism Dubbo deliberately made? For example, to 
protect a `disable=true` policy from working if it disables the last provider 
that’s available.

Will this problem happen when explicitly offline or unregister all provider 
from the registry?

I will dive into the code later. 

Best regards,
Jun

> On Nov 1, 2018, at 8:58 PM, Zonghai Shang  wrote:
> 
> Hi,
> 
> I found that the dubbo service was still called after it was disabled. I
> analyzed and fixed this problem.
> 
> This is my pull request:
> https://github.com/apache/incubator-dubbo/pull/2729
> 
> Please help me check again, thanks.
> 
> -yiji

Re: pull request 2686

[田 小波]

OK. I will read it carefully on this weekend.

-xiaobo

> 在 2018年11月2日，上午11:30，Ian Luo  写道：
> 
> Then Xiaobo, I am looking forward to merging your another pull request for
> doc update :). You should start to look into website project [1]. Pls. read
> its README to understand how to build it.
> 
> Thanks,
> -Ian.
> 
> 1. https://github.com/apache/incubator-dubbo-website
> 
> On Fri, Nov 2, 2018 at 11:15 AM 田 小波  wrote:
> 
>> OK. I got it.
>> 
>>> 在 2018年11月2日，上午11:10，jun liu  写道：
>>> 
 Nice! if needed, May I help to update the doc about delay exposure when
>> PR-2686 is released at next release or later.
>>> 
>>> That would be great. Docs are the part I forget to mention. You can
>> submit a PR to the dubbo-website project hosted here:
>>> https://github.com/apache/incubator-dubbo-website
>>> 
>>> Best regards,
>>> Jun
>>> 
 On Nov 2, 2018, at 10:49 AM, 田 小波  wrote:
 
 Nice! if needed, May I help to update the doc about delay exposure when
>> PR-2686 is released at next release or later.
 
 在 2018年11月2日，上午10:07，Ian Luo > ian@gmail.com>> 写道：
 
 To make sure I understand the change affect right, is the following and
>> the corresponding action right (for spring supports application listener)?
 Export always being executed after Spring Context initialized properly
>> despite the delay value, and the delay times after that is:
 * delay=null, no delay
 * delay=0, no delay
 * delay=-1 or delay=-5000, no delay
 * delay=5000, delay for 5s.
 
 Correct, this is what I understand too.
 
 On Fri, Nov 2, 2018 at 9:51 AM jun liu > ken.lj...@gmail.com>> wrote:
> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured.
 
 +1, agree with this logic as the default for the export process.
 
> Unfortunately in
> order to keep backward compatibility, considering not all spring
>> versions
> support context refresh callback, we have to start to expose services
>> after
> properties set if we find application listener is not supported, and
>> hope
> Dubbo service can be exposed normally.
 
 At first, I tend to remove the compatibility purpose snippet, because
>> spring versions without application listener support seems to be v2.0.0 or
>> earlier which must have been announced EOL long ago and may have few users.
>> But since the critical export process will never be triggered if removed, I
>> think it’s ok to continue keep it.
 
 To make sure I understand the change affect right, is the following and
>> the corresponding action right (for spring supports application listener)?
 
 Export always being executed after Spring Context initialized properly
>> despite the delay value, and the delay times after that is:
 * delay=null, no delay
 * delay=0, no delay
 * delay=-1 or delay=-5000, no delay
 * delay=5000, delay for 5s.
 
 Best regards,
 Jun
 
> On Nov 1, 2018, at 10:39 AM, Ian Luo > ian@gmail.com>> wrote:
> 
>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> supportedApplicationListener = true 时，export 会被 onApplicationEvent
>> 调用，而不是
> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> 
> I think this behavior is expected. The reason is, the best timing for
>> Dubbo
> to count down delay for exposing service is when Spring container is
>> ready,
> then this timing should be the moment when spring context gets
>> refreshed,
> since at this moment, all beans are settled, and are ready for wiring
>> in
> their dependencies. If it happens earlier, say, at the moment after
> properties set, then Dubbo may fail to expose service because it
>> depends on
> other spring bean.
> 
> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured.
>> Unfortunately in
> order to keep backward compatibility, considering not all spring
>> versions
> support context refresh callback, we have to start to expose services
>> after
> properties set if we find application listener is not supported, and
>> hope
> Dubbo service can be exposed normally.
> 
> I hope this can clarify the behavior.
> 
> -Ian.
> 
> 
> 
> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang > y...@apache.org>> wrote:
> 
>> Hi,
>> 
>>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
>>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent
>> 调用
>> export 暴露服务
>>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
>> 
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>> supportedApplicationListener = true 时，export 会被 onApplicationEvent
>> 调用，而不是
>> afterPro

Re: Advice to the package name refactor of version 2.7.0

[jun liu]

> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes.  So please ingore this discussion.

That’s correct!

> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.

Both the API and SPI need to be compatible after repackage. The API part is 
relatively easy since there’re only few APIs exposed to end users, and the API 
interface relies on little internal classes. But when comes to SPI it’s a 
little tricky, most SPI interface’s method signature relies on internal classes 
and this forces us to consider the compatibility of those internal classes at 
the same time.

Best regards,
Jun

> On Nov 1, 2018, at 7:23 PM, RQ  wrote:
> 
> Correct.  I just was worried that Dubbo may transfer those object on
> remoting layer because of  some mistaked memory .
> 
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes.  So please ingore this discussion.
> 
> BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
> DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
> problem.
> 
> Thanks
> Jeff
> 
> 
> 
> 
> Ian Luo  于2018年11月1日周四 下午5:51写道：
> 
>> So basically you are concerning on inter-op compatibility among the
>> different Dubbo instances?
>> 
>> Thanks,
>> -Ian.
>> 
>> On Thu, Nov 1, 2018 at 4:34 PM RQ  wrote:
>> 
>>> Hi Community,
>>> 
>>> I saw that it is the biggest version since into Apache Community with
>>> great
>>> changes  which include the package names renamed to *org.apache.dubbo.*
>>> 
>>> For this part of changes, the compatibility upward is what we care mostly.
>>> Here are two types of scenses we should keep it as legacy interfaces.
>>> 1) the interfaces or classes that Dubbo's users use in the application.
>>> Currently, it is ok.
>>> 2) the tranfer classes  that is serializable in remoting layer. such as
>>> RpcInvocation. We should keep the old package for communication between
>>> vesion 2.7 and version older than 2.7. I saw that this part of refactor
>>> should be think twice in version 2.7.
>>> 
>>> Please correct my views if I misunderstood.
>>> 
>>> Regards
>>> Thanks.
>>> 
>> 

Re: pull request 2686

[Ian Luo]

Then Xiaobo, I am looking forward to merging your another pull request for
doc update :). You should start to look into website project [1]. Pls. read
its README to understand how to build it.

Thanks,
-Ian.

1. https://github.com/apache/incubator-dubbo-website

On Fri, Nov 2, 2018 at 11:15 AM 田 小波  wrote:

> OK. I got it.
>
> > 在 2018年11月2日，上午11:10，jun liu  写道：
> >
> >> Nice! if needed, May I help to update the doc about delay exposure when
> PR-2686 is released at next release or later.
> >
> > That would be great. Docs are the part I forget to mention. You can
> submit a PR to the dubbo-website project hosted here:
> > https://github.com/apache/incubator-dubbo-website
> >
> > Best regards,
> > Jun
> >
> >> On Nov 2, 2018, at 10:49 AM, 田 小波  wrote:
> >>
> >> Nice! if needed, May I help to update the doc about delay exposure when
> PR-2686 is released at next release or later.
> >>
> >> 在 2018年11月2日，上午10:07，Ian Luo  ian@gmail.com>> 写道：
> >>
> >> To make sure I understand the change affect right, is the following and
> the corresponding action right (for spring supports application listener)?
> >> Export always being executed after Spring Context initialized properly
> despite the delay value, and the delay times after that is:
> >> * delay=null, no delay
> >> * delay=0, no delay
> >> * delay=-1 or delay=-5000, no delay
> >> * delay=5000, delay for 5s.
> >>
> >> Correct, this is what I understand too.
> >>
> >> On Fri, Nov 2, 2018 at 9:51 AM jun liu  ken.lj...@gmail.com>> wrote:
> >>> To conclude, Dubbo should start to expose services until spring context
> >>> gets refreshed, no matter delay or no-delay is configured.
> >>
> >> +1, agree with this logic as the default for the export process.
> >>
> >>> Unfortunately in
> >>> order to keep backward compatibility, considering not all spring
> versions
> >>> support context refresh callback, we have to start to expose services
> after
> >>> properties set if we find application listener is not supported, and
> hope
> >>> Dubbo service can be exposed normally.
> >>
> >> At first, I tend to remove the compatibility purpose snippet, because
> spring versions without application listener support seems to be v2.0.0 or
> earlier which must have been announced EOL long ago and may have few users.
> But since the critical export process will never be triggered if removed, I
> think it’s ok to continue keep it.
> >>
> >> To make sure I understand the change affect right, is the following and
> the corresponding action right (for spring supports application listener)?
> >>
> >> Export always being executed after Spring Context initialized properly
> despite the delay value, and the delay times after that is:
> >> * delay=null, no delay
> >> * delay=0, no delay
> >> * delay=-1 or delay=-5000, no delay
> >> * delay=5000, delay for 5s.
> >>
> >> Best regards,
> >> Jun
> >>
> >>> On Nov 1, 2018, at 10:39 AM, Ian Luo  ian@gmail.com>> wrote:
> >>>
>  当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> >>> supportedApplicationListener = true 时，export 会被 onApplicationEvent
> 调用，而不是
> >>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> >>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> >>>
> >>> I think this behavior is expected. The reason is, the best timing for
> Dubbo
> >>> to count down delay for exposing service is when Spring container is
> ready,
> >>> then this timing should be the moment when spring context gets
> refreshed,
> >>> since at this moment, all beans are settled, and are ready for wiring
> in
> >>> their dependencies. If it happens earlier, say, at the moment after
> >>> properties set, then Dubbo may fail to expose service because it
> depends on
> >>> other spring bean.
> >>>
> >>> To conclude, Dubbo should start to expose services until spring context
> >>> gets refreshed, no matter delay or no-delay is configured.
> Unfortunately in
> >>> order to keep backward compatibility, considering not all spring
> versions
> >>> support context refresh callback, we have to start to expose services
> after
> >>> properties set if we find application listener is not supported, and
> hope
> >>> Dubbo service can be exposed normally.
> >>>
> >>> I hope this can clarify the behavior.
> >>>
> >>> -Ian.
> >>>
> >>>
> >>>
> >>> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang  y...@apache.org>> wrote:
> >>>
>  Hi,
> 
> > 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> > delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent
> 调用
>  export 暴露服务
> > delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>  时算起，此时由 afterPropertiesSet 调用 export暴露服务
> 
> > 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>  supportedApplicationListener = true 时，export 会被 onApplicationEvent
> 调用，而不是
>  afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>  毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> 
> > 这是我目前所发现的问题，不知道和你说的是不是同一个。
> 
>  Yes, you are 

Re: pull request 2686

[田 小波]

OK. I got it.

> 在 2018年11月2日，上午11:10，jun liu  写道：
> 
>> Nice! if needed, May I help to update the doc about delay exposure when 
>> PR-2686 is released at next release or later.
> 
> That would be great. Docs are the part I forget to mention. You can submit a 
> PR to the dubbo-website project hosted here:
> https://github.com/apache/incubator-dubbo-website
> 
> Best regards,
> Jun
> 
>> On Nov 2, 2018, at 10:49 AM, 田 小波  wrote:
>> 
>> Nice! if needed, May I help to update the doc about delay exposure when 
>> PR-2686 is released at next release or later.
>> 
>> 在 2018年11月2日，上午10:07，Ian Luo mailto:ian@gmail.com>> 
>> 写道：
>> 
>> To make sure I understand the change affect right, is the following and the 
>> corresponding action right (for spring supports application listener)?
>> Export always being executed after Spring Context initialized properly 
>> despite the delay value, and the delay times after that is:
>> * delay=null, no delay
>> * delay=0, no delay
>> * delay=-1 or delay=-5000, no delay
>> * delay=5000, delay for 5s.
>> 
>> Correct, this is what I understand too.
>> 
>> On Fri, Nov 2, 2018 at 9:51 AM jun liu 
>> mailto:ken.lj...@gmail.com>> wrote:
>>> To conclude, Dubbo should start to expose services until spring context
>>> gets refreshed, no matter delay or no-delay is configured.
>> 
>> +1, agree with this logic as the default for the export process.
>> 
>>> Unfortunately in
>>> order to keep backward compatibility, considering not all spring versions
>>> support context refresh callback, we have to start to expose services after
>>> properties set if we find application listener is not supported, and hope
>>> Dubbo service can be exposed normally.
>> 
>> At first, I tend to remove the compatibility purpose snippet, because spring 
>> versions without application listener support seems to be v2.0.0 or earlier 
>> which must have been announced EOL long ago and may have few users. But 
>> since the critical export process will never be triggered if removed, I 
>> think it’s ok to continue keep it.
>> 
>> To make sure I understand the change affect right, is the following and the 
>> corresponding action right (for spring supports application listener)?
>> 
>> Export always being executed after Spring Context initialized properly 
>> despite the delay value, and the delay times after that is:
>> * delay=null, no delay
>> * delay=0, no delay
>> * delay=-1 or delay=-5000, no delay
>> * delay=5000, delay for 5s.
>> 
>> Best regards,
>> Jun
>> 
>>> On Nov 1, 2018, at 10:39 AM, Ian Luo 
>>> mailto:ian@gmail.com>> wrote:
>>> 
 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>>> 
>>> I think this behavior is expected. The reason is, the best timing for Dubbo
>>> to count down delay for exposing service is when Spring container is ready,
>>> then this timing should be the moment when spring context gets refreshed,
>>> since at this moment, all beans are settled, and are ready for wiring in
>>> their dependencies. If it happens earlier, say, at the moment after
>>> properties set, then Dubbo may fail to expose service because it depends on
>>> other spring bean.
>>> 
>>> To conclude, Dubbo should start to expose services until spring context
>>> gets refreshed, no matter delay or no-delay is configured. Unfortunately in
>>> order to keep backward compatibility, considering not all spring versions
>>> support context refresh callback, we have to start to expose services after
>>> properties set if we find application listener is not supported, and hope
>>> Dubbo service can be exposed normally.
>>> 
>>> I hope this can clarify the behavior.
>>> 
>>> -Ian.
>>> 
>>> 
>>> 
>>> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang 
>>> mailto:y...@apache.org>> wrote:
>>> 
 Hi,
 
> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
 export 暴露服务
> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
 时算起，此时由 afterPropertiesSet 调用 export暴露服务
 
> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
 supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
 afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
 
> 这是我目前所发现的问题，不知道和你说的是不是同一个。
 
 Yes, you are right.
 
 yiji
 
 田 小波 mailto:tianxiaobo@outlook.com>> 
 于2018年11月1日周四 上午1:25写道：
 
> Hi,
> 
> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> 
> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
> export 暴露服务
> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
> 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
> 
> 当代码修改后，由于 afterPropertiesSet 不再对 d

Re: [DISCUSS] issue 2541: Lack of HealthCheck ,we need it

[jun liu]

I left my opinions on Github issue#2541. Since the initial user of this issue 
seems to more likely to have this discussion on Github, it would be more 
convenient for him to notice that.

Briefly conclude, I raised two questions:
1. In what condition would we consider a service is ready for use?
1. How to export the health check service to end users, monitor systems or peer 
Dubbo Consumers? http, telnet or Dubbo?


Best regards,
Jun

> On Nov 1, 2018, at 3:02 PM, Ian Luo  wrote:
> 
> Hi Folks,
> 
> Recently Longfei (@stoneapple) from ICBU SDC raised one interesting topic
> against health check on issue 2541 [1]. Here below I list the brief
> discussion thread on this issue:
> 
> @stoneapple:
> 
>> Currently Dubbo does not have the ability of readiness check and that is
>> somehow very helpful and needed in production env.
>> Does dubbo team has any plans on it ? can you show some detail design
>> drafts ?
>> Our team currently is planing to add the healthcheck ability on dubbo , so
>> we want to know dubbo team's opinion , if ok , we may give a pr on this
>> topic.
> 
> 
> @kimmking
> 
>> @stoneapple It's a nice way to describe more details for your idea.
> 
> 
> @stoneapple
> 
>> we know dubbo have the delay exposed ability, sometimes delay time is not
>> easy to figure out. Also we may want to check other resources like db,cache
>> before we exposed our service to meet the business trade.
> 
> 
> @beiwei30
> 
>> @stoneapple if you have good idea for builtin /health service, pls. simply
>> submit a pull request :) From the point of view of Dubbo, it sounds like
>> Dubbo can only provide readiness for dubbo services only.
> 
> 
> @zonghaishang
> 
>> 我这边提供一个思路看看是否可行，实现一个最低优先级的ServiceBean,
>> 在这里拿到所有spring上下文ServiceBean的名字(BeanFactoryUtils.beansOfTypeIncludingAncestors(applicationContext,
>> ServiceBean.class, false, false)),
>> 每次在服务export时把成功暴露的bean从map剔除，在最后一个低优先级servicebean中检查没有正确暴露服务。
> 
> 
> @beiwei30
> 
>> what I propose is to provide a builtin health service which expose metrics
>> data to the user, from which at lease user can easily to learn whether all
>> other services are UP or not.
> 
> 
> If you are interested in this, pls. check the whole discussion directly on
> GitHub.
> 
> Longfei, if you happen to read this mail, would you like to share us your
> design here, then we can further discuss based on your proposal?
> 
> Others, this feature is quite critical for micro service governance, I'd
> like also hear from you. Feel free to discuss in mailing list, or propose
> your thought directly on GitHub issue.
> 
> Thanks,
> -Ian.
> 
> 
> 1. https://github.com/apache/incubator-dubbo/issues/2541

Re: pull request 2686

[jun liu]

> Nice! if needed, May I help to update the doc about delay exposure when 
> PR-2686 is released at next release or later.

That would be great. Docs are the part I forget to mention. You can submit a PR 
to the dubbo-website project hosted here:
https://github.com/apache/incubator-dubbo-website

Best regards,
Jun

> On Nov 2, 2018, at 10:49 AM, 田 小波  wrote:
> 
> Nice! if needed, May I help to update the doc about delay exposure when 
> PR-2686 is released at next release or later.
> 
> 在 2018年11月2日，上午10:07，Ian Luo mailto:ian@gmail.com>> 写道：
> 
> To make sure I understand the change affect right, is the following and the 
> corresponding action right (for spring supports application listener)?
> Export always being executed after Spring Context initialized properly 
> despite the delay value, and the delay times after that is:
> * delay=null, no delay
> * delay=0, no delay
> * delay=-1 or delay=-5000, no delay
> * delay=5000, delay for 5s.
> 
> Correct, this is what I understand too.
> 
> On Fri, Nov 2, 2018 at 9:51 AM jun liu 
> mailto:ken.lj...@gmail.com>> wrote:
>> To conclude, Dubbo should start to expose services until spring context
>> gets refreshed, no matter delay or no-delay is configured.
> 
> +1, agree with this logic as the default for the export process.
> 
>> Unfortunately in
>> order to keep backward compatibility, considering not all spring versions
>> support context refresh callback, we have to start to expose services after
>> properties set if we find application listener is not supported, and hope
>> Dubbo service can be exposed normally.
> 
> At first, I tend to remove the compatibility purpose snippet, because spring 
> versions without application listener support seems to be v2.0.0 or earlier 
> which must have been announced EOL long ago and may have few users. But since 
> the critical export process will never be triggered if removed, I think it’s 
> ok to continue keep it.
> 
> To make sure I understand the change affect right, is the following and the 
> corresponding action right (for spring supports application listener)?
> 
> Export always being executed after Spring Context initialized properly 
> despite the delay value, and the delay times after that is:
> * delay=null, no delay
> * delay=0, no delay
> * delay=-1 or delay=-5000, no delay
> * delay=5000, delay for 5s.
> 
> Best regards,
> Jun
> 
>> On Nov 1, 2018, at 10:39 AM, Ian Luo 
>> mailto:ian@gmail.com>> wrote:
>> 
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>> 
>> I think this behavior is expected. The reason is, the best timing for Dubbo
>> to count down delay for exposing service is when Spring container is ready,
>> then this timing should be the moment when spring context gets refreshed,
>> since at this moment, all beans are settled, and are ready for wiring in
>> their dependencies. If it happens earlier, say, at the moment after
>> properties set, then Dubbo may fail to expose service because it depends on
>> other spring bean.
>> 
>> To conclude, Dubbo should start to expose services until spring context
>> gets refreshed, no matter delay or no-delay is configured. Unfortunately in
>> order to keep backward compatibility, considering not all spring versions
>> support context refresh callback, we have to start to expose services after
>> properties set if we find application listener is not supported, and hope
>> Dubbo service can be exposed normally.
>> 
>> I hope this can clarify the behavior.
>> 
>> -Ian.
>> 
>> 
>> 
>> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang 
>> mailto:y...@apache.org>> wrote:
>> 
>>> Hi,
>>> 
 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
 delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
>>> export 暴露服务
 delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>>> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
>>> 
 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>>> 
 这是我目前所发现的问题，不知道和你说的是不是同一个。
>>> 
>>> Yes, you are right.
>>> 
>>> yiji
>>> 
>>> 田 小波 mailto:tianxiaobo@outlook.com>> 
>>> 于2018年11月1日周四 上午1:25写道：
>>> 
 Hi,
 
 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
 
 delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
 export 暴露服务
 delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
 
 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
 supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
 afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
 毫秒暴露，而不是像之前被延迟到afterPrope

Re: pull request 2686

[田 小波]

Nice! if needed, May I help to update the doc about delay exposure when PR-2686 
is released at next release or later.

在 2018年11月2日，上午10:07，Ian Luo mailto:ian@gmail.com>> 写道：

To make sure I understand the change affect right, is the following and the 
corresponding action right (for spring supports application listener)?
Export always being executed after Spring Context initialized properly despite 
the delay value, and the delay times after that is:
* delay=null, no delay
* delay=0, no delay
* delay=-1 or delay=-5000, no delay
* delay=5000, delay for 5s.

Correct, this is what I understand too.

On Fri, Nov 2, 2018 at 9:51 AM jun liu 
mailto:ken.lj...@gmail.com>> wrote:
> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured.

+1, agree with this logic as the default for the export process.

>  Unfortunately in
> order to keep backward compatibility, considering not all spring versions
> support context refresh callback, we have to start to expose services after
> properties set if we find application listener is not supported, and hope
> Dubbo service can be exposed normally.

At first, I tend to remove the compatibility purpose snippet, because spring 
versions without application listener support seems to be v2.0.0 or earlier 
which must have been announced EOL long ago and may have few users. But since 
the critical export process will never be triggered if removed, I think it’s ok 
to continue keep it.

To make sure I understand the change affect right, is the following and the 
corresponding action right (for spring supports application listener)?

Export always being executed after Spring Context initialized properly despite 
the delay value, and the delay times after that is:
* delay=null, no delay
* delay=0, no delay
* delay=-1 or delay=-5000, no delay
* delay=5000, delay for 5s.

Best regards,
Jun

> On Nov 1, 2018, at 10:39 AM, Ian Luo 
> mailto:ian@gmail.com>> wrote:
>
>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>
> I think this behavior is expected. The reason is, the best timing for Dubbo
> to count down delay for exposing service is when Spring container is ready,
> then this timing should be the moment when spring context gets refreshed,
> since at this moment, all beans are settled, and are ready for wiring in
> their dependencies. If it happens earlier, say, at the moment after
> properties set, then Dubbo may fail to expose service because it depends on
> other spring bean.
>
> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured. Unfortunately in
> order to keep backward compatibility, considering not all spring versions
> support context refresh callback, we have to start to expose services after
> properties set if we find application listener is not supported, and hope
> Dubbo service can be exposed normally.
>
> I hope this can clarify the behavior.
>
> -Ian.
>
>
>
> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang 
> mailto:y...@apache.org>> wrote:
>
>> Hi,
>>
>>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
>>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
>> export 暴露服务
>>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
>>
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>>
>>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
>>
>> Yes, you are right.
>>
>> yiji
>>
>> 田 小波 mailto:tianxiaobo@outlook.com>> 
>> 于2018年11月1日周四 上午1:25写道：
>>
>>> Hi,
>>>
>>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
>>>
>>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
>>> export 暴露服务
>>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>>> 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
>>>
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>>>
>>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
>>>
>>> - xiaobo
>>>
>>> 在 2018年10月31日，下午10:43，Zonghai Shang 
>>> mailto:y...@apache.org>> 写道：
>>>
>>> Hi,
>>>
>>> 我认为这种修改会造成延迟暴露的bug。
>>> 如果要在容器启动10秒后才进行服务暴露怎么办？
>>> 原始意图delay= 1表示10秒后执行。
>>>
>>> I think this modification will cause a delay in the exposure of the bug.
>>> What if you want to expose the service 10 seconds after the spring
>>> container started ?
>>> The original intention delay = 1 represents execution after 10
>>> seconds.
>>>
>>> public s

Re: [ANN] New PPMC member: Shang Zonghai

[Xin Wang]

Congratulations!

Zonghai Shang  于2018年11月2日周五 上午10:09写道：

> Thanks, :-)
>
> -yiji
>
> Jerrick Zhu  于2018年11月2日周五 上午8:55写道：
>
> > Woo, that's awesome. The first new Dubbo PPMC.
> >
> > Expecting more committers to becoming PPMC.
> >
> > On Thu, Nov 1, 2018 at 10:54 PM Ian Luo  wrote:
> >
> > > Congratulations!
> > >
> > > On Thu, Nov 1, 2018 at 8:59 PM Huxing Zhang  wrote:
> > >
> > > > Hi, Community,
> > > >
> > > > On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> > > > Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
> > > >
> > > > Please join me to say congratulations to him!
> > > >
> > > > [1] https://github.com/zonghaishang
> > > > --
> > > > Best Regards！
> > > > Huxing
> > > >
> > >
> >
>

Re: [ANN] New PPMC member: Shang Zonghai

[Zonghai Shang]

Thanks, :-)

-yiji

Jerrick Zhu  于2018年11月2日周五 上午8:55写道：

> Woo, that's awesome. The first new Dubbo PPMC.
>
> Expecting more committers to becoming PPMC.
>
> On Thu, Nov 1, 2018 at 10:54 PM Ian Luo  wrote:
>
> > Congratulations!
> >
> > On Thu, Nov 1, 2018 at 8:59 PM Huxing Zhang  wrote:
> >
> > > Hi, Community,
> > >
> > > On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> > > Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
> > >
> > > Please join me to say congratulations to him!
> > >
> > > [1] https://github.com/zonghaishang
> > > --
> > > Best Regards！
> > > Huxing
> > >
> >
>

Re: pull request 2686

[Ian Luo]

>
> To make sure I understand the change affect right, is the following and
> the corresponding action right (for spring supports application listener)?
> Export always being executed after Spring Context initialized properly
> despite the delay value, and the delay times after that is:
> * delay=null, no delay
> * delay=0, no delay
> * delay=-1 or delay=-5000, no delay
> * delay=5000, delay for 5s.


Correct, this is what I understand too.

On Fri, Nov 2, 2018 at 9:51 AM jun liu  wrote:

> > To conclude, Dubbo should start to expose services until spring context
> > gets refreshed, no matter delay or no-delay is configured.
>
> +1, agree with this logic as the default for the export process.
>
> >  Unfortunately in
> > order to keep backward compatibility, considering not all spring versions
> > support context refresh callback, we have to start to expose services
> after
> > properties set if we find application listener is not supported, and hope
> > Dubbo service can be exposed normally.
>
> At first, I tend to remove the compatibility purpose snippet, because
> spring versions without application listener support seems to be v2.0.0 or
> earlier which must have been announced EOL long ago and may have few users.
> But since the critical export process will never be triggered if removed, I
> think it’s ok to continue keep it.
>
> To make sure I understand the change affect right, is the following and
> the corresponding action right (for spring supports application listener)?
>
> Export always being executed after Spring Context initialized properly
> despite the delay value, and the delay times after that is:
> * delay=null, no delay
> * delay=0, no delay
> * delay=-1 or delay=-5000, no delay
> * delay=5000, delay for 5s.
>
> Best regards,
> Jun
>
> > On Nov 1, 2018, at 10:39 AM, Ian Luo  wrote:
> >
> >> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> > supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
> > afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> > 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> >
> > I think this behavior is expected. The reason is, the best timing for
> Dubbo
> > to count down delay for exposing service is when Spring container is
> ready,
> > then this timing should be the moment when spring context gets refreshed,
> > since at this moment, all beans are settled, and are ready for wiring in
> > their dependencies. If it happens earlier, say, at the moment after
> > properties set, then Dubbo may fail to expose service because it depends
> on
> > other spring bean.
> >
> > To conclude, Dubbo should start to expose services until spring context
> > gets refreshed, no matter delay or no-delay is configured. Unfortunately
> in
> > order to keep backward compatibility, considering not all spring versions
> > support context refresh callback, we have to start to expose services
> after
> > properties set if we find application listener is not supported, and hope
> > Dubbo service can be exposed normally.
> >
> > I hope this can clarify the behavior.
> >
> > -Ian.
> >
> >
> >
> > On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang  wrote:
> >
> >> Hi,
> >>
> >>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> >>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
> >> export 暴露服务
> >>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
> >> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
> >>
> >>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> >> supportedApplicationListener = true 时，export 会被 onApplicationEvent
> 调用，而不是
> >> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> >> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> >>
> >>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
> >>
> >> Yes, you are right.
> >>
> >> yiji
> >>
> >> 田 小波  于2018年11月1日周四 上午1:25写道：
> >>
> >>> Hi,
> >>>
> >>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> >>>
> >>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
> >>> export 暴露服务
> >>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
> >>> 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
> >>>
> >>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> >>> supportedApplicationListener = true 时，export 会被 onApplicationEvent
> 调用，而不是
> >>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> >>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> >>>
> >>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
> >>>
> >>> - xiaobo
> >>>
> >>> 在 2018年10月31日，下午10:43，Zonghai Shang  写道：
> >>>
> >>> Hi,
> >>>
> >>> 我认为这种修改会造成延迟暴露的bug。
> >>> 如果要在容器启动10秒后才进行服务暴露怎么办？
> >>> 原始意图delay= 1表示10秒后执行。
> >>>
> >>> I think this modification will cause a delay in the exposure of the
> bug.
> >>> What if you want to expose the service 10 seconds after the spring
> >>> container started ?
> >>> The original intention delay = 1 represents execution after 10
> >>> seconds.
> >>>
> >>> public synchronized void export() {
> >>>if (delay != null && delay > 0) {
> >>>   

Re: pull request 2686

[jun liu]

> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured. 

+1, agree with this logic as the default for the export process. 

>  Unfortunately in
> order to keep backward compatibility, considering not all spring versions
> support context refresh callback, we have to start to expose services after
> properties set if we find application listener is not supported, and hope
> Dubbo service can be exposed normally.

At first, I tend to remove the compatibility purpose snippet, because spring 
versions without application listener support seems to be v2.0.0 or earlier 
which must have been announced EOL long ago and may have few users. But since 
the critical export process will never be triggered if removed, I think it’s ok 
to continue keep it.

To make sure I understand the change affect right, is the following and the 
corresponding action right (for spring supports application listener)? 

Export always being executed after Spring Context initialized properly despite 
the delay value, and the delay times after that is:
* delay=null, no delay
* delay=0, no delay
* delay=-1 or delay=-5000, no delay
* delay=5000, delay for 5s.

Best regards,
Jun

> On Nov 1, 2018, at 10:39 AM, Ian Luo  wrote:
> 
>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> 
> I think this behavior is expected. The reason is, the best timing for Dubbo
> to count down delay for exposing service is when Spring container is ready,
> then this timing should be the moment when spring context gets refreshed,
> since at this moment, all beans are settled, and are ready for wiring in
> their dependencies. If it happens earlier, say, at the moment after
> properties set, then Dubbo may fail to expose service because it depends on
> other spring bean.
> 
> To conclude, Dubbo should start to expose services until spring context
> gets refreshed, no matter delay or no-delay is configured. Unfortunately in
> order to keep backward compatibility, considering not all spring versions
> support context refresh callback, we have to start to expose services after
> properties set if we find application listener is not supported, and hope
> Dubbo service can be exposed normally.
> 
> I hope this can clarify the behavior.
> 
> -Ian.
> 
> 
> 
> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang  wrote:
> 
>> Hi,
>> 
>>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
>>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
>> export 暴露服务
>>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
>> 
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>> 
>>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
>> 
>> Yes, you are right.
>> 
>> yiji
>> 
>> 田 小波  于2018年11月1日周四 上午1:25写道：
>> 
>>> Hi,
>>> 
>>> 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
>>> 
>>> delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由 onApplicationEvent 调用
>>> export 暴露服务
>>> delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
>>> 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
>>> 
>>> 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
>>> supportedApplicationListener = true 时，export 会被 onApplicationEvent 调用，而不是
>>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
>>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
>>> 
>>> 这是我目前所发现的问题，不知道和你说的是不是同一个。
>>> 
>>> - xiaobo
>>> 
>>> 在 2018年10月31日，下午10:43，Zonghai Shang  写道：
>>> 
>>> Hi,
>>> 
>>> 我认为这种修改会造成延迟暴露的bug。
>>> 如果要在容器启动10秒后才进行服务暴露怎么办？
>>> 原始意图delay= 1表示10秒后执行。
>>> 
>>> I think this modification will cause a delay in the exposure of the bug.
>>> What if you want to expose the service 10 seconds after the spring
>>> container started ?
>>> The original intention delay = 1 represents execution after 10
>>> seconds.
>>> 
>>> public synchronized void export() {
>>>if (delay != null && delay > 0) {
>>>   // should be delay, eg: 1 seconds
>>>delayExportExecutor.schedule(new Runnable() {
>>>@Override
>>>public void run() {
>>>doExport();
>>>}
>>>}, delay, TimeUnit.MILLISECONDS);
>>>} else {
>>>doExport();
>>>}
>>> }
>>> 
>>> yiji
>>> 
>>> Ian Luo  于2018年10月31日周三 下午5:50写道：
>>> 
 good good study, day day up. Looking forward to your contribution :)
 
 On Wed, Oct 31, 2018 at 4:43 PM 田 小波 
>> wrote:
 
> Yes, in fact, It is a plan. I'm learning Dubbo code by writing blogs
 way,
> It can make me understand Dubbo code deeply. So, I need to finish my
 blogs
> first before doing other t

Re: Advice to the package name refactor of version 2.7.0

[Jerrick Zhu]

@RQ, your concern is necessary. Other compatible test works need to do, the
more, the better.

On Thu, Nov 1, 2018 at 7:23 PM RQ  wrote:

> Correct.  I just was worried that Dubbo may transfer those object on
> remoting layer because of  some mistaked memory .
>
> However, now the worries seems unnecessary after do some testings between
> 2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
> classes DubboCodec,
> I found that dubbo remoting protocol don't put RpcInvocation directly as
> byte streams, insteadly only the business object is serialized and others
> metada info is processes as String bytes.  So please ingore this
> discussion.
>
> BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
> DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
> problem.
>
> Thanks
> Jeff
>
>
>
>
> Ian Luo  于2018年11月1日周四 下午5:51写道：
>
> > So basically you are concerning on inter-op compatibility among the
> > different Dubbo instances?
> >
> > Thanks,
> > -Ian.
> >
> > On Thu, Nov 1, 2018 at 4:34 PM RQ  wrote:
> >
> >> Hi Community,
> >>
> >> I saw that it is the biggest version since into Apache Community with
> >> great
> >> changes  which include the package names renamed to *org.apache.dubbo.*
> >>
> >> For this part of changes, the compatibility upward is what we care
> mostly.
> >> Here are two types of scenses we should keep it as legacy interfaces.
> >> 1) the interfaces or classes that Dubbo's users use in the application.
> >> Currently, it is ok.
> >> 2) the tranfer classes  that is serializable in remoting layer. such as
> >> RpcInvocation. We should keep the old package for communication between
> >> vesion 2.7 and version older than 2.7. I saw that this part of refactor
> >> should be think twice in version 2.7.
> >>
> >> Please correct my views if I misunderstood.
> >>
> >> Regards
> >> Thanks.
> >>
> >
>

Re: [ANN] New PPMC member: Shang Zonghai

[Jerrick Zhu]

Woo, that's awesome. The first new Dubbo PPMC.

Expecting more committers to becoming PPMC.

On Thu, Nov 1, 2018 at 10:54 PM Ian Luo  wrote:

> Congratulations!
>
> On Thu, Nov 1, 2018 at 8:59 PM Huxing Zhang  wrote:
>
> > Hi, Community,
> >
> > On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> > Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
> >
> > Please join me to say congratulations to him!
> >
> > [1] https://github.com/zonghaishang
> > --
> > Best Regards！
> > Huxing
> >
>

Re: Dubbo 2.6.2 triggers conflict with SkyWalking

[Ian Luo]

just merged, all looks good.

-Ian.

On Thu, Nov 1, 2018 at 5:54 PM jun liu  wrote:

> Just fixed: redundant disable() method removed in both PRs.
>
> @Documented
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> public @interface DisableInject {
> }
>
>
> Best regards,
> Jun
>
> > On Nov 1, 2018, at 5:49 PM, Ian Luo  wrote:
> >
> > Jun,
> >
> > I dropped a quick review comments on your PR just now. IMO, a marker
> > annotation should work fine. This is the only review comment I've had so
> > far.
> >
> > Thanks,
> > -Ian.
> >
> >
> > On Thu, Nov 1, 2018 at 4:45 PM jun liu  wrote:
> >
> >> Hi, Ian
> >>
> >> I just updated this PR
> >> https://github.com/apache/incubator-dubbo/pull/2681 <
> >> https://github.com/apache/incubator-dubbo/pull/2681> following your
> >> suggestions, could you help to check it again?
> >>
> >> Remember there’s another PR
> >> https://github.com/apache/incubator-dubbo/pull/2682 <
> >> https://github.com/apache/incubator-dubbo/pull/2682> for master branch.
> >>
> >> Best regards,
> >> Jun
> >>
> >>> On Oct 24, 2018, at 12:30 PM, jun liu  wrote:
> >>>
> >>> I have created a patch[1] to fix this problem, briefly changes:
> >>> * Add optional Inject annotation for developers to decide open
> >> auto-injection or not.
> >>> * Printing log instead of throwing Exception in SpringExtensionFactory
> >> when multi-extension or no extension found.
> >>>
> >>> 1. https://github.com/apache/incubator-dubbo/pull/2681 <
> >> https://github.com/apache/incubator-dubbo/pull/2681>
> >>>
> >>> Best regards,
> >>> Jun
> >>>
>  On Oct 23, 2018, at 11:01 AM, Sheng Wu  >> wush...@apache.org>> wrote:
> 
>  Hi
> 
>  I am moving a SkyWalking bug report[1] to here. SkyWalking supports
> >> Dubbo for a long time and works well. But recent days, people begin to
> >> report bug of monitoring Dubbo 2.6.2, looks like added some mechanism to
> >> make the conflicts.
> 
>  Could you go to the issue I post, we could continue the discussion
> >> there? Why add those new codes and what is the solution for supporting
> >> dubbo from SkyWalking.
> 
>  [1] https://github.com/apache/incubator-skywalking/issues/1769 <
> >> https://github.com/apache/incubator-skywalking/issues/1769>
> 
>  Sheng Wu
>  SkyWalking
> >>>
> >>
> >>
>
>

Re: [ANN] New PPMC member: Shang Zonghai

[Ian Luo]

Congratulations!

On Thu, Nov 1, 2018 at 8:59 PM Huxing Zhang  wrote:

> Hi, Community,
>
> On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
>
> Please join me to say congratulations to him!
>
> [1] https://github.com/zonghaishang
> --
> Best Regards！
> Huxing
>

回复：[ANN] New PPMC member: Shang Zonghai

[马金凯]

Congratulations！！








 信息中心 龙齿 马金凯 
韩都衣舍电子商务集团股份有限公司  
 电话：15806675757 
 邮箱：majin...@dingtalk.com 
 地址：奥盛大厦 
 
 韩都衣舍电子商务集团股份有限公司企业主页 
 信息安全声明：本邮件包含信息归发件人所在组织所有，发件人所在组织对该邮件拥有所有权利。
请接收者注意保密，未经发件人书面许可，不得向任何第三方组织和个人透露本邮件所含信息的全部或部分。以上声明仅适用于工作邮件。
Information Security Notice: The information contained in this mail is solely 
property of the sender's organization. 
This mail communication is confidential. Recipients named above are obligated 
to maintain secrecy and are not permitted to disclose the contents of this 
communication to others.  
--
发件人：Huxing Zhang
日　期：2018年11月01日 20:58:46
收件人：dev
主　题：[ANN] New PPMC member: Shang Zonghai

Hi, Community,

On behalf of the Dubbo PPMC, I am pleased to announce that Shang
Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.

Please join me to say congratulations to him!

[1] https://github.com/zonghaishang
-- 
Best Regards！
Huxing

Re: [ANN] New PPMC member: Shang Zonghai

[yuhang xiu]

Congratulations!
:)

Huxing Zhang  于2018年11月1日周四 下午8:59写道：

> Hi, Community,
>
> On behalf of the Dubbo PPMC, I am pleased to announce that Shang
> Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.
>
> Please join me to say congratulations to him!
>
> [1] https://github.com/zonghaishang
> --
> Best Regards！
> Huxing
>

[ANN] New PPMC member: Shang Zonghai

[Huxing Zhang]

Hi, Community,

On behalf of the Dubbo PPMC, I am pleased to announce that Shang
Zonghai, aka yiji[1], has been voted in as a new Dubbo PPMC member.

Please join me to say congratulations to him!

[1] https://github.com/zonghaishang
-- 
Best Regards！
Huxing

Fix disable provider does’t work.

[Zonghai Shang]

Hi,

I found that the dubbo service was still called after it was disabled. I
analyzed and fixed this problem.

This is my pull request:
https://github.com/apache/incubator-dubbo/pull/2729

Please help me check again, thanks.

-yiji

Re: Advice to the package name refactor of version 2.7.0

[RQ]

Correct.  I just was worried that Dubbo may transfer those object on
remoting layer because of  some mistaked memory .

However, now the worries seems unnecessary after do some testings between
2.7.0 and 2.6.3. I just dive into the code of Dubbo, espically the
classes DubboCodec,
I found that dubbo remoting protocol don't put RpcInvocation directly as
byte streams, insteadly only the business object is serialized and others
metada info is processes as String bytes.  So please ingore this discussion.

BTW I remembered Dubbo of version 1.x which is only used inside Alibaba put
DubboRequest/DubboResponse directly and Dubbo2.x is apperantly not this
problem.

Thanks
Jeff




Ian Luo  于2018年11月1日周四 下午5:51写道：

> So basically you are concerning on inter-op compatibility among the
> different Dubbo instances?
>
> Thanks,
> -Ian.
>
> On Thu, Nov 1, 2018 at 4:34 PM RQ  wrote:
>
>> Hi Community,
>>
>> I saw that it is the biggest version since into Apache Community with
>> great
>> changes  which include the package names renamed to *org.apache.dubbo.*
>>
>> For this part of changes, the compatibility upward is what we care mostly.
>> Here are two types of scenses we should keep it as legacy interfaces.
>> 1) the interfaces or classes that Dubbo's users use in the application.
>> Currently, it is ok.
>> 2) the tranfer classes  that is serializable in remoting layer. such as
>> RpcInvocation. We should keep the old package for communication between
>> vesion 2.7 and version older than 2.7. I saw that this part of refactor
>> should be think twice in version 2.7.
>>
>> Please correct my views if I misunderstood.
>>
>> Regards
>> Thanks.
>>
>

Re: Dubbo 2.6.2 triggers conflict with SkyWalking

[jun liu]

Just fixed: redundant disable() method removed in both PRs.
 
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface DisableInject {
}


Best regards,
Jun

> On Nov 1, 2018, at 5:49 PM, Ian Luo  wrote:
> 
> Jun,
> 
> I dropped a quick review comments on your PR just now. IMO, a marker
> annotation should work fine. This is the only review comment I've had so
> far.
> 
> Thanks,
> -Ian.
> 
> 
> On Thu, Nov 1, 2018 at 4:45 PM jun liu  wrote:
> 
>> Hi, Ian
>> 
>> I just updated this PR
>> https://github.com/apache/incubator-dubbo/pull/2681 <
>> https://github.com/apache/incubator-dubbo/pull/2681> following your
>> suggestions, could you help to check it again?
>> 
>> Remember there’s another PR
>> https://github.com/apache/incubator-dubbo/pull/2682 <
>> https://github.com/apache/incubator-dubbo/pull/2682> for master branch.
>> 
>> Best regards,
>> Jun
>> 
>>> On Oct 24, 2018, at 12:30 PM, jun liu  wrote:
>>> 
>>> I have created a patch[1] to fix this problem, briefly changes:
>>> * Add optional Inject annotation for developers to decide open
>> auto-injection or not.
>>> * Printing log instead of throwing Exception in SpringExtensionFactory
>> when multi-extension or no extension found.
>>> 
>>> 1. https://github.com/apache/incubator-dubbo/pull/2681 <
>> https://github.com/apache/incubator-dubbo/pull/2681>
>>> 
>>> Best regards,
>>> Jun
>>> 
 On Oct 23, 2018, at 11:01 AM, Sheng Wu > wush...@apache.org>> wrote:
 
 Hi
 
 I am moving a SkyWalking bug report[1] to here. SkyWalking supports
>> Dubbo for a long time and works well. But recent days, people begin to
>> report bug of monitoring Dubbo 2.6.2, looks like added some mechanism to
>> make the conflicts.
 
 Could you go to the issue I post, we could continue the discussion
>> there? Why add those new codes and what is the solution for supporting
>> dubbo from SkyWalking.
 
 [1] https://github.com/apache/incubator-skywalking/issues/1769 <
>> https://github.com/apache/incubator-skywalking/issues/1769>
 
 Sheng Wu
 SkyWalking
>>> 
>> 
>> 

Re: Advice to the package name refactor of version 2.7.0

[Ian Luo]

So basically you are concerning on inter-op compatibility among the
different Dubbo instances?

Thanks,
-Ian.

On Thu, Nov 1, 2018 at 4:34 PM RQ  wrote:

> Hi Community,
>
> I saw that it is the biggest version since into Apache Community with great
> changes  which include the package names renamed to *org.apache.dubbo.*
>
> For this part of changes, the compatibility upward is what we care mostly.
> Here are two types of scenses we should keep it as legacy interfaces.
> 1) the interfaces or classes that Dubbo's users use in the application.
> Currently, it is ok.
> 2) the tranfer classes  that is serializable in remoting layer. such as
> RpcInvocation. We should keep the old package for communication between
> vesion 2.7 and version older than 2.7. I saw that this part of refactor
> should be think twice in version 2.7.
>
> Please correct my views if I misunderstood.
>
> Regards
> Thanks.
>

Re: Dubbo 2.6.2 triggers conflict with SkyWalking

[Ian Luo]

Jun,

I dropped a quick review comments on your PR just now. IMO, a marker
annotation should work fine. This is the only review comment I've had so
far.

Thanks,
-Ian.


On Thu, Nov 1, 2018 at 4:45 PM jun liu  wrote:

> Hi, Ian
>
> I just updated this PR
> https://github.com/apache/incubator-dubbo/pull/2681 <
> https://github.com/apache/incubator-dubbo/pull/2681> following your
> suggestions, could you help to check it again?
>
> Remember there’s another PR
> https://github.com/apache/incubator-dubbo/pull/2682 <
> https://github.com/apache/incubator-dubbo/pull/2682> for master branch.
>
> Best regards,
> Jun
>
> > On Oct 24, 2018, at 12:30 PM, jun liu  wrote:
> >
> > I have created a patch[1] to fix this problem, briefly changes:
> > * Add optional Inject annotation for developers to decide open
> auto-injection or not.
> > * Printing log instead of throwing Exception in SpringExtensionFactory
> when multi-extension or no extension found.
> >
> > 1. https://github.com/apache/incubator-dubbo/pull/2681 <
> https://github.com/apache/incubator-dubbo/pull/2681>
> >
> > Best regards,
> > Jun
> >
> >> On Oct 23, 2018, at 11:01 AM, Sheng Wu  wush...@apache.org>> wrote:
> >>
> >> Hi
> >>
> >> I am moving a SkyWalking bug report[1] to here. SkyWalking supports
> Dubbo for a long time and works well. But recent days, people begin to
> report bug of monitoring Dubbo 2.6.2, looks like added some mechanism to
> make the conflicts.
> >>
> >> Could you go to the issue I post, we could continue the discussion
> there? Why add those new codes and what is the solution for supporting
> dubbo from SkyWalking.
> >>
> >> [1] https://github.com/apache/incubator-skywalking/issues/1769 <
> https://github.com/apache/incubator-skywalking/issues/1769>
> >>
> >> Sheng Wu
> >> SkyWalking
> >
>
>

Re: Dubbo 2.6.2 triggers conflict with SkyWalking

[jun liu]

Hi, Ian

I just updated this PR  https://github.com/apache/incubator-dubbo/pull/2681 
 following your 
suggestions, could you help to check it again?

Remember there’s another PR https://github.com/apache/incubator-dubbo/pull/2682 
 for master branch.

Best regards,
Jun

> On Oct 24, 2018, at 12:30 PM, jun liu  wrote:
> 
> I have created a patch[1] to fix this problem, briefly changes:
> * Add optional Inject annotation for developers to decide open auto-injection 
> or not.
> * Printing log instead of throwing Exception in SpringExtensionFactory when 
> multi-extension or no extension found.
> 
> 1. https://github.com/apache/incubator-dubbo/pull/2681 
> 
> 
> Best regards,
> Jun
> 
>> On Oct 23, 2018, at 11:01 AM, Sheng Wu > > wrote:
>> 
>> Hi 
>> 
>> I am moving a SkyWalking bug report[1] to here. SkyWalking supports Dubbo 
>> for a long time and works well. But recent days, people begin to report bug 
>> of monitoring Dubbo 2.6.2, looks like added some mechanism to make the 
>> conflicts.
>> 
>> Could you go to the issue I post, we could continue the discussion there? 
>> Why add those new codes and what is the solution for supporting dubbo from 
>> SkyWalking.
>> 
>> [1] https://github.com/apache/incubator-skywalking/issues/1769 
>> 
>> 
>> Sheng Wu
>> SkyWalking
> 

Advice to the package name refactor of version 2.7.0

[RQ]

Hi Community,

I saw that it is the biggest version since into Apache Community with great
changes  which include the package names renamed to *org.apache.dubbo.*

For this part of changes, the compatibility upward is what we care mostly.
Here are two types of scenses we should keep it as legacy interfaces.
1) the interfaces or classes that Dubbo's users use in the application.
Currently, it is ok.
2) the tranfer classes  that is serializable in remoting layer. such as
RpcInvocation. We should keep the old package for communication between
vesion 2.7 and version older than 2.7. I saw that this part of refactor
should be think twice in version 2.7.

Please correct my views if I misunderstood.

Regards
Thanks.

Re: pull request 2686

[Zonghai Shang]

:-)  My understanding is wrong, and keeping the delayed exposure was what I
expected.

yiji

Ian Luo  于2018年11月1日周四 下午1:23写道：

> I cannot agree with it. This code is necessary for delay expose.
>
> On Thu, Nov 1, 2018 at 12:01 PM Zonghai Shang  wrote:
>
> > Hi,
> >
> > org.apache.dubbo.config.ServiceConfig#export :
> >
> > ```
> >
> > if (delay != null && delay > 0) {
> > delayExportExecutor.schedule(new Runnable() {
> > @Override
> > public void run() {
> > doExport();
> > }
> > }, delay, TimeUnit.MILLISECONDS);
> > }
> >
> > ```
> >
> > If compatibility is not a consideration, this code is appropriate to
> delete
> >
> > -yiji
> >
> > Ian Luo  于2018年11月1日周四 上午11:48写道：
> >
> > > Folks, pls. also shine your thought on this particular topic.
> > >
> > > Thanks,
> > > -Ian.
> > >
> > > On Thu, Nov 1, 2018 at 11:16 AM 田 小波 
> wrote:
> > >
> > > > Last night, I thought deeply the timing of Dubbo expose service. And
> I
> > > > also think It is more reasonable to expose service after Spring
> ready.
> > > >
> > > > -xiaobo
> > > >
> > > > 在 2018年11月1日，上午11:12，Ian Luo  写道：
> > > >
> > > > pls. always loop in dev@dubbo.apache.org to discuss :)
> > > >
> > > > On Thu, Nov 1, 2018 at 11:07 AM 田 小波 
> > wrote:
> > > >
> > > >> Last night, I thought deeply the timing of Dubbo expose service. I
> > think
> > > >> It is more reasonable to expose service after Spring ready.
> > > >>
> > > >> -xiaobo
> > > >>
> > > >> 在 2018年11月1日，上午10:39，Ian Luo  写道：
> > > >>
> > > >> > 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> > > >> supportedApplicationListener = true 时，export 会被 onApplicationEvent
> > > 调用，而不是
> > > >> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> > > >> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> > > >>
> > > >> I think this behavior is expected. The reason is, the best timing
> for
> > > >> Dubbo to count down delay for exposing service is when Spring
> > container
> > > is
> > > >> ready, then this timing should be the moment when spring context
> gets
> > > >> refreshed, since at this moment, all beans are settled, and are
> ready
> > > for
> > > >> wiring in their dependencies. If it happens earlier, say, at the
> > moment
> > > >> after properties set, then Dubbo may fail to expose service because
> it
> > > >> depends on other spring bean.
> > > >>
> > > >> To conclude, Dubbo should start to expose services until spring
> > context
> > > >> gets refreshed, no matter delay or no-delay is configured.
> > > Unfortunately in
> > > >> order to keep backward compatibility, considering not all spring
> > > versions
> > > >> support context refresh callback, we have to start to expose
> services
> > > after
> > > >> properties set if we find application listener is not supported, and
> > > hope
> > > >> Dubbo service can be exposed normally.
> > > >>
> > > >> I hope this can clarify the behavior.
> > > >>
> > > >> -Ian.
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Nov 1, 2018 at 10:03 AM Zonghai Shang 
> > wrote:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> > 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> > > >>> > delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由
> > onApplicationEvent
> > > 调用
> > > >>> export 暴露服务
> > > >>> > delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
> > > >>> 时算起，此时由 afterPropertiesSet 调用 export暴露服务
> > > >>>
> > > >>> > 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> > > >>> supportedApplicationListener = true 时，export 会被 onApplicationEvent
> > > 调用，而不是
> > > >>> afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> > > >>> 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> > > >>>
> > > >>> > 这是我目前所发现的问题，不知道和你说的是不是同一个。
> > > >>>
> > > >>> Yes, you are right.
> > > >>>
> > > >>> yiji
> > > >>>
> > > >>> 田 小波  于2018年11月1日周四 上午1:25写道：
> > > >>>
> > > >>> > Hi,
> > > >>> >
> > > >>> > 我重新看了代码和文档，发现确实存在一个延迟暴露的问题。这里先列举 Dubbo 的延迟暴露策略：
> > > >>> >
> > > >>> > delay = null 或 delay = -1 ：延迟到 Spring 容器就绪后暴露服务，由
> > onApplicationEvent
> > > 调用
> > > >>> > export 暴露服务
> > > >>> > delay > 0 ：延迟指定毫秒后暴露服务，时间从 afterPropertiesSet 调用 export
> > > >>> > 时算起，此时由 afterPropertiesSet 调用 export 暴露服务
> > > >>> >
> > > >>> > 当代码修改后，由于 afterPropertiesSet 不再对 delay 进行校验。导致当 delay > 0，且
> > > >>> > supportedApplicationListener = true 时，export 会被
> onApplicationEvent
> > > >>> 调用，而不是
> > > >>> > afterPropertiesSet。这会造成服务被延迟到 Spring 容器就绪后的 delay
> > > >>> > 毫秒暴露，而不是像之前被延迟到afterPropertiesSet 调用 export 后的 delay 毫秒暴露。
> > > >>> >
> > > >>> > 这是我目前所发现的问题，不知道和你说的是不是同一个。
> > > >>> >
> > > >>> > - xiaobo
> > > >>> >
> > > >>> > 在 2018年10月31日，下午10:43，Zonghai Shang  写道：
> > > >>> >
> > > >>> > Hi,
> > > >>> >
> > > >>> > 我认为这种修改会造成延迟暴露的bug。
> > > >>> > 如果要在容器启动10秒后才进行服务暴露怎么办？
> > > >>> > 原始意图delay= 1表示10秒后执行。
> > > >>> >
> > > >>> > I think this modification will cause a delay in the exposure of
> the
> > > >>> bug.
> > > >>> > What if you want to expose the service 10 seconds after the
> spring
> > > >>> > con

[DISCUSS] issue 2541: Lack of HealthCheck ,we need it

[Ian Luo]

Hi Folks,

Recently Longfei (@stoneapple) from ICBU SDC raised one interesting topic
against health check on issue 2541 [1]. Here below I list the brief
discussion thread on this issue:

@stoneapple:

> Currently Dubbo does not have the ability of readiness check and that is
> somehow very helpful and needed in production env.
> Does dubbo team has any plans on it ? can you show some detail design
> drafts ?
> Our team currently is planing to add the healthcheck ability on dubbo , so
> we want to know dubbo team's opinion , if ok , we may give a pr on this
> topic.


@kimmking

> @stoneapple It's a nice way to describe more details for your idea.


@stoneapple

> we know dubbo have the delay exposed ability, sometimes delay time is not
> easy to figure out. Also we may want to check other resources like db,cache
> before we exposed our service to meet the business trade.


@beiwei30

> @stoneapple if you have good idea for builtin /health service, pls. simply
> submit a pull request :) From the point of view of Dubbo, it sounds like
> Dubbo can only provide readiness for dubbo services only.


@zonghaishang

> 我这边提供一个思路看看是否可行，实现一个最低优先级的ServiceBean,
> 在这里拿到所有spring上下文ServiceBean的名字(BeanFactoryUtils.beansOfTypeIncludingAncestors(applicationContext,
> ServiceBean.class, false, false)),
> 每次在服务export时把成功暴露的bean从map剔除，在最后一个低优先级servicebean中检查没有正确暴露服务。


@beiwei30

> what I propose is to provide a builtin health service which expose metrics
> data to the user, from which at lease user can easily to learn whether all
> other services are UP or not.


If you are interested in this, pls. check the whole discussion directly on
GitHub.

Longfei, if you happen to read this mail, would you like to share us your
design here, then we can further discuss based on your proposal?

Others, this feature is quite critical for micro service governance, I'd
like also hear from you. Feel free to discuss in mailing list, or propose
your thought directly on GitHub issue.

Thanks,
-Ian.


1. https://github.com/apache/incubator-dubbo/issues/2541