First of all, this article may not be useful to the big guys, it is just a record of the problem finding process.
The thing is like this. I experienced a very depressing thing in the transformation from spring-task to elastic-job demand.
The elastic-job part of the configuration is like this, very simple, the elastic-job part of the configuration
<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
namespace="${namespace}" base-sleep-time-milliseconds="1000"
max-sleep-time-milliseconds="3000" max-retries="3" />
Then in properties, we call it xxx.properties to add HAC_JOB_URL= 10.x.xx.xxx:2181 and
specify -Dspring.profiles.active=uat, it should be smooth to replace ${HAC_JOB_URL} with the above The string, but the weird thing happened, and an error was reported:
java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error
Actually tell me to print the error directly without parsing? There is no other way but to dive in to find the cause and look for it. . . .
At first I thought it was a configuration problem of elastic-job, but I was not familiar with it. . Then I changed the configuration in various ways. The most depressing thing is that another project was also transformed from spring-task to elastic-job, but it can actually run, and it runs very high...
well, maybe I am wrong, so I just changed it according to it, but it still doesn’t work, it’s still the same error. It’s already late at this time. I originally wanted to get home from work at 18 o’clock to dine with my wife, but it all fell through. I tried to modify various configurations, but the results were all Similarly, the time came to 21:40 in the evening, forget it, let's go home, or be scolded by my wife.
On the way home, I suddenly thought, why not run it locally, because before, the code was modified and submitted immediately, and jenkins was responsible for the construction.
I arrived at the office early the next morning, turned on the computer, and ran locally, but it could start normally. The problem in the previous environment was not reproduced. I began to wonder if there was a problem with the build script, but there was no evidence. Cannot drag the maintenance classmates into the water, so I have to continue to locate the reason.
I started to compare the logs of the two environments, and suddenly found that I obviously output some key and value of properties locally, and the extra is the new HAC_JOB_URL in xxx.properties, so I configured this key to another properties file Inside (we have several files of this kind, so it is easy to distinguish -_-), the submission re-triggered the jenkins build, xxx, this time it was successful, and I ran, I burst into tears. Obviously, adding a new key to that file has no effect, but why is it useless?
I opened the package built by Jenkins and found a problem, that is, no matter how you change the xxx.properties file, as long as it is built, it will generate a fixed file at the end, and the content inside will never change. Okay, the truth is out, right? So I threw this question to the operation and maintenance classmates, and the operation and maintenance said that there is no xxx.properties file. Well, I continue to find the reason.
I thought it turned out that the xxx.properties in the project was overwritten after each build, so I can start with the build script, so I opened the jenkins build log and saw a record like this:
scp -r /root/.jenkins/profile/jds-efg/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat
Another project output that can be successfully started is as follows:
scp -r /root/.jenkins/profile/jds-efg-app/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat
The only difference between the two is that there is one more -app below, that is to say, the first one is not the latest one in the project, but the one under the /root/.jenkins/profile/jds-efg/xxx.properties directory. A long time ago, this is why it will be overwritten every time it is built.
Finally, let the operation and maintenance change the build script to start normally.
This time it was caused by the operation and maintenance classmates who wrote the wrong script carelessly. It may not be of practical value to everyone. I just thought of the process of positioning the problem, so I made a record. After all, I even had a soup with my wife for dinner, but what's the point? Maybe someone who is naive makes the same mistake, hehe ( ▽ )