Re: Filter problems in async way

[Ian Luo]

Since filter may execute its methods in different threads, first of all we
cannot use thread local to pass the information. Because of this, this
leads us no room but method parameters, in this case, they are invoker and
invocation, to store and extract the extra info when necessary. Based on
this, it looks to me attachment is a reasonable solution.

What we need to think further if timeoutFilter's TIMEOUT_FILTER_START_TIME
needs to be transferred on the wire. If not, we may need to consider how we
can avoid of the transfer but still be able to fetch it in onResponse().

Any thoughts on this?

-Ian.


On Mon, Feb 18, 2019 at 9:30 PM yuhang xiu  wrote:

> Hi,ian
>
> Several reasons:
> 1. It seems that the attachment is based on the convention. We need to put
> the information other than the rpc parameter into the attachment. We need
> to ensure that the information and the temporary information (start in the
> timeoutFilter) do not overlap.
> 2. The attachment field may be null. This allows us to make some additional
> judgments and processing before we can use the attachment field:
>
> if (invocation.getAttachments() != null) {
> long start = System.currentTimeMillis();
> invocation.getAttachments().put(TIMEOUT_FILTER_START_TIME,
> String.valueOf(start));
> } else {
> if (invocation instanceof RpcInvocation) {
> RpcInvocation invc = (RpcInvocation) invocation;
> long start = System.currentTimeMillis();
> invc.setAttachment(TIMEOUT_FILTER_START_TIME,
> String.valueOf(start));
> }
> }
>
> I am still thinking about this issue recently. It seems that the extra
> tempAttachment needs to increase the cost of the transmission.
> So I have some hesitation about using tempAttachment. How do you think
> about this problem?
>
> Ian Luo  于2019年2月18日周一 下午6:26写道：
>
> > Yuhang,
> >
> > Why it's a bad idea to use invocation#attachments to store the temp data?
> >
> > Thanks,
> > -Ian.
> >
> >
> > On Fri, Feb 15, 2019 at 2:55 PM yuhang xiu  wrote:
> >
> > > Hi, everyone
> > >
> > > Recently, I found that dubbo does not handle the data generated during
> > the
> > > call process when it is asynchronous.
> > >
> > > For example, in TimeoutFilter, we used invocation#attachments to hold
> the
> > > data that needs to be passed (start time in TimeoutFilter). But I don't
> > > think this way is good, although using Invocation.attachments to pass
> > data
> > > does not pollute RpcContext.
> > >
> > > Perhaps a better way is to add a temporary attachment to the Invocation
> > > that only maintains the temporary data generated during the call.
> > >
> > > In addition, I found that we still have a few Filters that are
> currently
> > > problematic in asynchronous scenarios, such as:
> > >
> > > * ActiveLimitFilter
> > > * TraceFilter
> > >
> > > We should determine a plan as soon as possible and then proceed to fix
> > > these Filters.
> > >
> >
>

Proposal for releasing hessian-lite 3.2.5

[Minxuan Zhuang]

Hello Dubbo Community,
   since the last release of hessian-lite, some issues have been fixed, so
I suggest to release version 3.2.5, the branch is:
https://github.com/dubbo/hessian-lite/tree/3.2.5
release note:
https://github.com/dubbo/hessian-lite/releases/tag/v3.2.5

what do you think?

Bring Authorization to Dubbo OPS

[柯振旭]

HI Dubbo Comunity:
  There is no authorization or authentication in the current version of 
dubbo-ops and it's open to all users,
so I'm planing to bring authorization to dubbo-ops[1] for the sake of security, 
here is my thought:


1. provide a simple authorization implementation(for example Spring Security?) 
[2]
2. use SPI pattern so that users can change to other authorization machanisms


any advice is appreciated, thanks :)


[1] https://github.com/apache/incubator-dubbo-ops/issues/210 
[2] https://github.com/apache/incubator-dubbo-ops/issues/204

Fwd: JDK 12: First Release Candidate available

[Huxing Zhang]

Forwarding to Dubbo dev mailing list.
Early investigation on JDK 12 support for Dubbo could be started if
someone is interested.

-- Forwarded message -
From: Rory O'Donnell 
Date: Mon, Feb 18, 2019 at 7:50 PM
Subject: JDK 12: First Release Candidate available
To: 
Cc: , Dalibor Topic
, Balchandra Vaidya
, Muneer Kolarkunnu
, 


  Hi Mark,

