newtypebao

基于tomcat服务器的CPU使用率，重启tomcat

Mon, 23 Sep 2024 00:00:00 +0000

基于tomcat部署的javaweb项目中可能会遇到下面这个场景：由于应用功能里有个大报表、大查询又或者别的复杂的逻辑，把某一个tomcat所在服务器的cpu给搞满了。此时这个tomcat上的用户都巨卡。原则上遇到上述情况应当排查具体的程序或者接口是不是有逻辑上的优化方法。以下是退一万步而言的终极方案，一个基于tomcat服务器的CPU使用率，重启tomcat。可以结合操作系统的定时任务执行，比如每5分钟扫描一次。如果命中规则(cpu>90%)就重启这个tomcat.

	#!/bin/bash
	#需要在服务器内安装一下两个组件1.sysstat   2.bc

	# 定义toncat目录
	tomcatPath=/usr/local/tomcat
	# 定义日志文件
	log_file="/tmp/tomcat_thread_monitor.log"


	# 获取Tomcat进程的主进程ID
	tomcat_pid=$(pgrep -f catalina)

	# 检查是否找到了Tomcat进程
	if [ -z "$tomcat_pid" ]; then
		echo "Tomcat process not found."
		exit 1
	fi

	# 获取当前cpu使用率
	cpu_usage=$(top -bn1 | grep "Cpu(s)" | awk '{print $2 + $4}')

	# 获取当前日期和时间
	current_date=$(date)

	# 记录开始检查的时间
	echo "Tomcat usage at $current_date is $cpu_usage"

	# 检查CPU使用率是否超过90%
	if (( $(echo "$cpu_usage > 90" | bc -l) )); then
		echo "CPU usage is above 90% ($cpu_usage%). Restarting Tomcat..."
		echo "$current_date: CPU usage is above 90% ($cpu_usage%). Restarting Tomcat">> $log_file
		# 重启Tomcat服务
		sh "$tomcatPath/bin/shutdown.sh"
		sleep 10
		kill -9 $tomcat_pid
		sleep 5
		#启动tomcat
		sh "$tomcatPath/bin/startup.sh"
	else
		echo "CPU usage is below 90% ($cpu_usage%). No action taken."
	fi

Spring通过RestTemplate使用POST方式请求指定接口

Wed, 19 Jan 2022 00:00:00 +0000

java开发功能中会有需要发起请求调用外部的系统。系统运维过程中，有大批量数据需要调用指定的接口修改数据，java代码样例如下：

使用POST方式调用；

	public static void main(String[] args) {
		RestTemplate restTemplate = new RestTemplate();
		//  解决中文乱码
		restTemplate.getMessageConverters().set(1,new StringHttpMessageConverter(StandardCharsets.UTF_8));
		// 构建请求头
		HttpHeaders requestHeaders = new HttpHeaders();
		requestHeaders.setBearerAuth("tokenString");
		requestHeaders.setContentType(MediaType.APPLICATION_JSON);
		// 入参为json体
		String reqJsonStr = "{\"code\":\"testCode\", \"group\":\"testGroup\",\"content\":\"testContent\", \"order\":1}";
		HttpEntity<String> requestEntity = new HttpEntity<>(null, requestHeaders);
		// 发起请求
		ResponseEntity<String> json =restTemplate.exchange("https://xxx1/yyy1/zzz1/postmethod?userId=12345", HttpMethod.GET, requestEntity,String.class);
		System.out.println(json);
	}

使用GET方式调用：

	public static void main(String[] args) {
		RestTemplate restTemplate = new RestTemplate();
		restTemplate.getMessageConverters().set(1,new StringHttpMessageConverter(StandardCharsets.UTF_8));
		HttpHeaders requestHeaders = new HttpHeaders();
		requestHeaders.setBearerAuth("tokenString");
		HttpEntity<String> requestEntity = new HttpEntity<>(null, requestHeaders);
		ResponseEntity<String> json =restTemplate.exchange("https://xxx2/yyy2/zzz2/gettmethod?userId=12345", HttpMethod.GET, requestEntity,String.class);
	}

