binarywang/WxJava · error · WxRuntimeException

acquire timeouted

Error message

acquire timeouted

What it means

Thrown by JedisDistributedLock.lock() when lock.acquire(jedis) returns false, meaning the Redis-based JedisLock could not obtain the lock within its acquire timeout. It is a WxRuntimeException signalling contention: another holder kept the lock past the wait window.

Source

Thrown at weixin-java-common/src/main/java/me/chanjar/weixin/common/util/locks/JedisDistributedLock.java:32

 * @deprecated 不建议使用jedis-lock这个过期组件，不可靠
 *
 * @author <a href="https://github.com/007gzs">007</a>
 */
@Deprecated
public class JedisDistributedLock implements Lock {
  private final Pool<Jedis> jedisPool;
  private final JedisLock lock;

  public JedisDistributedLock(Pool<Jedis> jedisPool, String key){
    this.jedisPool = jedisPool;
    this.lock = new JedisLock(key);
  }

  @Override
  public void lock() {
    try (Jedis jedis = jedisPool.getResource()) {
      if (!lock.acquire(jedis)) {
        throw new WxRuntimeException("acquire timeouted");
      }
    } catch (InterruptedException e) {
      throw new WxRuntimeException("lock failed", e);
    }
  }

  @Override
  public void lockInterruptibly() throws InterruptedException {
    try (Jedis jedis = jedisPool.getResource()) {
      if (!lock.acquire(jedis)) {
        throw new WxRuntimeException("acquire timeouted");
      }
    }
  }

  @Override
  public boolean tryLock() {
    try (Jedis jedis = jedisPool.getResource()) {

View on GitHub (pinned to 1c43293a3c)

Solutions

1. Tune the JedisLock acquire timeout/lease to match expected hold time.
2. Ensure holders always release in a finally block and keep critical sections short.
3. Scale the Redis pool and check Redis latency/health.
4. Consider a non-blocking tryLock() path with a fallback instead of blocking lock().

Example fix

// before
distributedLock.lock();
// after
if (!distributedLock.tryLock(waitMs, TimeUnit.MILLISECONDS)) {
  throw new ServiceBusyException("try again later");
}

null

null

try {
  distributedLock.lock();
} catch (WxRuntimeException e) {
  if ("acquire timeouted".equals(e.getMessage())) {
    // contention - back off or fail fast
  }
  throw e;
}

When it happens

Trigger: Multiple JVMs/threads contending on the same lock key while the holder exceeds the acquire timeout; Redis heavily loaded so acquire retried out; lock key never released due to a crash and the lease did not expire yet.

Common situations: Cross-node token refresh serialized on a shared lock with too-short acquire timeout; a previous holder died without releasing and the lease TTL is long; Redis cluster failover mid-acquire.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• lock failed
• unsupported method
• Parameter 'leaseMilliseconds' must grate then 0: {}
• 线程 [{}] 获取会话存档SDK失败，请检查是否已调用 closeAllSdks()

AI-assisted analysis of binarywang/WxJava@1c43293a3c (2026-08-14). Data as JSON: /api/errors/d949e808c3b44268. Report an issue: GitHub.