1. Two way binding does not take effect
The drop-down box has three options: A, B and C, but after selecting B, it still displays A. in fact, the value selected in v-model has become B, but the display has not changed.
Cause of problem: queryParams. Attribute of v-model binding xxx and queryParams are attributes declared in data. xxx is not written in data during initialization, and vue cannot detect the addition or deletion of object attributes, so it is impossible to listen to the change of xxx attribute and conduct two-way binding
Solution: when declaring queryParams in data, bring the attribute xxx
2. Use calculated attribute prompt undefined
Property or method "XXX" is not defined on the instance but referenced during render
Check whether more than one computed is written
3. oracle connection error archiving program error
Error message:
ORA-00257: Archiving program error. Only after the parsing is completed AS SYSDBA Mode connection
Enter oracle user
su oracle
Connect to oracle using sqlplus command
# sqlplus username/password@ip:port/sid sqlplus wwwcloud/xxx2020@134.xx:1521/ORCL
1. Check the space redo log\recovery file\flash_recovery_area_usage usage
select * from v$log; select * from v$recovery_file_dest; select * from v$flash_recovery_area_usage;
It can be seen that the remote login is not possible due to the full space of the armed log, and the armed log has reached 99.61%
Enter rman from oracle user
rman target /
Delete all archived logs 7 days ago
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
Execute again and find that the space of ARCHIVED LOG has been reduced
4. The springcloud gateway reported an error 403
Colleagues added a maven coordinate to the gateway, and then the verification code interface in the project began to report error 403. It was found that the gateway started to report error:
********************************************************** Spring MVC found on classpath, which is incompatible with Spring Cloud Gateway at this time. Please remove spring-boot-starter-web dependency. **********************************************************
It turns out that the spring cloud gateway is internally implemented through netty + weblux. The weblux implementation conflicts with the spring MVC configuration dependency.
exclusion: the spring boot starter web is lost. After the gateway is started, the access to the verification code interface is normal.
5. Same package name
The project was transformed from fat jar to thin jar, but it was found that classes with the same package name and the same name as the third party depended on the project code, resulting in the failure of external lib startup. The startup script added the jvm parameter - verbose:class to print the class loading process. It was found that the XXXService defined by colleagues was loaded before unpacking, and the flowable-engine-6.4.1 was loaded after unpacking XXXService in jar
Check meta-inf / manifest before and after unpacking MF file
Before unpacking:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven 3.5.3 Built-By: yzliu Build-Jdk: 11.0.8 Main-Class: org.springframework.boot.loader.JarLauncher Start-Class: com.gykjit.wf.WorkFlowApplication Spring-Boot-Version: 2.6.4 Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx Spring-Boot-Layers-Index: BOOT-INF/layers.idx
After unpacking:
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven 3.8.4 Built-By: root Build-Jdk: 11.0.8 Main-Class: org.springframework.boot.loader.PropertiesLauncher Start-Class: com.gykjit.wf.WorkFlowApplication Spring-Boot-Version: 2.3.1.RELEASE Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Spring-Boot-Classpath-Index: BOOT-INF/classpath.idx
Print the java virtual machine system properties in the startup class
ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(appClassLoader);
Properties sp = System.getProperties();
Enumeration e = sp.propertyNames();
while (e.hasMoreElements()) {
String key = (String) e.nextElement();
System.out.println(key + "=" + sp.getProperty(key));
}
Found the pre unpacking system attribute Java class. First load the class in the path, then load the external dependencies, and unpack Java class. There is no external dependency jar package in path, and the external dependency is through loader Path loading,
Summary: the starter used before unpacking is JarLauncher through Java class. The loading order of path is to load the class first, and the initiator after unpacking is PropertiesLauncher, which is through Java class. Path and loader Path loading, should be loader The path is loaded first, which causes the classloader to judge that the files with the same package name and the same name in the project code are repeated and ignored.
6. Server ping domain name failed
The server is connected to the Internet, but Ping Maven aliyun. Com doesn't work
Modify domain name resolution
/etc/resolv.conf
Note: this file will be restored after restart
7. nacos configuration does not update after modification
It can be seen from these lines of the project startup log that 1. The local configinfoprocessor loads the nacos local snapshot file, which is located in C:\Users244\nacos\config. It is speculated that the reason why nacos does not take effect after modifying the configuration is related to the local snapshot file. 2. Nacospropertysourcebuilder Loadnacosdata is the entry method for loading nacos configuration.
2022-03-07 18:11:33.769 [main] INFO c.a.n.c.c.i.LocalConfigInfoProcessor - [<clinit>,212] - LOCAL_SNAPSHOT_PATH:C:\Users\11244\nacos\config 2022-03-07 18:11:35.620 [main] INFO c.a.n.c.c.i.Limiter - [<clinit>,54] - limitTime:5.0 2022-03-07 18:11:35.650 [main] WARN c.a.c.n.c.NacosPropertySourceBuilder - [loadNacosData,87] - Ignore the empty nacos configuration and get it based on dataId[modules] & group[DEFAULT_GROUP] 2022-03-07 18:11:36.269 [main] WARN c.a.c.n.c.NacosPropertySourceBuilder - [loadNacosData,87] - Ignore the empty nacos configuration and get it based on dataId[modules.yml] & group[DEFAULT_GROUP]
The source code of loadNacosData is as follows, configservice Getconfig reads remote configuration information
private Map<String, Object> loadNacosData(String dataId, String group,
String fileExtension) {
String data = null;
try {
data = configService.getConfig(dataId, group, timeout);
if (StringUtils.isEmpty(data)) {
log.warn(
"Ignore the empty nacos configuration and get it based on dataId[{}] & group[{}]",
dataId, group);
return EMPTY_MAP;
}
if (log.isDebugEnabled()) {
log.debug(String.format(
"Loading nacos data, dataId: '%s', group: '%s', data: %s", dataId,
group, data));
}
Map<String, Object> dataMap = NacosDataParserHandler.getInstance()
.parseNacosData(data, fileExtension);
return dataMap == null ? EMPTY_MAP : dataMap;
}
catch (NacosException e) {
log.error("get data from Nacos error,dataId:{}, ", dataId, e);
}
catch (Exception e) {
log.error("parse data from Nacos error,dataId:{},data:{},", dataId, data, e);
}
return EMPTY_MAP;
}
After entering the getConfig method, you will find that the actual call is getConfigInner:
private String getConfigInner(String tenant, String dataId, String group, long timeoutMs) throws NacosException {
group = null2defaultGroup(group);
ParamUtils.checkKeyParam(dataId, group);
ConfigResponse cr = new ConfigResponse();
cr.setDataId(dataId);
cr.setTenant(tenant);
cr.setGroup(group);
// Local configuration is preferred
String content = LocalConfigInfoProcessor.getFailover(agent.getName(), dataId, group, tenant);
if (content != null) {
LOGGER.warn("[{}] [get-config] get failover ok, dataId={}, group={}, tenant={}, config={}", agent.getName(),
dataId, group, tenant, ContentUtils.truncateContent(content));
cr.setContent(content);
configFilterChainManager.doFilter(null, cr);
content = cr.getContent();
return content;
}
try {
String[] ct = worker.getServerConfig(dataId, group, tenant, timeoutMs);
cr.setContent(ct[0]);
configFilterChainManager.doFilter(null, cr);
content = cr.getContent();
return content;
} catch (NacosException ioe) {
...
}
...
}
Breakpoint debugging localconfiginfoprocessor Getfailover found that the content read through the snapshot three times is null, which is actually through worker Get the configuration information from getserverconfig and enter worker Getserverconfig method, we will find that the configuration information is actually obtained by calling the nacos server interface through the httpget method
public String[] getServerConfig(String dataId, String group, String tenant, long readTimeout)
throws NacosException {
String[] ct = new String[2];
if (StringUtils.isBlank(group)) {
group = Constants.DEFAULT_GROUP;
}
HttpRestResult<String> result = null;
try {
Map<String, String> params = new HashMap<String, String>(3);
if (StringUtils.isBlank(tenant)) {
params.put("dataId", dataId);
params.put("group", group);
} else {
params.put("dataId", dataId);
params.put("group", group);
params.put("tenant", tenant);
}
result = agent.httpGet(Constants.CONFIG_CONTROLLER_PATH, null, params, agent.getEncode(), readTimeout);
} catch (Exception ex) {
String message = String
.format("[%s] [sub-server] get server config exception, dataId=%s, group=%s, tenant=%s",
agent.getName(), dataId, group, tenant);
LOGGER.error(message, ex);
throw new NacosException(NacosException.SERVER_ERROR, ex);
}
...
}
It is concluded that the problem that the nacos configuration is not updated has nothing to do with the local snapshot file. So why isn't the configuration information read from the nacos server up-to-date? I was just at the breakpoint agent The httpGet method gets the request parameters and calls the nacos server in postman, which is not updated.
So I got the source code of nacos from git clone on github, switched to the develop ment branch, and set the java startup parameter to stand-alone startup
-Dnacos.standalone=true
After successful startup, simulate the HTTP get request through postman and enter the nacos source code configcontroller Getconfig method
@GetMapping
@Secured(action = ActionTypes.READ, signType = SignType.CONFIG)
public void getConfig(HttpServletRequest request, HttpServletResponse response,
@RequestParam("dataId") String dataId, @RequestParam("group") String group,
@RequestParam(value = "tenant", required = false, defaultValue = StringUtils.EMPTY) String tenant,
@RequestParam(value = "tag", required = false) String tag)
throws IOException, ServletException, NacosException {
// check tenant
ParamUtils.checkTenant(tenant);
tenant = NamespaceUtil.processNamespaceParameter(tenant);
// check params
ParamUtils.checkParam(dataId, group, "datumId", "content");
ParamUtils.checkParam(tag);
final String clientIp = RequestUtil.getRemoteIp(request);
String isNotify = request.getHeader("notify");
inner.doGetConfig(request, response, dataId, group, tenant, tag, isNotify, clientIp);
}
It is found that the configuration information of the default namespace is queried, and we use our own defined namespace.
So why does the program start to get the configuration information under the default namespace? After investigation, it is found that colleagues have modified the springboot startup process and set the namespace spring for service discovery in the code cloud. nacos. discovery. The namespace property, but the registry namespace spring. Is not set cloud. nacos. config. Namespace, the namespace that causes service discovery is user-defined, and the namespace of the registry is the default namespace.