Windows下bat脚本判断(tomcat)端口是否可用

Thu, 23 Aug 2018 00:00:00 +0000

考虑到目前项目组所使用的windows server服务器上部署的tomcat总是不定期的自动关闭，经过讨论初步准备的解决方案是希望有个脚本能定时扫描系统中tomcat是否开启，如果未开启，则自动启动tomcat.

脚本如下：

注：以上脚本中需要将tomcat的目录设置到windows的环境变量中（CATALINA_HOME）

@echo off
echo.Check that the tomcat port is open
set num=8080
for /f "tokens=3 delims=: " %%a in ('netstat -an') do (
echo."%%a"
if "%%a"=="%num%" goto en
)
if not "%%a"=="%num%" goto en1
:en
echo.Checking For local port %NUM% is Opening...
exit
:en1
echo.Checking For local port %NUM% is Not Opening...
echo.Starting Tomcat Program...
call "%CATALINA_HOME%"\bin\startup.bat
echo.Starting Succes!
echo.OK!
exit

主要命令说明：

for /f “tokens=3 delims=: “ %%a in (‘netstat -an’) ：

根据netstat -an命令的返回结果进行文本的切割，切割的关键字是冒号和空格。将文本中的每行内容根据关键字切割成多列，并且只使用第三列，即端口号信息。通过循环比对目前系统使用中的端口号，监测8080端口是否开启。未开启的话就执行tomcat的启动程序。

然后，将上面的脚本设置为windows的计划任务，根据项目组的实际情况，设定计划任务执行的时间间隔即可。

nginx之iphash算法

Sat, 28 Jul 2018 00:00:00 +0000

今日客户生产环境中发现了个奇怪的现象：nginx的upstream中部署了10多台后端服务器，但是在实际的监控中发现用户的请求只负载到了其中3-4台服务器。虽然后来已经证实是由于nginx前还有部署WAF，导致了获取到的ip非用户的真实ip，从而导致了负载的混乱。

问题发生期间，客户it方面经过讨论，原先提了一个这样的一个解决方案：他们认为现在不是配置了10来台，现在实际只负载到3-4台上吗？那么我们直接把剩下没有负载到的后端服务器从负载清单里去除掉，然后把剩下被负载到的几台服务器进行配置升级（用的阿里云，可以弹性扩展）。这样真的可以解决问题吗？我们一般会想到iphash如果后台服务器的配置总数发生了变化，那么其转发的规则也会自然发生变化，也就是说后端配置了10台服务器负载了到3台上，那么把配置修改为3台的话，很可能就转发到1-2台上了。我们来看下nginx iphash的算法，是否可以验证上面的说法。

直接看代码：

   for ( ;; ) {

       for (i = 0; i < (ngx_uint_t) iphp->addrlen; i++) {
           hash = (hash * 113 + iphp->addr[i]) % 6271;
       }

       w = hash % iphp->rrp.peers->total_weight;
       peer = iphp->rrp.peers->peer;
       p = 0;

       while (w >= peer->weight) {
           w -= peer->weight;
           peer = peer->next;
           p++;
       }

       n = p / (8 * sizeof(uintptr_t));
       m = (uintptr_t) 1 << p % (8 * sizeof(uintptr_t));

       if (iphp->rrp.tried[n] & m) {
           goto next;
       }

       ngx_log_debug2(NGX_LOG_DEBUG_HTTP, pc->log, 0,
                      "get ip hash peer, hash: %ui %04XL", p, (uint64_t) m);

       ngx_http_upstream_rr_peer_lock(iphp->rrp.peers, peer);

       if (peer->down) {
           ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer);
           goto next;
       }

       if (peer->max_fails
           && peer->fails >= peer->max_fails
           && now - peer->checked <= peer->fail_timeout)
       {
           ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer);
           goto next;
       }

       if (peer->max_conns && peer->conns >= peer->max_conns) {
           ngx_http_upstream_rr_peer_unlock(iphp->rrp.peers, peer);
           goto next;
       }

       break;

   next:

       if (++iphp->tries > 20) {
           ngx_http_upstream_rr_peers_unlock(iphp->rrp.peers);
           return iphp->get_rr_peer(pc, &iphp->rrp);
       }
   }

