[ https://issues.apache.org/jira/browse/GEODE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399873#comment-17399873 ]
ASF subversion and git services commented on GEODE-9365: -------------------------------------------------------- Commit 53941d0e3e9091680bd9f24c20c9e53a9e66a1df in geode-native's branch refs/heads/develop from Matthew Reddington [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=53941d0 ] GEODE-9356: Adding NetCore and testing to the CI. (#839) * GEODE-9365: Building netcore as part of ALL. * GEODE-9356: Added missing newline. * GEODE-9356: Finding the dotnet program and added a compile option. * GEODE-9356: Adding .Net 5 to Windows builds. * GEODE-9356: Changed .Net SDK to 3.1, installing NetCore dll. * GEODE-9356: Code review changes. * GEODE-9356: Installing .Net toolchain to Linux platforms. * GEODE-9356: Changed a variable name. * GEODE-9356: Moved .NET install to its own script. * GEODE-9356: Added netcore unit tests. * GEODE-9356: Added missing endif. * GEODE-9356: Shooting in the dark because... YAML... * GEODE-9356: .Net tasks can fail the pipeline. * GEODE-9356: Code review changes. > HARegionQueue over throttles when multiple threads attempt concurrent adds > -------------------------------------------------------------------------- > > Key: GEODE-9365 > URL: https://issues.apache.org/jira/browse/GEODE-9365 > Project: Geode > Issue Type: Bug > Components: client queues > Reporter: Darrel Schneider > Assignee: Mark Hanson > Priority: Major > Labels: GeodeOperationAPI > > HARegionQueue.checkQueueSizeConstraint has some code that implements a > "throttle" on adds to a queue that is full. It is supposed to wait > "eventEnqueueWaitTime" before doing an add. But because this code does two > syncs (putGuard and permitMon) and only waits on one of them, it holds the > other sync for the duration of this threads throttle. Any other concurrent > thread trying to add to the queue gets stuck on the putGuard sync that is > held by the first thread that is doing the timed wait. So it ends up waiting > "eventEnqueueWaitTime" to acquire the first sync and then ends up waiting > again "eventEnqueueWaitTime" when it does its own timed wait. If you have 10 > concurrent threads trying to add one of them will end up waiting 10 * > "eventEnqueueWaitTime". > A couple ideas of how to fix this. Get rid of the putGuard and just use > permitMon. Then as soon as the first thread goes into its timed wait another > thread is allowed to sync on permitMon. But if this is done then we need to > think carefully about the code inside this sync block since it can not be > executed while one or more other threads are waiting in permitMon. > The other solution would be to compute the elapsed time it took to get into > the first sync and subtract that from the time we wait on permitMon. This > seems like a simple solution but does introduce at least one call of get time > (the second call is only needed if the queue is full). -- This message was sent by Atlassian Jira (v8.3.4#803005)