如何修复WSO2-AM 2.2.0切换数据库后的TDS RPC协议流错误？

我来帮你梳理这个问题——你遇到的TDS RPC协议错误，核心原因是WSO2 Metrics模块向SQL Server写入Timer指标时，某个float类型的参数不符合SQL Server的字段要求。虽然系统没崩溃，但频繁报错会干扰日志可读性，还可能存在指标数据丢失的潜在风险，下面是具体的排查和解决步骤：

1. 检查Metrics相关数据库表的字段定义 #

WSO2 Metrics会创建一系列以METRIC_开头的表（比如METRIC_TIMERS、METRIC_TIMER_VALUES），你需要定位到Timer指标对应的表，重点检查其中的数值型字段：

• 确认字段类型是否为SQL Server的FLOAT，如果是，建议尝试将其改为DECIMAL(18,9)这类精确数值类型，避免近似数值带来的转换兼容问题。
• 核对字段的精度和scale设置，确保Java传递的数值不会超出该范围（比如低精度的FLOAT可能无法容纳Java侧的高精度数值）。

2. 升级SQL Server JDBC驱动版本 #

你当前使用的SQL Server JDBC驱动可能存在旧版本的类型转换bug，建议：

• 下载适配SQL Server版本的最新mssql-jdbc驱动（推荐8.x及以上版本，适配SQL Server 2012+）。
• 替换<WSO2_AM_HOME>/repository/components/lib目录下的旧驱动文件，然后重启WSO2 AM服务。

3. 调整Metrics的JDBC上报配置 #

在<WSO2_AM_HOME>/repository/conf/metrics/metrics.properties文件中，找到JDBC Reporter相关配置进行调整：

• 尝试减小metrics.jdbc.reporter.timer.batch.size参数值，降低批量插入的单次数据量，避免一次性传递过多数值导致的转换错误。
• 检查是否有数值类型格式化相关的配置项，强制将Timer的数值转换为符合SQL Server要求的精度格式。

4. 临时方案：禁用不必要的Timer指标（可选） #

如果暂时无法彻底解决，可以先关闭部分非核心的Timer指标上报：

• 在metrics.properties中找到对应Timer的配置项，将其设置为false，或者调整metrics.jdbc.reporter.enabled关闭特定模块的上报，但这只是权宜之计，建议优先解决类型兼容问题。

附：完整错误日志 #

[2018-05-20 07:50:24,935] ERROR - JDBCReporter Error when reporting timers com.microsoft.sqlserver.jdbc.SQLServerException: The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Parameter 6 (""): The supplied value is not a valid instance of data type float. Check the source data for invalid values. An example of an invalid value is data of numeric type with scale greater than precision. 
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:259) 
at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(SQLServerStatement.java:1547) 
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.doExecutePreparedStatementBatch(SQLServerPreparedStatement.java:2678) 
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement$PrepStmtBatchExecCmd.doExecute(SQLServerPreparedStatement.java:2547) 
at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:7347) 
at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:2713) 
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(SQLServerStatement.java:224) 
at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(SQLServerStatement.java:204) 
at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeBatch(SQLServerPreparedStatement.java:2460) 
at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:498) 
at org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy.invoke(StatementFacade.java:114) 
at com.sun.proxy.$Proxy19.executeBatch(Unknown Source) 
at org.wso2.carbon.metrics.jdbc.reporter.JDBCReporter.reportTimers(JDBCReporter.java:389) 
at org.wso2.carbon.metrics.jdbc.reporter.JDBCReporter.report(JDBCReporter.java:200) 
at com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:162) 
at com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:117) 
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) 
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)

内容的提问来源于stack exchange，提问作者N.Abdolalizadeh