主要代码在180-184的几行。

1、for循环 i取 012三个值，而ip的点分十进制表示方法将ip分成四段（如：192.168.1.1），但是这里循环时只是将ip的前三个端作为参数加入hash函数。这样做的目的是保证ip地址前三位相同的用户经过hash计算将分配到相同的后端server。

作者的这个考虑是极为可取的，因此ip地址前三位相同通常意味着来着同一个局域网或者相邻区域，使用相同的后端服务让nginx在一定程度上更具有一致性。

2、哈希函数：hash = (hash * 113 + iphp->addr[i]) % 6271

作者使用了这样一个极为简单的hash函数，当然目的是为了性能。虽然该hash函数的效果并不是很好，产生的的分布并不是太均衡。但这在nginx选择后端server这样的应用场景已经足够，关键是其简单性。

3、iphash后如何决定分配在哪台服务器上？从184行的代码w = hash % iphp->rrp.peers->total_weight;可以看到：把ip地址hash以后，立刻就针对当前总共的服务器个数取模。那么也就初步证实了后端服务器的总数是会直接影响到负载的规则，证实了之前的设想。故解决之前的问题，最正确合理的做法，还是需要通过nginx的realip模块，把WAF的ip过滤掉才是正确且合理的做法。

【转】《王者荣耀》各职业铭文搭配概要

Thu, 26 Jul 2018 00:00:00 +0000

王者中有6种职业，不同职业对于铭文的需求不同，在30种铭文中，比较常用的也就10余种。对于铭文的使用，下面就概括性的按英雄类型给大家分析一波。

1、战士

战士铭文比较单一，要么狩猎百穿，要么隐匿百穿，完全不需要攻速的用隐匿百穿，其它就带狩猎百穿。当然，战士中也有比较特殊的，如老夫子、曹操需要带26攻速，宫本、铠可以走暴击流，吕布带肉铭文，还有一些法战，带的当然是法术铭文。不过大多数的战士，还是百穿这一套。

2、坦克

坦克的铭文大致可以分两类，一种是打伤害的坦克，带一手隐匿百穿，能打出不俗的伤害，白起、项羽、钟无艳，甚至牛魔都可以用。还有一种是纯肉坦克，带的是调和宿命虚空，这套铭文真的是贼肉，相当于出门多了一件大防御装。当然，还有少量的法伤坦克，比如庄周，要么带贪婪怜悯梦魇打输出，要么带调和虚空宿命堆肉度。

3、辅助

辅助可以分为两类，一是法伤辅助，二是物伤辅助。法伤辅助推荐带调和、怜悯、梦魇这一套，因为法伤辅助多为功能性辅助，对于冷却缩减的需求更高，比如孙膑、鬼谷子、大乔等等。物伤辅助只要堆肉就可以了，调和虚空宿命这一套就行。

4、刺客

刺客对于铭文的分歧主要在红色铭文上，一种是异变党，一种是无双党，打技能伤害的就用异变，比如李白、娜可露露、兰陵王等等，打普攻伤害的就带无双，如韩信、百里玄策这些。至于蓝色铭文，要么吸血的夺萃，要么狩猎，这个不分英雄，按自己的习惯带，两种混搭也可以。

5、法师

大部分的法师，可以使用这两套铭文：（轮回献祭梦魇）（轮回心眼梦魇），这两套铭文可以解决大多数法师铭文的使用。还有一些特殊法师，如需要攻速的法师，那就从狩猎、凶兆、红月中选择使用；或者是需要续航的中路法师，蓝色铭文带一手调和没毛病，比如诸葛亮、高渐离等等。

6、射手