**OpenJDK builds *- JDK 12 Early Access build 32 **is now available **at
: - jdk.java.net/12/*
**JDK 12:  First Release Candidate [1]**

  * Per the JDK 12 schedule [2], we are now in Release Candidate Phase.
  * The stabilization repository, jdk/jdk12, is open for P1 bug fixes
per the JDK Release Process (JEP 3) [3].
  * All changes require approval via the Fix-Request Process [4].
  *
Release note additions since last email

  o
Build 31 - can_pop_frame and can_force_early_return capabilities
are disabled if JVMCI compiler is used (JDK-8218025
) The JVMTI
|can_pop_frame| and |can_force_early_return| capabilities are
disabled if a JVMCI compiler (like Graal) is used. As a result
the corresponding functionality (|PopFrame| and
|ForceEarlyReturnXXX| functions) is not available to JVMTI
agents. This issue is being fixed via JDK-8218885

[https://bugs.openjdk.java.net/browse/JDK-8218885
].

  o Build 28: JDK-8212233
 : javadoc
fails on jdk12 with "The code being documented uses modules but
the packages defined in $URL are in the unnamed module."
  * Changes in this build.



**OpenJDK builds *- JDK 13 Early Access build 8 is **now available **at
: - jdk.java.net/13/*

  * These early-access, open-source builds are provided under the
  o GNU General Public License, version 2, with the Classpath
Exception .
  * Release Notes updates
  * Build 8
  o GraphicsEnvironment.getCenterPoint()/getMaximumWindowBounds()
are unified across the platforms (JDK-8214918
)
  o The experimental FIPS 140 compliant mode has been removed from
the SunJSSE provider. (JDK-8217835
)
  * Build 7
  o Change DOM parser to not resolve EntityReference and add Text
node with
DocumentBuilderFactory.setExpandEntityReferences(false)
(JDK-8206132 )
  * Build 6
  o Base64.Encoder and Base64.Decoder methods can throw
OutOfMemoryError (JDK-8210583
)
  * Changes in this build


  * FOSS Bugs fixed in recent builds
  o Build 6 : JDK-8216970
 : condy
causes JVM crash
  o Build 7: JDK-8215577
 : Remove
javadoc support for HTML 4


Rgds,Rory

[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-February/002623.html
[2] http://openjdk.java.net/projects/jdk/12/#Schedule
[3] http://openjdk.java.net/jeps/3
[4] http://openjdk.java.net/jeps/3#Fix-Request-Process

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland



-- 
Best Regards！
Huxing

Re: Bring Authorization to Dubbo OPS

[Minxuan Zhuang]

thanks for your interesting, Dubbo OPS do need an authorization for service
governance and service test, I think your advice is fine, please feel free
to send a pr

On Tue, Feb 19, 2019 at 2:06 PM 柯振旭  wrote:

> HI Dubbo Comunity:
>   There is no authorization or authentication in the current version of
> dubbo-ops and it's open to all users,
> so I'm planing to bring authorization to dubbo-ops[1] for the sake of
> security, here is my thought:
>
>
> 1. provide a simple authorization implementation(for example Spring
> Security?) [2]
> 2. use SPI pattern so that users can change to other authorization
> machanisms
>
>
> any advice is appreciated, thanks :)
>
>
> [1] https://github.com/apache/incubator-dubbo-ops/issues/210
> [2] https://github.com/apache/incubator-dubbo-ops/issues/204

Re: how to deal with two pull requests to solve the same issue

[Ian Luo]

It happens but I believe it's rare. If it does happen, I agree with the
ideas Huxing proposed.

Regards,
-Ian.

On Mon, Feb 18, 2019 at 5:39 PM yuhang xiu  wrote:

> Totally agree with huxing.
> In addition, we may be able to remind the authors of the two prs that their
> pr is repeated.
> This will let them review the code and leave a comment. In some cases,
> perhaps one of them will close their pr directly.
>
> Huxing Zhang  于2019年2月18日周一 下午5:28写道：
>
> > Hi,
> >
> > I remember I've seen this kind of issue before.
> >
> > From my point of view, I prefer the following precedence:
> > - check the implementation, the code quality requirement should be
> > satisfied.
> > - if the quality looks more or less the same, I usually check if
> > he/she is the first time contributor. I think we should be more
> > generous to new comers.
> >
>
> Can't agree more. We should involve more people. Getting more people to
> contribute to dubbo is very important for the dubbo community, and we
> should give this opportunity to newcomer.
>
>
> > - if the above condition is not met, I tend to use FIFO based on the
> > creation time of the pull request.
> >
> > This is my personal opinion, let's see what others might think.
> >
> > To avoid this issue, I do recommend people to leave a comment before
> > start contributing.
> >
> > On Mon, Feb 18, 2019 at 2:03 PM Minxuan Zhuang 
> > wrote:
> > >
> > > Hi Community,
> > >If two pull requests are aiming  to solve the same issue, how to
> > choose
> > > from them?
> >
> >
> >
> > --
> > Best Regards！
> > Huxing
> >
>

Re: version of Apache Dubbo OPS(Incubating)

[Ian Luo]

Totally agree, the schema MAJOR.MINOR.PATCH is common sense.

-Ian.

On Mon, Feb 18, 2019 at 5:30 PM Huxing Zhang  wrote:

> Hi,
>
>
> On Mon, Feb 18, 2019 at 4:11 PM Minxuan Zhuang 
> wrote:
> >
> > Hello Dubbo Community,
> >   The first dubbo ops has been released with version 0.1, usually the
> > apache project releases follow the format:  MAJOR.MINOR.PATCH, so I
> suggest
> > to use version 0.2.0 for the next release.
>
> +1 to use semantic versioning[1] for dubbo-admin.
>
> p.s. Didn't the community reach the consesus to use dubbo-admin instead? :)
>
> [1] https://semver.org/
> --
> Best Regards！
> Huxing
>

Re: ConsistentHash LoadBalance中的解释：缺省只对第一个参数进行Hash运算是什么意思？

[Ian Luo]

+1. I agree with Xiaobo and Jason.

-Ian.

On Thu, Feb 14, 2019 at 9:29 AM Jason Joo  wrote:

> +1
>
> Methods with no arguments or little possible values of arguments should
> not be applied `ConsistentHashLoadBalance`. Or requests can not be smoothly
> distributed when nodes change.
>
> best regards,
>
> Jason
>
> > On Feb 13, 2019, at 22:30, 田 小波  wrote:
> >
> > 数
>
>

Re: Non-apache releases and old releases

[Huxing Zhang]

Hi,

On Mon, Feb 18, 2019 at 1:25 PM Mercy  wrote:
>
> Hi,
>
>Sorry about the unannouced release that is a re-deploy caused by the
> incompatible issue of Maven, and it will appear again.

Can you explain this issue a bit more?
Will this re-deploy cause change to the source files?

I checked the ASF doc[1], it says:
In all such cases, the binary/bytecode package MUST have the same
version number as the source release and MUST only add binary/bytecode
files that are the result of compiling that version of the source code
release and its dependencies.

Due to the incompatible version number,  we should stop promoting it.
It is lucky to know that 2.7.0 has already been released, I checked
the version in both GitHub and website that it has been changed to
2.7.0.



[1] http://www.apache.org/legal/release-policy.html#compiled-packages


>
> Kind regards,
>
> Mercy Ma
>
> 在 2019/2/14 下午1:41, Huxing Zhang 写道:
> > I have checked the maven repo[3] again, I found there are two extra
> > release artifacts, 0.1.2.RELEASE and 0.2.1.RELEASE, I did not find any
> > discussion on the mailing list about it, we should stop doing things
> > like that.



--
Best Regards！
Huxing

Re: how to deal with two pull requests to solve the same issue

[Huxing Zhang]

Hi,

I remember I've seen this kind of issue before.

>From my point of view, I prefer the following precedence:
- check the implementation, the code quality requirement should be satisfied.
- if the quality looks more or less the same, I usually check if
he/she is the first time contributor. I think we should be more
generous to new comers.
- if the above condition is not met, I tend to use FIFO based on the
creation time of the pull request.

This is my personal opinion, let's see what others might think.

To avoid this issue, I do recommend people to leave a comment before
start contributing.

On Mon, Feb 18, 2019 at 2:03 PM Minxuan Zhuang  wrote:
>
> Hi Community,
>If two pull requests are aiming  to solve the same issue, how to choose
> from them?



--
Best Regards！
Huxing

Re: [DISCUSS] Next Dubbo meetup

[Minxuan Zhuang]

+1 for March 23rd
+1 for Nanjing

On Thu, Feb 14, 2019 at 2:41 PM jun liu  wrote:

> > Can we make it Mar 23rd? As our venue is available on that day.
>
> +1 for Mar. 23th, any time is ok for me.
>
> +1 for hosting in Nanjing.
>
> Jun
>
> > On Feb 12, 2019, at 12:20 PM, 王蓉(涂南)  wrote:
> >
> > Mar 15th is Friday.
> >
> > Can we make it Mar 23rd? As our venue is available on that day.
> >
> >
> > --
> > 发件人：Ian Luo 
> > 发送时间：2019年2月1日(星期五) 17:12
> > 收件人：dev 
> > 抄 送：王蓉(涂南) 
> > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> >
> > +1 Mar. 15th looks better.
> >
> > On Thu, Jan 31, 2019 at 10:49 AM Huxing Zhang  wrote:
> >
> >> Hi,
> >>
> >> Consider the Chinese New Year vacation, how about move one week later?
> >>
> >> Location: Nanjing
> >> Call for talks close:  Feb. 22nd (Friday)
> >> Meetup: March 15th (Saturday)
> >>
> >> On Mon, Jan 28, 2019 at 10:47 PM Ian Luo  wrote:
> >>
> >>> +1 for Nanjing. I think any weekend in March sounds fine to me.
> >>>
> >>> Thanks,
> >>> -Ian.
> >>>
> >>> On Mon, Jan 28, 2019 at 5:12 PM Huxing Zhang 
> wrote:
> >>>
>  Hi,
> 
>  On Mon, Jan 28, 2019 at 11:19 AM 王蓉(涂南) 
> >>> wrote:
> 
> > Hi guys,
> >
> > Last week meetup in Guangzhou was so much fun.
> > We have total 400+ registrations and more than 200 attendees, another
> >>> 4k
> > people watched our live streaming!
> >
> > I think we should start to prepare next meetup in Nanjing ASAP. As
> >> the
> > Chinese New Year is approaching.
> >
> 
>  We need to first discuss with the community about:
>  - where should next meetup be held?
>  - when should it be held?
> 
>  As discussed in the previous threads, based on the vote result, I
> think
>  Nanjing is a good candidate for the next meetup.
>  +1 for Nanjing!
> 
> 
> 
> >
> > What about March 9th?If March 9th is OK, the Call for Talks will be
>  closed
> > on Feb 15th. That will give us plenty of time to prepare.
> >
> 
>  March 9th is a Saturday, which looks good to me.
>  Feb 15th looks too early to me, because the Chinese new year festival
> >> is
>  Feb 4th to Feb 10th. There is only one week after the vacation, and it
> >> is
>  possible some of us would have extra days-off after the vacation.
>  Is is possible to close the Call for talks one week later? say Feb
> >> 22nd.
> 
> 
> >
> > Amber
> > BR
> >
> >
> > --
> > 发件人：Huxing Zhang 
> > 发送时间：2018年12月11日(星期二) 15:15
> > 收件人：dev 
> > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> >
> > Hi,
> >
> > I think Guangzhou and Nanjing are the cities we all should go to. It
> >> is
> > just about who is the first.
> >
> > On Tue, Dec 11, 2018 at 2:07 PM Mercy  wrote:
> >
> >> I vote twice, one is Nanjing, another is Guangzhou :D
> >>
> >>
> >> Kind regards,
> >>
> >> Mercy Ma
> >>
> >>
> >> 在 2018/12/11 下午1:47, 王蓉(涂南) 写道:
> >>> Folks, so far we have received 40 votes.
> >>>
> >>> Looks like Guangzhou is where we're gonna meet on Jan 19th.
> >>>
> >>>
> >>>  广州  12
> >>>  南京  10
> >>>  北京  4
> >>>  深圳  4
> >>>  上海  4
> >>>  厦门  2
> >>>  武汉  1
> >>>  西安  1
> >>>  重庆  1
> >>>  大连  1
> >>>
> >>>
> >>>
> >> --
> >>> 发件人：jun liu 
> >>> 发送时间：2018年12月7日(星期五) 23:52
> >>> 收件人：dev 
> >>> 主 题：Re: [DISCUSS] Next Dubbo meetup
> >>>
> >>> I prefer Nanjing for the next Meetup city.
> >>>
> >>> Jun
> >>>
>  On Dec 4, 2018, at 10:06 PM, Huxing Zhang 
>  wrote:
> 
>  In the link[1] provided, there are 3 options:
> 
>  * Nanjing
>  * Guangzhou
>  * Other
> 
>  I prefer to a new city where we haven't been there before.
>  According to a survey, the number of users who is using Dubbo in
> >> Guangzhou
>  ranks 5th in China, only secondary to Beijing, Shanghai,
> >> Shenzhen,
> >> Hangzhou.
>  So I am going to vote +1 for Guangzhou. :)
> 
>  [1] http://sc-meetup.mikecrm.com/7hZFeTl <
> >> http://sc-meetup.mikecrm.com/7hZFeTl>
> 
>  On Tue, Dec 4, 2018 at 4:08 PM 王蓉(涂南)  >> > wrote:
> 
> > Hi guys,
> >
> > I'm Amber, organizer of Dubbo meetup.
> >
> > Since 2018, Dubbo community has been touring around China!
> > We have been to Beijing, Chengdu, Shenzhen, Shanghai, and
> >>> Hangzhou.
> > More than 30K developers have either come to the meetup or
> >>> watched
> > our
> > live 

Re: [ANN] New PPMC member: Minxuan Zhuang

[Ian Luo]

Congratulations!

On Mon, Feb 18, 2019 at 5:11 PM Xianjun Ke  wrote:

> Congratulations
>
> Imteyaz Khan  于2019年2月18日周一 下午3:54写道：
>
> > Congratulations
> >
> > On Monday, February 18, 2019, 柯振旭  wrote:
> >
> > > Congratulations!!
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 在 2019-02-18 14:00:59，"Chen ZhiGuo"  写道：
> > > >Congratulations！！
> > > >
> > > >在 2019/2/18 13:40，“xxz” 写入:
> > > >
> > > >Congratulations！！
> > > >
> > > >
> > > >
> > > >
> > > >| |
> > > >xxz
> > > >邮箱：xxz...@126.com
> > > >|
> > > >
> > > >Signature is customized by Netease Mail Master
> > > >
> > > >On 02/18/2019 13:37, Huxing Zhang wrote:
> > > >Hi Community,
> > > >
> > > >On behalf of the Dubbo PPMC, I am pleased to announce that Minxuan
> > > Zhuang[1]
> > > >has been voted in as a new Dubbo PPMC member.
> > > >
> > > >Please join me to say congratulations to him!
> > > >
> > > >[1] https://github.com/nzomkxia
> > > >--
> > > >Best Regards！
> > > >Huxing
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Next Dubbo meetup

[victory]

+1 for Nanjing
And any weekend is fine for me.

Minxuan Zhuang  于2019年2月18日周一 下午5:49写道：

> +1 for March 23rd
> +1 for Nanjing
>
> On Thu, Feb 14, 2019 at 2:41 PM jun liu  wrote:
>
> > > Can we make it Mar 23rd? As our venue is available on that day.
> >
> > +1 for Mar. 23th, any time is ok for me.
> >
> > +1 for hosting in Nanjing.
> >
> > Jun
> >
> > > On Feb 12, 2019, at 12:20 PM, 王蓉(涂南)  wrote:
> > >
> > > Mar 15th is Friday.
> > >
> > > Can we make it Mar 23rd? As our venue is available on that day.
> > >
> > >
> > > --
> > > 发件人：Ian Luo 
> > > 发送时间：2019年2月1日(星期五) 17:12
> > > 收件人：dev 
> > > 抄 送：王蓉(涂南) 
> > > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> > >
> > > +1 Mar. 15th looks better.
> > >
> > > On Thu, Jan 31, 2019 at 10:49 AM Huxing Zhang 
> wrote:
> > >
> > >> Hi,
> > >>
> > >> Consider the Chinese New Year vacation, how about move one week later?
> > >>
> > >> Location: Nanjing
> > >> Call for talks close:  Feb. 22nd (Friday)
> > >> Meetup: March 15th (Saturday)
> > >>
> > >> On Mon, Jan 28, 2019 at 10:47 PM Ian Luo  wrote:
> > >>
> > >>> +1 for Nanjing. I think any weekend in March sounds fine to me.
> > >>>
> > >>> Thanks,
> > >>> -Ian.
> > >>>
> > >>> On Mon, Jan 28, 2019 at 5:12 PM Huxing Zhang 
> > wrote:
> > >>>
> >  Hi,
> > 
> >  On Mon, Jan 28, 2019 at 11:19 AM 王蓉(涂南) 
> > >>> wrote:
> > 
> > > Hi guys,
> > >
> > > Last week meetup in Guangzhou was so much fun.
> > > We have total 400+ registrations and more than 200 attendees,
> another
> > >>> 4k
> > > people watched our live streaming!
> > >
> > > I think we should start to prepare next meetup in Nanjing ASAP. As
> > >> the
> > > Chinese New Year is approaching.
> > >
> > 
> >  We need to first discuss with the community about:
> >  - where should next meetup be held?
> >  - when should it be held?
> > 
> >  As discussed in the previous threads, based on the vote result, I
> > think
> >  Nanjing is a good candidate for the next meetup.
> >  +1 for Nanjing!
> > 
> > 
> > 
> > >
> > > What about March 9th?If March 9th is OK, the Call for Talks will be
> >  closed
> > > on Feb 15th. That will give us plenty of time to prepare.
> > >
> > 
> >  March 9th is a Saturday, which looks good to me.
> >  Feb 15th looks too early to me, because the Chinese new year
> festival
> > >> is
> >  Feb 4th to Feb 10th. There is only one week after the vacation, and
> it
> > >> is
> >  possible some of us would have extra days-off after the vacation.
> >  Is is possible to close the Call for talks one week later? say Feb
> > >> 22nd.
> > 
> > 
> > >
> > > Amber
> > > BR
> > >
> > >
> > > --
> > > 发件人：Huxing Zhang 
> > > 发送时间：2018年12月11日(星期二) 15:15
> > > 收件人：dev 
> > > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> > >
> > > Hi,
> > >
> > > I think Guangzhou and Nanjing are the cities we all should go to.
> It
> > >> is
> > > just about who is the first.
> > >
> > > On Tue, Dec 11, 2018 at 2:07 PM Mercy 
> wrote:
> > >
> > >> I vote twice, one is Nanjing, another is Guangzhou :D
> > >>
> > >>
> > >> Kind regards,
> > >>
> > >> Mercy Ma
> > >>
> > >>
> > >> 在 2018/12/11 下午1:47, 王蓉(涂南) 写道:
> > >>> Folks, so far we have received 40 votes.
> > >>>
> > >>> Looks like Guangzhou is where we're gonna meet on Jan 19th.
> > >>>
> > >>>
> > >>>  广州  12
> > >>>  南京  10
> > >>>  北京  4
> > >>>  深圳  4
> > >>>  上海  4
> > >>>  厦门  2
> > >>>  武汉  1
> > >>>  西安  1
> > >>>  重庆  1
> > >>>  大连  1
> > >>>
> > >>>
> > >>>
> > >> --
> > >>> 发件人：jun liu 
> > >>> 发送时间：2018年12月7日(星期五) 23:52
> > >>> 收件人：dev 
> > >>> 主 题：Re: [DISCUSS] Next Dubbo meetup
> > >>>
> > >>> I prefer Nanjing for the next Meetup city.
> > >>>
> > >>> Jun
> > >>>
> >  On Dec 4, 2018, at 10:06 PM, Huxing Zhang 
> >  wrote:
> > 
> >  In the link[1] provided, there are 3 options:
> > 
> >  * Nanjing
> >  * Guangzhou
> >  * Other
> > 
> >  I prefer to a new city where we haven't been there before.
> >  According to a survey, the number of users who is using Dubbo in
> > >> Guangzhou
> >  ranks 5th in China, only secondary to Beijing, Shanghai,
> > >> Shenzhen,
> > >> Hangzhou.
> >  So I am going to vote +1 for Guangzhou. :)
> > 
> >  [1] http://sc-meetup.mikecrm.com/7hZFeTl <
> > >> http://sc-meetup.mikecrm.com/7hZFeTl>
> > 
> >  On Tue, Dec 4, 2018 at 4:08 

Re: dubbo.registry.check=false具体是什么功能呢？看官网的解释不太理解，请教了！

[Ian Luo]

这是个顺序问题。check 的引入是为了保证 consumer 的启动不会依赖 provider
的启动，尤其是存在循环依赖的时候强制检查导致无法启动的现象出现。

On Wed, Feb 13, 2019 at 3:19 PM LiZhenNet  wrote:

> dubbo.registry.check . 是启动时候监测注册中心是否存在。
> dubbo.reference.check=false 用的会比较多，  会在启动时判断服务提供者是否存在，如果是true，当服务提供者列表为空时
> ，会报错提示。 false 则不检查。
>
> 一直以来 <279377...@qq.com> 于2019年2月13日周三 上午11:54写道：
>
> > dubbo.reference.check=false，强制改变所有 reference 的 check 值，就算配置中有声明，也会被覆盖。
> >
> > dubbo.consumer.check=false，是设置 check 的缺省值，如果配置中有显式的声明，如： > check="true"/>，不会受影响。
> >
> >
> >
> dubbo.registry.check=false，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。
> >
> >
> >
> >
> > -
> >
> >
> >
> dubbo.registry.check=false，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。
> >
> > 上面这句话中的“前面两个都是指订阅成功”，我不太理解这个“订阅成功”是指什么？，如果使用check=false说明提供者都不存在，怎么订阅成功了？
> >
> >
> >
> >
> >
> >
> 这句话“但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。”，说明提供者列表为空就出现了异常，那和提供者都不存在也没有区别啊，本质上都是提供者不存在，那么使用dubbo.registry.check=false的意义是什么呢？？
> >
> >
> >
> >
> > 感谢 ！由于要讲的内容太多，所以用了中文，感谢 ！
>

version of Apache Dubbo OPS(Incubating)

[Minxuan Zhuang]

Hello Dubbo Community,
  The first dubbo ops has been released with version 0.1, usually the
apache project releases follow the format:  MAJOR.MINOR.PATCH, so I suggest
to use version 0.2.0 for the next release.

Re: [ANN] New PPMC member: Minxuan Zhuang

[Xianjun Ke]

Congratulations

Imteyaz Khan  于2019年2月18日周一 下午3:54写道：

> Congratulations
>
> On Monday, February 18, 2019, 柯振旭  wrote:
>
> > Congratulations!!
> >
> >
> >
> >
> >
> >
> >
> >
> > 在 2019-02-18 14:00:59，"Chen ZhiGuo"  写道：
> > >Congratulations！！
> > >
> > >在 2019/2/18 13:40，“xxz” 写入:
> > >
> > >Congratulations！！
> > >
> > >
> > >
> > >
> > >| |
> > >xxz
> > >邮箱：xxz...@126.com
> > >|
> > >
> > >Signature is customized by Netease Mail Master
> > >
> > >On 02/18/2019 13:37, Huxing Zhang wrote:
> > >Hi Community,
> > >
> > >On behalf of the Dubbo PPMC, I am pleased to announce that Minxuan
> > Zhuang[1]
> > >has been voted in as a new Dubbo PPMC member.
> > >
> > >Please join me to say congratulations to him!
> > >
> > >[1] https://github.com/nzomkxia
> > >--
> > >Best Regards！
> > >Huxing
> > >
> > >
> >
>

Re: how to deal with two pull requests to solve the same issue

[Taosheng, Wei]

+1
If the pr introduce new feature or modify origin logic, the unit test should be 
considered!




-- Original --
From: Huxing Zhang 
Date: Mon,Feb 18,2019 5:28 PM
To: dev 
Subject: Re: how to deal with two pull requests to solve the same issue

Re: version of Apache Dubbo OPS(Incubating)

[Huxing Zhang]

Hi,


On Mon, Feb 18, 2019 at 4:11 PM Minxuan Zhuang  wrote:
>
> Hello Dubbo Community,
>   The first dubbo ops has been released with version 0.1, usually the
> apache project releases follow the format:  MAJOR.MINOR.PATCH, so I suggest
> to use version 0.2.0 for the next release.

+1 to use semantic versioning[1] for dubbo-admin.

p.s. Didn't the community reach the consesus to use dubbo-admin instead? :)

[1] https://semver.org/
-- 
Best Regards！
Huxing

Re: Non-apache releases and old releases

[Ian Luo]

We should make it public every time when we publish artifacts to the public
repository, even there's nothing change from the source but other
irrelevant problem like maven issue.

Thanks,
-Ian.

On Mon, Feb 18, 2019 at 5:08 PM Huxing Zhang  wrote:

> Hi,
>
> On Mon, Feb 18, 2019 at 1:25 PM Mercy  wrote:
> >
> > Hi,
> >
> >Sorry about the unannouced release that is a re-deploy caused by the
> > incompatible issue of Maven, and it will appear again.
>
> Can you explain this issue a bit more?
> Will this re-deploy cause change to the source files?
>
> I checked the ASF doc[1], it says:
> In all such cases, the binary/bytecode package MUST have the same
> version number as the source release and MUST only add binary/bytecode
> files that are the result of compiling that version of the source code
> release and its dependencies.
>
> Due to the incompatible version number,  we should stop promoting it.
> It is lucky to know that 2.7.0 has already been released, I checked
> the version in both GitHub and website that it has been changed to
> 2.7.0.
>
>
>
> [1] http://www.apache.org/legal/release-policy.html#compiled-packages
>
>
> >
> > Kind regards,
> >
> > Mercy Ma
> >
> > 在 2019/2/14 下午1:41, Huxing Zhang 写道:
> > > I have checked the maven repo[3] again, I found there are two extra
> > > release artifacts, 0.1.2.RELEASE and 0.2.1.RELEASE, I did not find any
> > > discussion on the mailing list about it, we should stop doing things
> > > like that.
>
>
>
> --
> Best Regards！
> Huxing
>

Re: [ANN] Welcome new committer: Zhongming Hua

[Ian Luo]

Congratulations and welcome!

On Fri, Feb 15, 2019 at 10:12 AM Huxing Zhang  wrote:

> Hi Community,
>
> On behalf of the Dubbo PPMC, I am pleased to announce that Zhongming Hua,
> a.k.a. CrazyHZM[1], has been voted in as a new Dubbo committer.
>
> Please join me to say congratulations to him!
>
> Zhongming, would you please briefly introduce yourself to the community?
>
> [1] https://github.com/CrazyHZM
>
> --
> Best Regards！
> Huxing
>

Re: How to integrate dubbo-registry-nacos into Fescar project?

[Ian Luo]

I am confused, why fescar needs to depend on dubbo-registry-nacos.

> because fescar 0.2 has been
released and supports nacos as a registration and configuration center.

It looks like you should depend on nacos directly.

-Ian.


On Thu, Feb 14, 2019 at 11:07 PM 季敏  wrote:

> When will the 2.7.1 be released? Fescar's main framework does not directly
> depend on dubbo-registry-nacos, because the framework does not directly
> determine which registry the user uses. But recently I will post a PR on
> how fescar, nacos and dubbo are integrated, because fescar 0.2 has been
> released and supports nacos as a registration and configuration center.
>
> Huxing Zhang  于2019年2月14日周四 下午3:30写道：
>
> > Hi,
> >
> > On Wed, Feb 13, 2019 at 6:59 PM Xin Wang 
> wrote:
> > >
> > > Hi all,
> > > Now the Fescar project[0] will integrate dubbo-registry-nacos[1],
> but
> > > there are two issues:
> > > *  dubbo-registry-nacos[1] has no release version
> > > *  I know dubbo-registry-nacos is being merged into Dubbo main repo
> [2],
> > >  Then what kind of Maven dependency do you recommend?
> > >
> > >  org.apache.dubbo
> > >  dubbo
> > >or
> > >com.alibaba
> > >dubbo
> >
> > What is schedule of Fescar's integration with dubbo-registry-nacos?
> > If it is not in a hurry, I suggest to use the org.apache.dubbo, since
> > it will be available in the subsequent 2.6.6 and 2.7.1 release.
> >
> > >
> > > [0] https://github.com/alibaba/fescar/
> > > [1] https://github.com/dubbo/dubbo-registry-nacos
> > > [2]
> > >
> >
> https://lists.apache.org/thread.html/a6753eee2f7098fcaaf12b24d5496b9f1d3f21f52ffdbc5a808ddd89@%3Cdev.dubbo.apache.org%3E
> >
> >
> >
> > --
> > Best Regards！
> > Huxing
> >
>

Re: [DISCUSS] Next Dubbo meetup

[Ian Luo]

+1 to the proposed time and location.

On Mon, Feb 18, 2019 at 5:56 PM victory  wrote:

> +1 for Nanjing
> And any weekend is fine for me.
>
> Minxuan Zhuang  于2019年2月18日周一 下午5:49写道：
>
> > +1 for March 23rd
> > +1 for Nanjing
> >
> > On Thu, Feb 14, 2019 at 2:41 PM jun liu  wrote:
> >
> > > > Can we make it Mar 23rd? As our venue is available on that day.
> > >
> > > +1 for Mar. 23th, any time is ok for me.
> > >
> > > +1 for hosting in Nanjing.
> > >
> > > Jun
> > >
> > > > On Feb 12, 2019, at 12:20 PM, 王蓉(涂南) 
> wrote:
> > > >
> > > > Mar 15th is Friday.
> > > >
> > > > Can we make it Mar 23rd? As our venue is available on that day.
> > > >
> > > >
> > > > --
> > > > 发件人：Ian Luo 
> > > > 发送时间：2019年2月1日(星期五) 17:12
> > > > 收件人：dev 
> > > > 抄 送：王蓉(涂南) 
> > > > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> > > >
> > > > +1 Mar. 15th looks better.
> > > >
> > > > On Thu, Jan 31, 2019 at 10:49 AM Huxing Zhang 
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Consider the Chinese New Year vacation, how about move one week
> later?
> > > >>
> > > >> Location: Nanjing
> > > >> Call for talks close:  Feb. 22nd (Friday)
> > > >> Meetup: March 15th (Saturday)
> > > >>
> > > >> On Mon, Jan 28, 2019 at 10:47 PM Ian Luo  wrote:
> > > >>
> > > >>> +1 for Nanjing. I think any weekend in March sounds fine to me.
> > > >>>
> > > >>> Thanks,
> > > >>> -Ian.
> > > >>>
> > > >>> On Mon, Jan 28, 2019 at 5:12 PM Huxing Zhang 
> > > wrote:
> > > >>>
> > >  Hi,
> > > 
> > >  On Mon, Jan 28, 2019 at 11:19 AM 王蓉(涂南)  >
> > > >>> wrote:
> > > 
> > > > Hi guys,
> > > >
> > > > Last week meetup in Guangzhou was so much fun.
> > > > We have total 400+ registrations and more than 200 attendees,
> > another
> > > >>> 4k
> > > > people watched our live streaming!
> > > >
> > > > I think we should start to prepare next meetup in Nanjing ASAP.
> As
> > > >> the
> > > > Chinese New Year is approaching.
> > > >
> > > 
> > >  We need to first discuss with the community about:
> > >  - where should next meetup be held?
> > >  - when should it be held?
> > > 
> > >  As discussed in the previous threads, based on the vote result, I
> > > think
> > >  Nanjing is a good candidate for the next meetup.
> > >  +1 for Nanjing!
> > > 
> > > 
> > > 
> > > >
> > > > What about March 9th?If March 9th is OK, the Call for Talks will
> be
> > >  closed
> > > > on Feb 15th. That will give us plenty of time to prepare.
> > > >
> > > 
> > >  March 9th is a Saturday, which looks good to me.
> > >  Feb 15th looks too early to me, because the Chinese new year
> > festival
> > > >> is
> > >  Feb 4th to Feb 10th. There is only one week after the vacation,
> and
> > it
> > > >> is
> > >  possible some of us would have extra days-off after the vacation.
> > >  Is is possible to close the Call for talks one week later? say Feb
> > > >> 22nd.
> > > 
> > > 
> > > >
> > > > Amber
> > > > BR
> > > >
> > > >
> > > >
> --
> > > > 发件人：Huxing Zhang 
> > > > 发送时间：2018年12月11日(星期二) 15:15
> > > > 收件人：dev 
> > > > 主 题：Re: 回复：[DISCUSS] Next Dubbo meetup
> > > >
> > > > Hi,
> > > >
> > > > I think Guangzhou and Nanjing are the cities we all should go to.
> > It
> > > >> is
> > > > just about who is the first.
> > > >
> > > > On Tue, Dec 11, 2018 at 2:07 PM Mercy 
> > wrote:
> > > >
> > > >> I vote twice, one is Nanjing, another is Guangzhou :D
> > > >>
> > > >>
> > > >> Kind regards,
> > > >>
> > > >> Mercy Ma
> > > >>
> > > >>
> > > >> 在 2018/12/11 下午1:47, 王蓉(涂南) 写道:
> > > >>> Folks, so far we have received 40 votes.
> > > >>>
> > > >>> Looks like Guangzhou is where we're gonna meet on Jan 19th.
> > > >>>
> > > >>>
> > > >>>  广州  12
> > > >>>  南京  10
> > > >>>  北京  4
> > > >>>  深圳  4
> > > >>>  上海  4
> > > >>>  厦门  2
> > > >>>  武汉  1
> > > >>>  西安  1
> > > >>>  重庆  1
> > > >>>  大连  1
> > > >>>
> > > >>>
> > > >>>
> > > >> --
> > > >>> 发件人：jun liu 
> > > >>> 发送时间：2018年12月7日(星期五) 23:52
> > > >>> 收件人：dev 
> > > >>> 主 题：Re: [DISCUSS] Next Dubbo meetup
> > > >>>
> > > >>> I prefer Nanjing for the next Meetup city.
> > > >>>
> > > >>> Jun
> > > >>>
> > >  On Dec 4, 2018, at 10:06 PM, Huxing Zhang 
> > >  wrote:
> > > 
> > >  In the link[1] provided, there are 3 options:
> > > 
> > >  * Nanjing
> > >  * Guangzhou
> > >  * Other
> > > 
> > >  I prefer to a new city where we haven't been there 

Re: [ANNOUNCEMENT] Apache Dubbo Spring Boot Project (Incubating) 2.7.0 has been released

[Ian Luo]

Finally we have it :) It is a strongly demanded feature. Thank you Mercy.

-Ian.

On Fri, Feb 15, 2019 at 4:12 PM Mercy  wrote:

> Hi community,
>
> The Apache Dubbo(incubating) team is pleasured to announce that the
> Apache Dubbo Spring Boot Project (Incubating) 2.7.0 has just been released.
>
> Both the source release[1] and the maven binary release[2] are available
> now, you can also find the detailed release notes in here[3].
>
> If you have any usage questions, or have problems when upgrading or find
> any problems about enhancements included in this release, please don’t
> hesitate to let us know by sending feedback to this mailing list or filing
> an issue on GitHub[4].
>
> [1]
>
> https://www.apache.org/dyn/closer.cgi?path=incubator/dubbo/spring-boot-project/2.7.0/apache-dubbo-spring-boot-project-incubating-2.7.0-source-release.zip
> [2] http://central.maven.org/maven2/org/apache/dubbo
> [3] https://github.com/apache/incubator-dubbo-spring-boot-project/releases
> [4] https://github.com/apache/incubator-dubbo-spring-boot-project/issues
>
>
> Best Regards,
>
> The Apache Dubbo (Incubating) Team
>
>

Re: Filter problems in async way

[Ian Luo]

Yuhang,

Why it's a bad idea to use invocation#attachments to store the temp data?

Thanks,
-Ian.


On Fri, Feb 15, 2019 at 2:55 PM yuhang xiu  wrote:

> Hi, everyone
>
> Recently, I found that dubbo does not handle the data generated during the
> call process when it is asynchronous.
>
> For example, in TimeoutFilter, we used invocation#attachments to hold the
> data that needs to be passed (start time in TimeoutFilter). But I don't
> think this way is good, although using Invocation.attachments to pass data
> does not pollute RpcContext.
>
> Perhaps a better way is to add a temporary attachment to the Invocation
> that only maintains the temporary data generated during the call.
>
> In addition, I found that we still have a few Filters that are currently
> problematic in asynchronous scenarios, such as:
>
> * ActiveLimitFilter
> * TraceFilter
>
> We should determine a plan as soon as possible and then proceed to fix
> these Filters.
>

Re: Filter problems in async way

[yuhang xiu]

Hi,ian

Several reasons:
1. It seems that the attachment is based on the convention. We need to put
the information other than the rpc parameter into the attachment. We need
to ensure that the information and the temporary information (start in the
timeoutFilter) do not overlap.
2. The attachment field may be null. This allows us to make some additional
judgments and processing before we can use the attachment field:

if (invocation.getAttachments() != null) {
long start = System.currentTimeMillis();
invocation.getAttachments().put(TIMEOUT_FILTER_START_TIME,
String.valueOf(start));
} else {
if (invocation instanceof RpcInvocation) {
RpcInvocation invc = (RpcInvocation) invocation;
long start = System.currentTimeMillis();
invc.setAttachment(TIMEOUT_FILTER_START_TIME,
String.valueOf(start));
}
}

I am still thinking about this issue recently. It seems that the extra
tempAttachment needs to increase the cost of the transmission.
So I have some hesitation about using tempAttachment. How do you think
about this problem?

Ian Luo  于2019年2月18日周一 下午6:26写道：

> Yuhang,
>
> Why it's a bad idea to use invocation#attachments to store the temp data?
>
> Thanks,
> -Ian.
>
>
> On Fri, Feb 15, 2019 at 2:55 PM yuhang xiu  wrote:
>
> > Hi, everyone
> >
> > Recently, I found that dubbo does not handle the data generated during
> the
> > call process when it is asynchronous.
> >
> > For example, in TimeoutFilter, we used invocation#attachments to hold the
> > data that needs to be passed (start time in TimeoutFilter). But I don't
> > think this way is good, although using Invocation.attachments to pass
> data
> > does not pollute RpcContext.
> >
> > Perhaps a better way is to add a temporary attachment to the Invocation
> > that only maintains the temporary data generated during the call.
> >
> > In addition, I found that we still have a few Filters that are currently
> > problematic in asynchronous scenarios, such as:
> >
> > * ActiveLimitFilter
> > * TraceFilter
> >
> > We should determine a plan as soon as possible and then proceed to fix
> > these Filters.
> >
>