Shulou(Shulou.com)06/02 Report--

How to participate in a top-level open source project and what is the asynchronous conversion to synchronization in the process of Dubbo calls? for this question, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

Participate in open source

Now let's talk about participation in open source.

Every day, almost all developers will enjoy the convenience and even benefits brought by open source projects. Limited by the environment, open source activities have always been dominated by foreign developers more than a decade or even a few years ago.

But in recent years, the gradual internationalization of domestic Internet companies to expand their influence has also greatly improved our development level, led by BAT, there are many excellent open source projects.

Now even participating in open source projects can find another way to get a big offer, so in fact, many friends want to participate in it, it may not be easy to give people the first feeling, so it is still stuck in the first step.

Concrete steps

Here are some steps summed up from my personal experience:

Find a problem or recommend feature.

Fork source code.

Local development, self-testing.

Initiate pull request.

Wait for the community Code Review.

Follow up the community opinion adjustment code.

Pass the examination and merge into the master branch to complete this contribution.

Now I will talk about it in detail in combination with the process of participating in Dubbo recently.

Find a problem or recommend feature

First of all, naturally, the first step is to find out what is the content of this contribution. It's usually about solving a problem or submitting a new feature; the former is relatively easier.

Of course, this problem can be found in the course of your own use, or it can be a problem to be solved in the Issues list.

Take this as an example, which is the problem I found in the process of using it. I also submitted the relevant Issue and wrote an article to record and solve the problem: What? It takes two hours for a Dubbo service to start!

It is worth noting that before submitting the Issue, it is best to search the Issue list by keyword to see if there are any related problems to avoid repetition.

At the same time, the community may follow up after the submission, and it is considered not a problem to be tagged with invalid, or it is possible to use the posture incorrectly.

Fork source code, local development

When it is determined that this is a problem to be fixed, you can start to develop.

The first step, of course, is to copy the source code into your own warehouse.

Then you only need the source code from clone's own repository to develop locally.

Let's review the problem I encountered first.

To put it simply, it is very slow to start the Dubbo service, and it is positioned that the main thread is blocked at the place where the native ip is obtained.

So the solution I proposed at that time was to add a timeout when getting the native ip, and throw an exception or try again once the timeout occurs, but at least there must be a log to facilitate the user to locate the problem.

The problem is that the main thread will always block here InetAddress.getLocalHost (). GetHostAddress (), but you need to know how long it has been blocked to determine whether it has timed out.

So I can only start another thread to check whether the main thread has completed the task. Here is the content of my first pr.

The focus this time is not on the specific technical details here, so let's briefly talk about the next steps:

A thread pool with a declared size of 1.

A volatile flag is also declared to determine whether the main thread has completed the task.

A condition is declared for the new thread to wait.

Finally, all you need to do is run the thread to determine the flag.

How to test yourself

After the completion of the development, the next step is self-testing, because this kind of project can run as a basic package dependent on other projects, so usually we have to create a new project to cooperate with the full-process testing (except single test).

Here I think there are still a few tips to pay attention to.

The first is the version number; because you are testing locally, you need to install the package locally using mvn clean install before you can rely on it for testing in other projects.

However, since the versions of the code we pulled out officially have been released to the central maven repository (whether release or snapshot), we must already have these versions of jar packages in our local repository.

Once we execute mvn clean install to install the modified code locally, there is a good chance that something will go wrong (or maybe I am in the wrong position), which will result in the newly built project not being able to rely on the new code.

So my usual practice is to change the version number, which has never been officially released to the central warehouse, to ensure that my new code will be installed locally with a new version, so that we can rely on this version for testing.

However, you have to be careful not to submit this version number when you submit it.

Initiate pull request

After the self-test is complete, you can launch pull request, don't be careless, there is another place to pay attention to, and that is the problem of code newline characters.

Once the newline character is inconsistent with the source repository, git will think that the change is deleted and restarted, which will cause a lot of trouble for code review.

Just like this, obviously I didn't change a lot of lines, but git confirmed that you overturned and started all over again, so that the audit didn't know what you had changed.

The easiest way is to set up your own global configuration of git, as you can refer to here.

# convert to LF on submission, convert to CRLFgit config on check out-convert to LF on global core.autocrlf true# submission, and do not convert git config on check out-- global core.autocrlf input# submit check out does not convert git config-global core.autocrlf false

After confirming that there is no problem, you can click here to initiate pull request, and then follow the guide to execute.

Of course, each project will have its own customized contribution process, and it is best to check out the official contribution guide.

Http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html

Code Review

After the pr is initiated, you can wait for community review.

In the process to fully communicate with the community, it is possible that your plan and the community's ideas are not consistent.

For example, like me this time:

In the end, through communication and thinking behind me, I felt that the community's plan was more light and reasonable. After reaching an agreement, the community incorporated this pr into master.

In fact, I think the most meaningful part of the whole process is the code review process, in which everyone can take part in brainstorming, and there is no lack of technology, and they can learn a lot before they know it.

Similar cases

Although my previous scheme was not adopted, there are a lot of similar uses (one thread monitors other threads), which happens to be used in Dubbo.

This is the core service invocation, which by default looks like a synchronous invocation to the consumer, meaning that the consumer waits for the RPC to complete before executing the subsequent logic.

But in fact, at the bottom, this is a TCP network packet sending process, itself is asynchronous.

It's just that Dubbo does asynchronous conversion to synchronization without you knowing it, so it looks like a synchronization method.

As shown in the red box in the figure, Dubbo itself calls the get () method to synchronously get the returned results from the service provider.

The logic is actually quite simple, similar to my previous scenario, except that the isDone () function here returns whether the return value of the service provider has been obtained.

Summing up the specific steps to participate in open source is actually quite simple; as the official said, even if you mention an Issue, changing a typos can be regarded as a participation, so don't think too hard.

Finally, it also briefly analyzes the process of asynchronous to synchronous in the process of Dubbo call, and mastering these operations is also very helpful to their usual development.

This is the answer to the question about how to participate in a top open source project and what is the asynchronous transfer to synchronization in the process of Dubbo call. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.