对于射手这个职业，两种铭文搭配基本可以解决，狩猎鹰眼无双，这套铭文适配大部分射手。李元芳、虞姬、百里守约这三个射手用狩猎鹰眼异变。当然，射手打野又另一说了，蓝色铭文在夺萃和狩猎之间选择。

铭文是死的，玩家是活的，没有哪个英雄的铭文搭配是固定不变的，还是需要根据玩家的习惯喜好来使用，就比如刘备打野，有些玩家就喜欢带狩猎，跑得快；也有些玩家就喜欢带夺萃，吸的快；还有些玩家两样都带，比较均衡。一个英雄玩时间长了，知道自己更喜欢什么风格，才能搭配出对自己来说最好的铭文。

【转】https下HttpServletResponse_sendRedirect跳转到http的解决方法

Thu, 19 Jul 2018 00:00:00 +0000

问题描述

最近全站上线SSL，架构如下：

                 |
                 |(https)
                 |
                SLB
                 |
          WebServer (Nginx)                外网   
         /       |      \
       /         |       \                    内网
     /(http)     |(http)  \(http)
   Container1  Container2   Container3

近日项目中使用了阿里的SLB,在外网使用SSL，然后使用反向代理到具体的Web Container，内网依然使用HTTP进行传输，这样可以节省一些资源，效率也比较高。不过这样做的时候发现所有的 HttpServletResponse.sendRedirect 方法使用相对地址的时候都会跳转到80端口，而不是443，经过查找了一些网上的资源，综合发现下面的几种解决方案。目前项目中暂时使用第一个解决方案（绝对路径），供有需要的同学们参考：

解决方案

跳转的时候url使用绝对地址，而不是相对地址关键代码如下：

String url = "/login";
// 将相对地址转换成https的绝对地址
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse)resp;
String scheme = request.getScheme();
String serverName = request.getServerName();
int port = request.getServerPort();
String contextPath = request.getContextPath();
String servletPath = request.getServletPath();
String queryString = request.getQueryString();

StringBuilder sbd = new StringBuilder();
// 强制使用https
sbd.append("https").append("://").append(serverName)
if(port != 80 && port != 443) {
    sbd.append(":").append(port);
}
if(contextPath != null) {
    sbd.append(contextPath);
}
if(servletPath != null) {
    sbd.append(servletPath);
}
sbd.append(url);
if(queryString != null) {
    sbd.append(queryString);
}

// 绝对地址
response.sendRedirect(sbd.toString());

可以的参考Spring Security的 org.springframework.security.web.util.RedirectUrlBuilder 代码。

创建一个强制转换的过滤器

将上面的代码封装成一个ResponseWrapper，覆盖到sendRedirect方法中，然后在过滤器中进行调用，核心代码如下： RedirectResponseWrapper.java

public class RedirectResponseWrapper extends HttpServletResponseWrapper {

    private final HttpServletRequest request;

    public RedirectResponseWrapper(final HttpServletRequest inRequest,
            final HttpServletResponse response) {
        super(response);
        this.request = inRequest;
    }

    @Override
    public void sendRedirect(final String pLocation) throws IOException {
        if (StringUtils.isBlank(pLocation)) {
            super.sendRedirect(pLocation);
            return;
        }

        try {
            final URI uri = new URI(pLocation);
            if (uri.getScheme() != null) {
                super.sendRedirect(pLocation);
                return;
            }
        } catch (URISyntaxException ex) {
            super.sendRedirect(pLocation);
        }

        // !!! FIX Scheme !!!
        String scheme = request.getScheme();
        String serverName = request.getServerName();
        int port = request.getServerPort();
        String contextPath = request.getContextPath();
        String servletPath = request.getServletPath();
        String queryString = request.getQueryString();

        StringBuilder sbd = new StringBuilder();
        // 强制使用https
        sbd.append("https").append("://").append(serverName)
        if(port != 80 && port != 443) {
            sbd.append(":").append(port);
        }
        if(contextPath != null) {
            sbd.append(contextPath);
        }
        if(servletPath != null) {
            sbd.append(servletPath);
        }
        sbd.append(url);
        if(queryString != null) {
            sbd.append(queryString);
        }

        super.sendRedirect(sbd.toString());
    }
}

