[
https://issues.apache.org/jira/browse/GEODE-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302770#comment-16302770
]
ASF GitHub Bot commented on GEODE-4098:
---------------------------------------
igorbarc commented on a change in pull request #169: GEODE-4098, add mutex
timeout
URL: https://github.com/apache/geode-native/pull/169#discussion_r158596746
##########
File path: cppcache/src/ClientMetadataService.cpp
##########
@@ -143,7 +143,12 @@ void ClientMetadataService::getClientPRMetadata(const
char* regionFullPath) {
reply.getFpaSet());
if (m_bucketWaitTimeout > std::chrono::milliseconds::zero() &&
reply.getNumBuckets() > 0) {
- WriteGuard guard(m_PRbucketStatusLock);
+ std::unique_lock<std::timed_mutex> guard(m_timedBucketStatusLock,
+ std::chrono::seconds(60));
Review comment:
Other uses come in the context of read/white requests , that has their own
timeout, beyond which as I understand the is no point to continue waiting
for bucket. I think now, maybe it is better I will use read/write timeout
constants here as basis for mutex timeout , instead of defining new one?
Here specifically though, the flow is stopping the service for the pool,
so I think the timeout can be higher , that is why defined 1 minute
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Mutex guarding buckets statuses container has no timeout hanldling
> ------------------------------------------------------------------
>
> Key: GEODE-4098
> URL: https://issues.apache.org/jira/browse/GEODE-4098
> Project: Geode
> Issue Type: Bug
> Components: native client
> Reporter: Igor Barchak
> Fix For: 1.2.0
>
>
> Mutex guarding buckets statuses container has no timeout handling,in
> ClientMetadataService.cpp
> Can cause messages stuck on client
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
