No more than 30,000 operation can't be performed in one transaction

Thre is a problem in Protocol class. When a transaction is executed (in Protoco.send) locks on concurrentOpt are aquired. The issue is when the number of operations in transaction + 1 is greater than the MaxConcurrentRequestsOpt that is defaulted to 30,000 the operation hangs forever, since that’s the way the semaphore.acquire(count) works. Of course the limit might be adjusted, but when the limit is reached, Protocol will freeze the whole execution.

Solution would be to perform check if the number of requested concurrent operations reached the limit value.

Besides that I wonder why every single operation in transaction is treated as concurrent operation? The transaction is executed in a single thread.

[kpbochenek]

@Zuchos There are 2 issues raised here. I will refer to the first one and try investigate more a second one.

PR #48 should fix mentioned issue. In detail for:

• inTransaction -> returned future will be failed with RedisTansactionBuilderException[IllegalArgumentException]
• withTransaction -> exception will be thrown RedisTansactionBuilderException[IllegalArgumentException]

I will let this PR be open till tomorrow and if you have any concerns about it please comment there, if not I will merge it and release next version.

[Zuchos]

Sorry for not responding so long. Yeah, you are right, it will not block infinitely, but one transaction will block execution of another for a while and there is no control of how long this call will be blocked. Using tryAcquire with timeout would give control over it.

My point was that the name of variable max-concurrent-requests and its purpose are different. AFAIU all commands in transaction are executed in one Future so there is no concurrency between them. Transaction will take longer than single request and take more memory to store the list of commands and their responses, but it has nothing to do with concurrency access to the resource (redis). So here single concurrent command is treated the same way as a command in the batch the transaction.

Maybe it’s all cause by the ambiguity of the naming convention (transaction, has number of requests, which are not real requests, rather commands in one batch request).