Hello All,
We have been recently developing our Framework for a newly started project and have faced an issue while using global cache and concurrent threads.
Following this insightful community post by Amar Shah: https://community.ibm.com/community/user/integration/blogs/amar-shah1/2021/09/07/how-to-refactor-global-cache-topology-app-connect, we managed to set up our containerized environment to connect to the global cache an on-premise integration node that hosts the global cache catalogs and containers.
Furthermore, considering that the limitation on the additional instances (concurrent threads) for a message flow is 256, we wanted to set up our flows for the maximum amount of throughput so we set this property to the max value for our flows deployed on CP4I; this is where the issue appeared. We set up a simple message flow to increment a counter on the on premise global cache, but the introduction of concurrent threads started to show read-write issues and conflicts as threads were reading the global cache value of previous threads before they were incremented, causing inconsistent incrementing and behavior of the global cache (Readers writers problem).
We tried solving this in 2 ways, but both introduced different bottlenecks which highly affected performance (which is a major concern and requirement for our project):
1) 1 replica for the CP4I integration server, 256 additional instances with a "synchronized (LOCK)" code block in a java compute node in order to ensure sequential execution of the code and prevent the readers writers problem when incrementing.
2) Multiple replicas for CP4I integration server with 256 additional instances each. For this approach, to ensure sequential execution of the incrementing counter, we set up another separate message flow that handles the incrementing global cache logic with no additional instances using a Queue Manager to pass the message to and back from the flow - this ensures that the global cache incrementing is executed one at a time which avoids the readers writers issue.
Is there another approach that we could take to prevent these performance bottlenecks? Is there another way to avoid the readers writers problem when reading and writing to global cache? As Global Cache will be a big part of our implementation for different use cases.
Thank you,
Ahmed Moussa