HttpUrlConnection会复用tcp链接

[chunlaiqingke]

在使用中使用tcpdump抓包发现，客户端在调长连接接口时结束之后，即使stream被close了，tcp也不会触发FIN，而是下次调notification接口时还是在原来的tcp上进行传输。
但是掉queryConfig接口则会触发FIN，但是Sync和Fin间隔120秒

[chunlaiqingke]

这是正常的吗，现在有业务方反映他们服务出现大量close_wait，怀疑是客户端的问题，他们的服务器用的weblogic

[chunlaiqingke]

他们的服务作为客户端，他们抓包，所有的请求，notification和getConfig接口都会触发fin，异常的时候是，客户端接受到304之后20秒内没有FIN掉链接，而是20秒时服务端触发FIN，这样客户端就处于close_wait，这个20秒应该是服务端的connectionTimeout的值导致的

[nobodyiam]

1. 看 tcpdump 的截图，请求频率很低，所以不应该产生『大量』的 close wait
2. close wait 本身也是正常的连接状态，对服务的影响是啥？

[chunlaiqingke]

我们已经查出来了，是apollo-client中的DefaultHttpClient类

HttpURLConnection conn = (HttpURLConnection) new URL(httpRequest.getUrl()).openConnection()

生成连接那行的openConnection() 方法在WebLogic上执行的时候返回的是WebLogic自己的类，那个类没有keepAlive（从tcpdump结果来看），是有问题的
所以需要使用webLogic的启动参数DUseSunHttpHandler=true，来让openConnection生成sun的类，就和其他的抓包结果一样

[chunlaiqingke]

回答您的问题：
1.请求频率没问题，是正常的，但是请求完之后，客户端拿到304的之后，没有立刻出发下一次请求，而是等待十几二十秒之后，发了一个FIN结束连接，当十几秒还行，服务端的connectionTimeout是20秒，客户端不会出现close_wait，但是超过20秒的时候，服务端超时主动先FIN，客户端就是close_wait。这样积累就会大量的，业务方说多的有2000多，都是apollo的连接
2.其他用tomcat的服务都是正常的，close_wait只有1-2个。影响就是close_wait量大的告警，别的指标都是正常的

[kimmking]

使用JDK自带的半拉子http client，总是有各种莫名其妙的问题。

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[chunlaiqingke]

使用JDK自带的半拉子http client，总是有各种莫名其妙的问题。

是weblogic的问题

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had activity in the last 7 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.