[
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)