创建一个过滤器，并在web.xml中启用

public class AbsoluteSendRedirectFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        RedirectResponseWrapper redirectResponseWrapper = new RedirectResponseWrapper(request, response);
        filterChain.doFilter(request, redirectResponseWrapper);
    }
}

web.xml

<filter>
    <filter-name>AbsoluteSendRedirectFilter</filter-name>  
    <filter-class>com.rensanning.core.filter.AbsoluteSendRedirectFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>AbsoluteSendRedirectFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

将Spring MVC中viewResolver的redirectHttp10Compatible属性设置为false

如果使用Spring的话，可以将viewResolver的redirectHttp10Compatible属性设置为false，代码如下：

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">  
  <property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />  
  <property name="prefix" value="/" />  
  <property name="suffix" value=".jsp" />  
  <property name="redirectHttp10Compatible" value="false" />  
</bean>  

在Nginx中设置X-Forwarded-Proto

上面的方法使用了一种强制的方式，但真正传输到后端容器中的依然是HTTP协议，Spring Security等使用 ServletRequest#isSecure() 方法判断是否是SSL环境，可以使用Nginx进行反向代理的时候，设置X-Forwarded-Proto，关键设置如下：

location / {
    proxy_next_upstream http_502 http_504 error timeout invalid_header;
    proxy_set_header Host  $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_pass http://tdt_server;
    proxy_redirect off;
}

将Host由$host修改为$http_host，区别是后者包含端口号，而前者不包含。还需要后端的容器能够识别，在Tomcat中可以使用 RemoteIpValve 进行设置：

<Valve className="org.apache.catalina.valves.RemoteIpValve"
    internalProxies="192\.168\.0\.10|192\.168\.0\.11"
    remoteIpHeader="x-forwarded-for"
    proxiesHeader="x-forwarded-by"
    protocolHeader="x-forwarded-proto" />

Resin4.0中可以在resin.xml中通过 resin:SetRequestSecure 设置：

<web-app xmlns="http://caucho.com/ns/resin"
         xmlns:resin="urn:java:com.caucho.resin">
    <resin:SetRequestSecure>
        <resin:IfHeader name="X-Forwarded-Proto" value="https" />
    </resin:SetRequestSecure>
</web-app>

在Resin4.0中如果想针对特定的地址使用http，可以使用下面的设置：

<web-app xmlns="http://caucho.com/ns/resin"
         xmlns:resin="urn:java:com.caucho.resin">
    <resin:Redirect regexp="^/yyy/" target="http://myhost.com/yyy/">
        <resin:IfSecure value="true"/>
    </resin:Redirect>
</web-app>

在Nginx中使用rewrite

还有一种简单的方式，直接在Nginx中将所有80的请求自动设置成301跳转，设置如下：

server {
    listen 80;
    server_name example.com;

    location / {
        rewrite ^(.*) https://$server_name$1 permanent;
    }
}
server {
    listen 443;
    server_name example.com;

    ssl on;
    ssl_certificate   cert.pem;
    ssl_certificate_key  cert.key;
    ssl_session_timeout 5m;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_next_upstream http_502 http_504 error timeout invalid_header;
        proxy_set_header Host  $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_pass http://tdt_server;
        proxy_redirect off;
    }
}

经过这样设置，遇到跳转的时候等于需要跳转两次，先是从https跳转到http，然后因为nginx设置的原因，又从http跳转到https，虽然解决方法粗暴了一些，但是能够忽略后端不同的Java Web Container的差异。

《我的前半生》--职场经典语录

Fri, 13 Jul 2018 00:00:00 +0000

新人篇

