sql-server – Sql Server JDBC连接重置错误:仅限于Amazon EC2

前端之家收集整理的这篇文章主要介绍了sql-server – Sql Server JDBC连接重置错误:仅限于Amazon EC2前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
背景:云

我们有一个基于java的Web应用程序,我们通常在我们自己的服务器上托管.最近我们使用Amazon Web Services(AWS EC2)云来托管一个实例.

这个“云设置”与我们典型的“现场”设置相匹配:应用服务器的一个服务器,数据库服务器的另一个服务器. (几个应用服务器指向同一个数据库服务器)

问题
在这个云设置中,我们在数据库和jdbc驱动程序之间接收到间歇性的“通过对等错误的连接重置”,其中(看似)随机间隔和代码库中的随机点,数据库连接失败.

以下是日志的几个错误摘录

堆栈跟踪示例1:

at com.participate.pe.genericdisplay.client.taglib.GenDisplayViewTag.doStartTag(GenDisplayViewTag.java:77)
    ... 75 more
Caused by: com.microsoft.sqlserver.jdbc.sqlServerException: The connection is closed.
    at com.microsoft.sqlserver.jdbc.sqlServerException.makeFromDriverError(sqlServerException.java:170)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.checkClosed(sqlServerConnection.java:304)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.getMetaData(sqlServerConnection.java:1734)
    at org.jboss.resource.adapter.jdbc.WrappedConnection.getMetaData(WrappedConnection.java:354)

堆栈跟踪示例2

at java.lang.Thread.run(Thread.java:619)
Caused by: com.microsoft.sqlserver.jdbc.sqlServerException: Connection reset
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1368)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.terminate(sqlServerConnection.java:1355)
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1532)
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3274)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4437)
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4389)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection$1ConnectionCommand.doExecute(sqlServerConnection.java:1457)
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4026)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.executeCommand(sqlServerConnection.java:1416)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.connectionCommand(sqlServerConnection.java:1462)
    at com.microsoft.sqlserver.jdbc.sqlServerConnection.setAutoCommit(sqlServerConnection.java:1610)
    at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:429)

技术环境

> Jboss 4.2.2.GA(Jboss-Web 2.0 / Tomcat 6)
> MSsql 2005 2.0 jdbc驱动

一些点

>我们从来没有见过这个问题
我们自己的环境(即自己的数据中心)运行应用程序已有好几年了
>这导致我得出结论:“有趣的事情正在与亚马逊网络环境发生”.我可能是错的/缺少某事/等等.
>这个问题只发生在我们的应用程序.我们还有其他没有这个问题的java和PHP应用程序.其他java应用程序使用不同的jdbc驱动程序(jtds,afaik)
>它似乎不是一个简单的连接超时

问题

以前有人看过这个吗?
– 如果它是EC2“已知问题”,我们可以配置我们的方法解决问题(即确保一切都在自己的子网或虚拟私有云(vpc)上?
– 任何jdbc驱动程序设置来解决这个问题?

**更新**
我在这个问题上扩大和增加了赏金.

关于额外的信息:两个虚拟服务器(数据库和应用程序服务器)在不同的子网上,即两台服务器之间一跳.

在非云环境中,我们在两台服务器上都有“零跳”.

我们的托管管理员表示,我们无法控制EC2实例的子网.这让我想知道虚拟私有云是否会有所帮助.

提前致谢

解决方法

只需谨慎使用DBCP /连接池功能来减轻问题 – 启用“testOnBorrow”和其他功能的可用性越多,引入系统延迟或其他性能变化的影响越多.我不知道DBCP是否仍然执行此操作,但几年以前,它将生成实际的测试查询来测试连接 – 完整的堆栈,数据库响应 – 而不仅仅是在网络层.来自Brian的上述链接带来了二十世纪早期关于JDBC连接管理的周边重试逻辑的可怕回忆.

无论如何,真正根本原因是困难的,除了收集证据,并将“看似随机的”消除到一组具体的条件:

>你可以尝试抛出一个Wireshark / PCAP跟踪,找到它发生的时间,并将结果发送给亚马逊和微软看看是否可以根本原因
>您可以尝试使用某些测试工具来解决问题(JMeter测试以获得并发性),反弹网络连接,监视恢复等
>您可以尝试sql Server的替代版本来折扣已经被修复的sql Server / JDBC驱动程序错误.
>如果在连接字符串中使用DNS,可以使用IP地址验证nslookup问题

我不是sql Server专家,但研究的另一个途径可能在相关产品领域内 – 例如看看有没有人遇到与TFS / Sharepoint类似的问题(例如http://nickhoggard.wordpress.com/2009/12/07/further-experiences-with-tfs-2010-beta-2-on-amazon-ec2/)

原文链接:https://www.f2er.com/mssql/81186.html

猜你在找的MsSQL相关文章