原文引用 大专栏 https://www.dazhuanlan.com/2019/08/22/5d5e73c98f48d/
部署项目时，能不能只同步进程，不重启tomcat
可以的，只是会报个错，这应该是之前的线程报的错误，不影响新部署的进程的使用：
Unable to register MBean [org.springframework.boot.actuate.endpoint.jmx.DataEndpointMBean@1e6a6993] with key ‘autoConfigurationReportEndpoint’; nested exception is javax.management.InstanceAlreadyExistsException: infomine:type=Endpoint,name=autoConfigurationReportEndpoint
常见报错
[main] DEBUG org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name [java:comp/env/logging.PATTERN.FILE] not found - trying original name [logging.PATTERN.FILE]. javax.naming.NameNotFoundException: Name [logging.PATTERN.FILE] is not bound in this Context. Unable to find [logging.PATTERN.FILE].
原因：JNDI在logback还未初始化的时候，用到了logback
解决方案：https://stackoverflow.com/questions/42446013/spring-jndi-logging-before-logback-is-initialized
JNDI是什么：https://www.cnblogs.com/zhchoutai/p/7389089.html
18:40:47.114 [main] DEBUG org.springframework.jndi.JndiLocatorDelegate - Converted JNDI name [java:comp/env/LOGGING_PATTERN_LEVEL] not found - trying original name [LOGGING_PATTERN_LEVEL]. javax.naming.NameNotFoundException: Name [LOGGING_PATTERN_LEVEL] is not bound in this Context. Unable to find [LOGGING_PATTERN_LEVEL].
I also had the same problem, but I couldn’t turn off jndi, because my application is using it on startup. So after some research, I ended up with the solution:
1) rename logback-spring.xml to some other name, for example logback-config.xml
2) put logging.config property into application.properties file.
As the result you configuration will be applied only on spring startup, and this debug logging will be skipped. Also in my case the first solution wasn’t working because I needed jndi, in this case you also leave jndi enabled.
Update: this helped only for local environment, to make the same work on remote tomcat and remove this debug log from catalina.log file, I ended up with renaming this logback file to logback.xml, thus it’s found on the startup, before jndi lookup.
从StackOverflow的这个回答来看，远程服务器上部署的进程，得修改logback配置文档的名称才行。
后来发现，原来是因为application.yml里面忘记修改了。其实和上面的报错是同一个问题。
测试环境因为是直接在测试服务器上修改的，改完就直接编译部署，所以测试环境观察到问题是解决了；而内网代码库上还没修改，我们线上的发布，都是从内网代码库拿进程编译部署的，因此线上就出问题了。
org.apache.tomcat.util.http.parser.Cookie.logInvalidHeader A cookie header was received [1533551432; user=MDpob3VwaW5waW46Ok5vbmU6NTAwOjM3OTQzMDg2MTo3LDExMTExMTExMTExLDQwOzQ0LDExLDQwOzYsMSw0MDs1LDEsNDA7MSwxLDQwOzIsMSw0MDszLDEsNDA7NSwxLDQwOzgsMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDEsNDA6OTo6OjM2OTQzMDg2MToxNTM0OTAwMTk0Ojo6MTQ4MjM3NTYwMDo0MDI2MDY6MDoxMGNjMzM1YTRjNTg3YWM0ZGM1MDJkYmU0NTZkOTRkYzQ6OjA%3D; userid=369430861; u_name=houpinpin; escapename=houpinpin; ticket=d48d1078f46b9869a7d26b0808ba0328; @#!userid!#@=369430861; @#!sessionid!#@=17bd9e0483445a3b391e98d07b33434e5; @#!rsa_version!#@=default_2; v=Al5Sm1lMifVdFN0RgW-5GTXgr_-jHyKZtOPWfQjnyqGcK_SjcK9yqYRzJozb] that contained an invalid cookie. That cookie will be ignored.Note: further occurrences of this error will be logged at DEBUG level.
参考这个文章：https://www.cnblogs.com/passedbylove/p/7587142.html
高版本的Tomcat，对于Cookie的格式验证规则做了一些变更。
上面的cookie，按照key-value拆分后，如下：
1533551432; user=MDpob3VwaW5waW46Ok5vbmU6NTAwOjM3OTQzMDg2MTo3LDExMTExMTExMTExLDQwOzQ0LDExLDQwOzYsMSw0MDs1LDEsNDA7MSwxLDQwOzIsMSw0MDszLDEsNDA7NSwxLDQwOzgsMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDEsNDA6OTo6OjM2OTQzMDg2MToxNTM0OTAwMTk0Ojo6MTQ4MjM3NTYwMDo0MDI2MDY6MDoxMGNjMzM1YTRjNTg3YWM0ZGM1MDJkYmU0NTZkOTRkYzQ6OjA%3D;
userid=369430861;
u_name=houpinpin;
escapename=houpinpin;
ticket=d48d1078f46b9869a7d26b0808ba0328;
@#!userid!#@=369430861;
@#!sessionid!#@=17bd9e0483445a3b391e98d07b33434e5;
@#!rsa_version!#@=default_2;
v=Al5Sm1lMifVdFN0RgW-5GTXgr_-jHyKZtOPWfQjnyqGcK_SjcK9yqYRzJozb
猜测会不会是第一个数字没有遵循key-value格式的缘故？
我抓包看了我们官网的请求，cookie都是key-value键值对。上面的cookie应该是一个异常的cookie
Caused by: java.io.FileNotFoundException: /usr/local/tomcat/webapps/infomine/infomine/WEB-INF/lib/spring-boot-starter-thymeleaf-1.5.6.RELEASE.jar (没有那个文档或目录)
这个报错只出现了一次，刚好是jenkins同步时报的，说明这是发生在部署过程中的。
jenkins是18:39同步的
异常也是18:39抛出的
查看tomcat进程，是18.41起来的
然后我再次查看了下我给运维的发布邮件，发现操作顺序有问题。邮件里面先让他们同步jenkins，再关闭tomcat，重新启动tomcat。这就导致jenkins同步过程中，应用还是在跑着的；而jenkins里面我写了一行命令：
这就导致同步时，webapps下面的文档被删了，而应用还跑着，所以就爆出上面的错误了。
因此，发布操作一定要在测试服务器验证一遍，确认无误，才发给运维！
控制面板-2018-08-22 18:40:24 [ContainerBackgroundProcessor[StandardEngine[kiv]]] ERROR org.springframework.boot.actuate.endpoint.jmx.EndpointMBeanExporter - Could not register JmxEndpoint [auditEventsEndpoint]
org.springframework.jmx.export.UnableToRegisterMBeanException: Unable to register MBean [org.springframework.boot.actuate.endpoint.jmx.AuditEventsJmxEndpoint@31b82549] with key ‘auditEventsEndpoint’; nested exception is javax.management.InstanceAlreadyExistsException: kiv:type=Endpoint,name=auditEventsEndpoint
我们已经给每个项目设置了不同的jmx，这个报错应该和上面的报错一样，都是因为重新部署的顺序有误，没有先关闭kiv应用，然后直接删除文档，更新了war包导致的。
可以看到有一个报错：javax.management.InstanceAlreadyExistsExceptio，明确指出了是实例已存在，之前的应用还没销毁。