You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2019/04/30 21:58:00 UTC
[jira] [Updated] (GEODE-6657) BridgeServer.MAX_INCOMING_DATA and
BridgeServer.MAX_INCOMING_MSGS do not work correctly together
[ https://issues.apache.org/jira/browse/GEODE-6657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Darrel Schneider updated GEODE-6657:
------------------------------------
Description:
If you set both the following system properties: BridgeServer.MAX_INCOMING_DATA and BridgeServer.MAX_INCOMING_MSGS you will not get correct behavior.
What will happen is that every incoming message will be counted twice (instead of the correct once) and the data limit will not be ignored.
The bug is in: org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(int)
in the code that handles a non-null dataLimiter. If timeToWait is not zero then this code should be acquiring the dataLimiter semaphore. But instead if acquires again the messageLimiter semaphore.
Note: we have another issue that mentions that neither of these system properties have any tests.
It also looks like MAX_INCOMING_DATA's implementation is broken even if MAX_INCOMING_MSGS is not set. In that case (if timeToWait is non-zero) no limit is enforced at all. I think the common case is that timeToWait is non-zero.
It looks like MAX_INCOMING_DATA is so broken that it could just be removed. It is possible that MAX_INCOMING_MSGS is being used by itself and its implementation is correct so someone may be using it.
Both these system properties are documented in:
geode-core/src/main/java/org/apache/geode/internal/cache/properties.html
but that is an internal file. I did not see them mentioned at all (except for source code) when I did a google search.
was:
Is you set both the following system properties: BridgeServer.MAX_INCOMING_DATA and BridgeServer.MAX_INCOMING_MSGS you will not get correct behavior.
What will happen is that every incoming message will be counted twice (instead of the correct once) and the data limit will not be ignored.
The bug is in: org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(int)
in the code that handles a non-null dataLimiter. If timeToWait is not zero then this code should be acquiring the dataLimiter semaphore. But instead if acquires again the messageLimiter semaphore.
Note: we have another issue that mentions that neither of these system properties have any tests.
It also looks like MAX_INCOMING_DATA's implementation is broken even if MAX_INCOMING_MSGS is not set. In that case (if timeToWait is non-zero) no limit is enforced at all. I think the common case is that timeToWait is non-zero.
It looks like MAX_INCOMING_DATA is so broken that it could just be removed. It is possible that MAX_INCOMING_MSGS is being used by itself and its implementation is correct so someone may be using it.
Both these system properties are documented in:
geode-core/src/main/java/org/apache/geode/internal/cache/properties.html
but that is an internal file. I did not see them mentioned at all (except for source code) when I did a google search.
> BridgeServer.MAX_INCOMING_DATA and BridgeServer.MAX_INCOMING_MSGS do not work correctly together
> ------------------------------------------------------------------------------------------------
>
> Key: GEODE-6657
> URL: https://issues.apache.org/jira/browse/GEODE-6657
> Project: Geode
> Issue Type: Bug
> Components: client/server
> Reporter: Darrel Schneider
> Priority: Major
>
> If you set both the following system properties: BridgeServer.MAX_INCOMING_DATA and BridgeServer.MAX_INCOMING_MSGS you will not get correct behavior.
> What will happen is that every incoming message will be counted twice (instead of the correct once) and the data limit will not be ignored.
> The bug is in: org.apache.geode.internal.cache.tier.sockets.Message.readHeaderAndBody(int)
> in the code that handles a non-null dataLimiter. If timeToWait is not zero then this code should be acquiring the dataLimiter semaphore. But instead if acquires again the messageLimiter semaphore.
> Note: we have another issue that mentions that neither of these system properties have any tests.
> It also looks like MAX_INCOMING_DATA's implementation is broken even if MAX_INCOMING_MSGS is not set. In that case (if timeToWait is non-zero) no limit is enforced at all. I think the common case is that timeToWait is non-zero.
> It looks like MAX_INCOMING_DATA is so broken that it could just be removed. It is possible that MAX_INCOMING_MSGS is being used by itself and its implementation is correct so someone may be using it.
> Both these system properties are documented in:
> geode-core/src/main/java/org/apache/geode/internal/cache/properties.html
> but that is an internal file. I did not see them mentioned at all (except for source code) when I did a google search.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)