[ 
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Blum updated GEODE-10035:
------------------------------
    Description: 
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static) 
constant field 
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
 which is derived from either the "{{p2p.nodirectBuffers"}} OR the 
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional 
logic is incorrect!

It should read (formatted to make it more readable):

{code:java}
  public static final boolean useDirectBuffers = !(
      Boolean.getBoolean("p2p.nodirectBuffers")
      || 
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
  );
{code}

Alternatively:

{code:java}
  public static final boolean useDirectBuffers = 
!Boolean.getBoolean("p2p.nodirectBuffers")
      && 
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}

That is, if either the "{{p2p.nodirectBuffers}}" OR the 
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO 
NOT USE direct ByteBuffers.

The term "{{useHeapBuffers}}" implies that the buffer should be created on the 
JVM Heap, and not in main memory as a "direct" ByteBuffer.

Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to 
"{{true}}" would result in a direct ByteBuffer allocation as can be seen 
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
 
rather than what should happen 
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].

As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System 
property is not set at all (which results in {{Boolean.getBoolean(..)}} 
returning {{false}}), which negated results in the OR'd condition not even 
being evaluated!



  was:
In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member (static) 
constant field 
([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
 which is derived from either the "{{p2p.nodirectBuffers"}} OR the 
"{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional 
logic is incorrect!

It should read (formatted to make it more readable):

{code:java}
  public static final boolean useDirectBuffers = !(
      Boolean.getBoolean("p2p.nodirectBuffers")
      || 
Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
  );
{code}

Alternatively:

{code:java}
  public static final boolean useDirectBuffers = 
!Boolean.getBoolean("p2p.nodirectBuffers")
      && 
!Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
{code}

That is, if either the "{{p2p.nodirectBuffers}}" OR the 
"{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then DO 
NOT USE direct ByteBuffers.

The term "{{useHeapBuffers}}" implies that the buffer should be created on the 
JVM Heap, and not in main memory as a "direct" ByteBuffer.

Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to 
"{{true}}" would result in a direct ByteBuffer allocation as can be seen 
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
 
rather than what should happen 
[here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].




> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -------------------------------------------------------------------------
>
>                 Key: GEODE-10035
>                 URL: https://issues.apache.org/jira/browse/GEODE-10035
>             Project: Geode
>          Issue Type: Improvement
>    Affects Versions: 1.14.3
>            Reporter: John Blum
>            Priority: Major
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member 
> (static) constant field 
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
>  which is derived from either the "{{p2p.nodirectBuffers"}} OR the 
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional 
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
>   public static final boolean useDirectBuffers = !(
>       Boolean.getBoolean("p2p.nodirectBuffers")
>       || 
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
>   );
> {code}
> Alternatively:
> {code:java}
>   public static final boolean useDirectBuffers = 
> !Boolean.getBoolean("p2p.nodirectBuffers")
>       && 
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the 
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then 
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on 
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to 
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen 
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>  
> rather than what should happen 
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System 
> property is not set at all (which results in {{Boolean.getBoolean(..)}} 
> returning {{false}}), which negated results in the OR'd condition not even 
> being evaluated!



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to