-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Closed
Description
main/src/main/java/org/springframework/data/redis/connection/jedis/JedisHashCommands.java
public Cursor<Entry<byte[], byte[]>> hScan(byte[] key, long cursorId, ScanOptions options) {
Assert.notNull(key, "Key must not be null");
return new KeyBoundCursor<Entry<byte[], byte[]>>(key, cursorId, options) {
@Override
protected ScanIteration<Entry<byte[], byte[]>> doScan(byte[] key, long cursorId, ScanOptions options) {
if (isQueueing() || isPipelined()) {
throw new InvalidDataAccessApiUsageException("'HSCAN' cannot be called in pipeline / transaction mode");
}
ScanParams params = JedisConverters.toScanParams(options);
ScanResult<Entry<byte[], byte[]>> result = connection.getJedis().hscan(key, JedisConverters.toBytes(cursorId),
params);
return new ScanIteration<>(Long.valueOf(result.getCursor()), result.getResult());
}
@Override
protected void doClose() {
JedisHashCommands.this.connection.close();
};
}.open();
}
When an exception occurs in doScan, the returned cursor is null, so the connection cannot be closed through the cursor, resulting in a leak of the jedis connection pool.
Therefore, when an exception occurs in doScan, the connection should be closed
All operations involving cursors have the same problem
Metadata
Metadata
Assignees
Labels
type: bugA general bugA general bug
