RedisGraph传timeout参数查询抛出JRedisGraphCompileTimeException异常

传入long类型timeout参数调用query方法抛出参数数量错误，核心原因是当前部署的RedisGraph 2.5.1版本服务端，原生不支持GRAPH.QUERY命令携带timeout参数：

1. GRAPH.QUERY的timeout参数是RedisGraph 2.8.0版本才正式上线的特性，2.5.x版本的服务端定义的GRAPH.QUERY命令仅接受图名、Cypher语句、可选查询参数三类入参，收到额外传入的timeout值时，会直接判定参数数量不符合命令规范，抛出ERR wrong number of arguments for 'graph.QUERY' command错误。
2. JRedisGraph客户端提供的三参数（图名、Cypher语句、timeout）query重载方法，是为适配高版本RedisGraph做的接口封装，客户端本身不会校验连接的服务端版本是否支持该参数，因此低版本服务端调用时会直接触发服务端报错。不带timeout的两参数query方法完全匹配2.5.1版本的命令格式，所以可以正常运行。

触发异常的调用代码如下：

public ResultSet query(String query) {
   //return graph.query(graphName, query);
   return graph.query(graphName, query,60000L);
}

抛出的完整异常信息：

com.redislabs.redisgraph.exceptions.JRedisGraphCompileTimeException: redis.clients.jedis.exceptions.JedisDataException: ERR wrong number of arguments for 'graph.QUERY' command

根据实际运维场景选择对应方案即可：

• 方案一：升级RedisGraph服务端到2.8及以上稳定版本，升级完成后不需要修改现有业务代码，传入timeout参数的调用逻辑可以直接正常运行。
• 方案二：如果暂时无法升级服务端，移除query调用时传入的60000L超时参数，改回两参数的query调用。如果需要实现查询超时控制，不要通过GRAPH.QUERY命令传参实现，可以用两种客户端侧方案替代：
  • 配置Jedis连接的socketTimeout参数，从TCP连接层面控制单个请求的最大阻塞时长；
  • 在业务层通过异步线程池、熔断组件做查询超时截断，避免长查询长时间占用服务端资源。

注意：如果服务端长期固定使用2.5.x版本，建议同时将JRedisGraph客户端版本调整为适配2.5.x系列的对应发行版，避免误调用高版本专属接口触发同类参数错误。

内容的提问来源于stack exchange，提问作者Atharv Thakur