第1句。谁找工作时不是抱着百分百真诚的态度，但是态度有用的话，找不到工作的人就不会那么多了。经验和技能才是你的立足根本，在没有经验的时候，不要挑挑拣拣，先工作起来才是重要的。

第2句。一旦你开始工作了，这就相当于是开启了闯关游戏的大门。你要去找到你的同伴。同伴你可以信任他，但是不能依赖他。

第3句。我觉得吃饭的时间，也要有效利用起来做些什么和学点什么。一天3个小时，一周下来就比别人多出一天时间。

交际篇

第4句。你来工作是来赚钱的，不是来交朋友的。如果能交到朋友那是惊喜，交不到朋友那才是正常的。

第5句。不要去做客户没有要求你去做的事情，不要给客户免费的午餐，你是计时收费的，而且还不便宜。

第6句。对待客户有有张有弛，要去体会他们，为他们考虑，但是要恰到好处的考虑。

提升篇

第7句。说过的话，就不能收回，不能让步，否则你就是一个可以被讨价还价的人，后患无穷。

第8句。你要知道你的上级是谁，并且要知道他们的爱好，嗜好和兴趣，因为每一个人，最喜欢的东西，往往是他的弱点所在，也是最容易被利用的突破口。

第9句。实战之前，必须预演，以排除一切意外的可能。没有人会在乎你所谓的特殊情况，更没有人有心情，有时间去听你解释。

终极篇

第10句。职场上你一定要做到可以取代任何人，然后再考虑做到任何人都不可以取代你。

身处职场的你，最害怕的就是失去竞争力，不被同事看好，也不被领导看中，一辈子浑浑噩噩，终无成就。

职场如人生，想要过好职场这一生，就要努力学习提升职场技能，这才是叫嚣的资本。

路要自己一步步走，苦要自己一口口吃，只有经历痛苦我们才能明白成功的定义！

Apache Tomcat Versions

Fri, 13 Jul 2018 00:00:00 +0000

Apache Tomcat® is an open source software implementation of the Java Servlet and JavaServer Pages technologies. Different versions of Apache Tomcat are available for different versions of the Servlet and JSP specifications. The mapping between the specifications and the respective Apache Tomcat versions is:

Servlet Spec	JSP Spec	EL Spec	WebSocket Spec	JASPIC Spec	Apache Tomcat Version	Latest Released Version	Supported Java Versions
4.0	2.3	3.0	1.1	1.1	9.0.x	9.0.10	8 and later
3.1	2.3	3.0	1.1	1.1	8.5.x	8.5.32	7 and later
3.1	2.3	3.0	1.1	N/A	8.0.x (superseded)	8.0.53 (superseded)	7 and later
3.0	2.2	2.2	1.1	N/A	7.0.x	7.0.90	6 and later (7 and later for WebSocket)
2.5	2.1	2.1	N/A	N/A	6.0.x (archived)	6.0.53 (archived)	5 and later
2.4	2.0	N/A	N/A	N/A	5.5.x (archived)	5.5.36 (archived)	1.4 and later
2.3	1.2	N/A	N/A	N/A	4.1.x (archived)	4.1.40 (archived)	1.3 and later
2.2	1.1	N/A	N/A	N/A	3.3.x (archived)	3.3.2 (archived)	1.1 and later

Each version of Tomcat is supported for any stable Java release that meets the requirements of the final column in the table above.

reference:http://tomcat.apache.org/whichversion.html

关于通过jcifs无法登陆centos7中SMB服务的问题

Thu, 05 Jul 2018 00:00:00 +0000

最近客户需要将自己部署在IDC机房的系统迁移到阿里云上，由于之前的系统是前几年开发的，当时使用是Centos6系统，考虑到系统中主要使用到的是jdk\java\smb这些常用的服务，而这些服务在最新的CentOS中运行的还是比较稳定的，因此本次迁移到阿里云上采用的是Centos7。

在系统迁移实施过程中，大部分进行的还是比较顺利的，比如原来用的是tomcat6+jdk1.6(这两个版本到各自的官网上都已经找不到了。。-_-!),从原服务器上搬到centos7上运行都还算正常。

