[ 
https://issues.apache.org/jira/browse/ARROW-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834687#comment-16834687
 ] 

Liya Fan commented on ARROW-5264:
---------------------------------

I agree with you that #1 and #2 solve most cases. However, there are some 
unfortunate rare cases which can be resolved by neither #1 nor #2. 

For example, when writing “plugin of plugin“, #1 and #2 are infeasible. 

To be specific, let me illustrate by an example of running a Flink job.
1. First, we need to start yarn daemons. We do not have access to the JVM 
command line of the daemons, because they are started by the cluster 
administrator, and are long-running.
2. Second, we need to start a Flink session. In particular, we need to start 
job managers and task managers, which will load Arrow classes in the memory 
manager. Similarly, we do not have access to the command line, nor can we 
insert initialization code, because we are not the owner of these components.
3. We submit our job to the session, and we want to disable bound checking in 
the operators. But it is too late since the flag has been set then starting the 
session.

So can we setup a environmental variable for this? The priority of the 
environmental variable will be lower than the system property. This will make 
the process much easier, and will cover the remaining rare cases.

> [Java] Allow enabling/disabling boundary checking dynamically in the code
> -------------------------------------------------------------------------
>
>                 Key: ARROW-5264
>                 URL: https://issues.apache.org/jira/browse/ARROW-5264
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: Java
>            Reporter: Liya Fan
>            Assignee: Liya Fan
>            Priority: Minor
>              Labels: pull-request-available
>         Attachments: screenshot-1.png
>
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The flag BoundsChecking#BOUNDS_CHECKING_ENABLED determines if boundary 
> checking is enabled/disabled in vector/arrow buffer APIs. 
> It has significant performance implications, since boundary checking is a 
> frequent operation.
> This issue address 2 problems with the flag for boundary checking in Java API:
> 1. This flag is final and initialized in a static block. That means, the only 
> reliable way to override it is in the JVM command line, by providing some 
> system properties. However, for some scenarios, it is difficult or even 
> impossible to get access to the JVM command line. Therefore, it is desirable 
> to provide a way to override it dynamically in the program code. 
> 2. There is an old and a new system property for this flag. To disable 
> boundary checking, both the old and new properties must be set to true, which 
> is undesirable:
>  !screenshot-1.png! 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to