从Linux到MS SQL Server 2008的JDBC连接在40秒后超时

如何解决从Linux到MS SQL Server 2008的JDBC连接在40秒后超时

|| [查看底部的更新] 我正在使用JDBC从运行带有2.6.32-32服务器内核的Ubuntu 10.04 LTS的计算机上的Windows 2008 R2计算机上的SQL Server 2008 R2运行语句。我正在使用适用于Ubuntu的当前Sun Java 6构建版本(sun-java6-jdk 6.24-1build0.10.04.1)和MS \的当前JDBC 3.0驱动程序(sqljdbc_3.0.1301.101_enu)。 当一条语句完成的时间超过40秒且不返回ResultSet时(例如\'stmt.executeUpdate(\“ SELECT * INTO BAR FROM FOO \”)\'),该程序将终止连接重置:
Exception in thread \"main\" com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1352)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1339)
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1654)
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5022)
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:773)
    at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:676)
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575)
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400)
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:179)
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:154)
    at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeUpdate(SQLServerStatement.java:633)
    at TestTimeout.main(TestTimeout.java:42)
如果我的陈述式确实传回ResultSet(例如\'ResultSet res = stmt.executeQuery(\“ SELECT * FROM FOO \”)\'),则连线不会逾时。 当我在Win2003R2上运行相同的语句而不针对SQL2005中的数据库副本返回ResultSet时,该语句完成且未在40秒时重置连接。 我启用了日志记录功能,并比较了以未完成的SQL2008R2语句结尾的SQL2005语句的日志,它们与2008年查询中的连接重置消息一样,都是逐行等效的。看到在12:54:47 PM的那一行:
Jun 6,2011 12:54:07 PM com.microsoft.sqlserver.jdbc.TDSCommand onRequestComplete
FINEST: TDSCommand@7ac2b2f6 (SQLServerStatement:1 executeXXX): request complete
Jun 6,2011 12:54:07 PM com.microsoft.sqlserver.jdbc.TDSCommand startResponse
FINEST: TDSCommand@7ac2b2f6 (SQLServerStatement:1 executeXXX): Reading response...
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.TDSChannel read
FINE: TDSChannel (ConnectionID:1) read failed:Connection reset
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.SQLServerException logException
FINE: *** SQLException:ConnectionID:1 com.microsoft.sqlserver.jdbc.SQLServerException: Connection reset Connection reset
Jun 6,2011 12:54:47 PM com.microsoft.sqlserver.jdbc.SQLServerException logException
FINE: com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1352)com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1339)com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1654)com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694)com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5022)com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(SQLServerStatement.java:773)com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(SQLServerStatement.java:676)com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575)com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400)com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:179)com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:154)com.microsoft.sqlserver.jdbc.SQLServerStatement.executeUpdate(SQLServerStatement.java:633)TestTimeout.main(TestTimeout.java:42)
[...]
这是针对2005数据库的语句中对应的行:
Jun 6,2011 2:02:20 PM com.microsoft.sqlserver.jdbc.TDSCommand onRequestComplete
FINEST: TDSCommand@4737371 (SQLServerStatement:1 executeXXX): request complete
Jun 6,2011 2:02:20 PM com.microsoft.sqlserver.jdbc.TDSCommand startResponse
FINEST: TDSCommand@4737371 (SQLServerStatement:1 executeXXX): Reading response...
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSChannel logPacket
FINEST: /XXX.XXX.XXX.XXX:60091 SPID:73 TDSReader@6 (ConnectionID:1) received Packet:1 (13 bytes)
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX   .....I..........
XX XX XX XX XX                                    .....
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSCommand onResponseEOM
FINEST: TDSCommand@4737371 (SQLServerStatement:1 executeXXX): disabling interrupts
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSReader nextPacket
FINEST: TDSReader@6 (ConnectionID:1) Moving to next packet -- unlinking consumed packet
Jun 6,2011 2:02:57 PM com.microsoft.sqlserver.jdbc.TDSParser parse
FINEST: TDSReader@6 (ConnectionID:1): getNextResult: Processing TDS_DONE (0xFD)
[...] 
我使用tcpdump捕获了SQL Server主机和Linux主机之间的所有流量以及所有ICMP流量,并且我注意到,在语句开始执行30秒后,2008和2005服务器都向Linux发送了一个TCP保持活动数据包。 Linux主机使用ACK确认来自2005服务器的保持活动状态,但在连接到2008服务器时,Linux主机不发送ACK,并且2008服务器在重设保持活动状态之前重传9次(每秒一次)。连接(因此需要40秒的时间直到超时)。现在,我注意到Win2003 / SQL2005和Win2008R2 / SQL2008R2主机传输的保持活动数据包之间存在差异:较新的OS使用窗口大小为66560的TCP窗口缩放。所以现在我想知道TCP窗口大小> 65535导致Linux计算机上的iptables或tcp / ip堆栈静默忽略该数据包。但是随后连接中的其他数据包也具有缩放的窗口大小66560,并且Linux服务器会确认它们。日志文件中没有任何内容指示这些数据包被丢弃或引起任何类型的问题。 最后一点:在解决这个问题的过程中,由于更新,我们不得不重启Linux服务器几次,并且两次连接都没有超时一两天。 所以我很困惑,我希望你们中的一个可能对我有所帮助。 更新资料 我发现可以通过在Linux服务器上禁用tcp时间戳来消除连接超时。禁用窗口缩放对这个问题没有影响。追求禁用tcp时间戳的含义对于serverfault.com来说似乎是一个问题,因此我将看到有关在此迁移该问题的信息。 更新2 比较有效的连接(Win2003 / SQL2003)和不可用的连接(Win2008R2 / SQL2008R2)的数据包跟踪,我注意到Win2003连接的keepalive没有选项(即使它在较早的数据包中使用tcp时间戳记也是如此) ),并且断开的连接的keepalive(除非禁用了时间戳)在keepalive中确实具有tcp选项,即时间戳。因此,现在看来,Ubuntu机器对不带tcp选项的keepalive响应,而忽略了带tcp选项的keeplives。这实际上是有关两台主机上的tcp / ip问题的问题。 最终更新 我在Linux网络开发人员列表上提出了这个问题,现在我确信该问题是由于Windows错误导致具有tcp时间戳的tcp keepalive生成错误的校验和(但显然没有其他数据包) )。请参阅netdev列表上的线程。这个问题应该结束。     