只有应用中出现的一个问题比较奇怪：由于程序没有做过任何变动，部署到新环境中涉及到通过smb向远程文件服务器写文件的时候，总是报用户名和密码不对,像下面这个报错：

Caused by: jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password. at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:515) at jcifs.smb.SmbTransport.send(SmbTransport.java:629)

这个比较奇怪，期初我怀疑这个是我建的smb服务用户名密码和应用设置的不匹配，但是通过再三比对，确定使用的smb用户名和密码是没问题的。但这个错误依旧是那么明确unknown user name or bad password。。。

通过搜索了网上资源，目前是在tomcat中调整了jvm的可选参数： jcifs.smb.lmCompatibility=3

重新测试后，表现正常。其原因，目前推测还是centos6和centos7中的smb服务的版本不一致导致，具体还没了解清楚。

之前baidu上搜索了很久才在一些英语资料上找到的解决方法，特此总结，以供有相似经历的人分享。

关于nginx中iphash不生效的解决方案

Tue, 19 Jun 2018 00:00:00 +0000

最近客户需要将自己部署在阿里云上的系统从可用区A迁移到可用区E,所有服务器人工重新搭建（不愿意走镜像-_-!)，系统总体的结构是:SLB->WEB SERVER(nginx)->APP SERVER(TOMCAT),项目实施过程中配置nginx时遇到一个很奇怪的问题：

外网访问者每次从外网SLB访问系统时，总是会路由到某2个固定的后端ECS上（后端总共有十多台ECS)。这个比较奇怪，因为理论上根据配置，nginx会通过iphash的规则，根据不同的外网ip转发到后端服务器。然后后台总共有10多台服务器，用了100个外网地址测试，还是固定的那么2个后端ECS，感觉明显是有问题的。然后，开始了排查之旅。。

首先先从阿里角度排查，怀疑是否有可能是SLB里需要什么特别的配置，比如没有把实际的客户端IP放进来？查阅了阿里的资料发现如下：

四层负载均衡（TCP协议）服务可以直接在后端ECS上获取客户端的真实IP地址，无需进行额外的配置。
七层负载均衡（HTTP/HTTPS协议）服务需要对应用服务器进行配置，然后使用X-Forwarded-For的方式获取客户端的真实IP地址。
真实的客户端IP会被负载均衡放在HTTP头部的X-Forwareded-For字段，格式如下：
X-Forwarded-For: 用户真实IP, 代理服务器1-IP，代理服务器2-IP，...
当使用此方式获取客户端真实IP时，获取的第一个地址就是客户端真实IP。

由于原SLB是四层的（TCP协议），新环境的SLb是七层的（HTTPS协议），客户要用7层的，那么我尝试在nginx配置中告知Nginx真实客户端IP从哪个请求头获取，在server中增加配置：
real_ip_header X-Forwarded-For;

重新测试后，发现效果还是老样子，无改善。继续。。发现nginx access日志中大量的访问ip大都是在一个地址段，100.x.x.x,继续查阅阿里资料，了解到这些访问的来源都是由负载均衡系统发起的，地址段为100.64.0.0/10。因此，继续在server中增加配置：
set_real_ip_from 100.64.0.0/10;
real_ip_recursive on;

顺便说明一下这两个配置的作用：
set_real_ip_from192.168.0.0/16：告知Nginx哪些是反向代理IP，即排除后剩下的就是真实客户端IP，支持配置具体IP地址、CIDR地址；
real_ip_recursive on：是否递归解析，当real_ip_recursive配置为off时，Nginx会把real_ip_header指定的请求头中的最后一个IP作为真实客户端IP；当real_ip_recursive配置为on时，Nginx会递归解析real_ip_header指定的请求头，最后一个不匹配set_real_ip_from的IP作为真实客户端IP。

重新测试后，表现正常。

之前baidu上搜索都无法直接定位到这个情况以及原因，特此总结，以供有相似经历的人分享。