解决方法

        事实证明,Win2008发送的带有tcp时间戳记的tcp keepalive带有错误的tcp校验和,这导致Linux主机正确地忽略了它们。这个问题几乎肯定是Windows错误,而不是编程或Linux内核问题。请参阅Linux网络开发人员列表上的该线程。     ,我看到Windows Server 2003和SQL Server与具有可启用TCP / IP卸载功能的网络适配器的计算机上的可伸缩网络包(SNP)有关的类似问题。 此处的信息和解决方案: http://support.microsoft.com/kb/948496     ,        我们目前的雇主也遇到了同样的问题。我们偶然发现,如果Windows 2008 R2服务器的“ Chimney Offload State”设置为“ Enabled”,则同样的断开连接会在40秒后发生。如果该设置设置为“自动”,则可以正常工作。     ,        当发生问题时,我们确实会看到相同的问题,“烟囱卸载状态”设置为“已启用”,但应将其禁用。 我们发现的根本原因是,服务器上应用的语义补丁之一将此标志重置为Enabled。     

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


依赖报错 idea导入项目后依赖报错,解决方案:https://blog.csdn.net/weixin_42420249/article/details/81191861 依赖版本报错:更换其他版本 无法下载依赖可参考:https://blog.csdn.net/weixin_42628809/a
错误1:代码生成器依赖和mybatis依赖冲突 启动项目时报错如下 2021-12-03 13:33:33.927 ERROR 7228 [ main] o.s.b.d.LoggingFailureAnalysisReporter : *************************** APPL
错误1:gradle项目控制台输出为乱码 # 解决方案:https://blog.csdn.net/weixin_43501566/article/details/112482302 # 在gradle-wrapper.properties 添加以下内容 org.gradle.jvmargs=-Df
错误还原:在查询的过程中,传入的workType为0时,该条件不起作用 <select id="xxx"> SELECT di.id, di.name, di.work_type, di.updated... <where> <if test=&qu
报错如下,gcc版本太低 ^ server.c:5346:31: 错误:‘struct redisServer’没有名为‘server_cpulist’的成员 redisSetCpuAffinity(server.server_cpulist); ^ server.c: 在函数‘hasActiveC
解决方案1 1、改项目中.idea/workspace.xml配置文件,增加dynamic.classpath参数 2、搜索PropertiesComponent,添加如下 <property name="dynamic.classpath" value="tru
删除根组件app.vue中的默认代码后报错:Module Error (from ./node_modules/eslint-loader/index.js): 解决方案:关闭ESlint代码检测,在项目根目录创建vue.config.js,在文件中添加 module.exports = { lin
查看spark默认的python版本 [root@master day27]# pyspark /home/software/spark-2.3.4-bin-hadoop2.7/conf/spark-env.sh: line 2: /usr/local/hadoop/bin/hadoop: No s
使用本地python环境可以成功执行 import pandas as pd import matplotlib.pyplot as plt # 设置字体 plt.rcParams['font.sans-serif'] = ['SimHei'] # 能正确显示负号 p
错误1:Request method ‘DELETE‘ not supported 错误还原:controller层有一个接口,访问该接口时报错:Request method ‘DELETE‘ not supported 错误原因:没有接收到前端传入的参数,修改为如下 参考 错误2:cannot r
错误1:启动docker镜像时报错:Error response from daemon: driver failed programming external connectivity on endpoint quirky_allen 解决方法:重启docker -> systemctl r
错误1:private field ‘xxx‘ is never assigned 按Altʾnter快捷键,选择第2项 参考:https://blog.csdn.net/shi_hong_fei_hei/article/details/88814070 错误2:启动时报错,不能找到主启动类 #
报错如下,通过源不能下载,最后警告pip需升级版本 Requirement already satisfied: pip in c:\users\ychen\appdata\local\programs\python\python310\lib\site-packages (22.0.4) Coll
错误1:maven打包报错 错误还原:使用maven打包项目时报错如下 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources (default-resources)
错误1:服务调用时报错 服务消费者模块assess通过openFeign调用服务提供者模块hires 如下为服务提供者模块hires的控制层接口 @RestController @RequestMapping("/hires") public class FeignControl
错误1:运行项目后报如下错误 解决方案 报错2:Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project sb 解决方案:在pom.
参考 错误原因 过滤器或拦截器在生效时,redisTemplate还没有注入 解决方案:在注入容器时就生效 @Component //项目运行时就注入Spring容器 public class RedisBean { @Resource private RedisTemplate<String
使用vite构建项目报错 C:\Users\ychen\work>npm init @vitejs/app @vitejs/create-app is deprecated, use npm init vite instead C:\Users\ychen\AppData\Local\npm-