Hi Ed, Once you create the PR against the trunk branch, the CI would run the tests. However, this is currently only for Linux. We've recently setup a CI for Windows that runs daily on the trunk branch - https://ci-hadoop.apache.org/view/Hadoop/job/hadoop-qbt-trunk-java8-win10-x86_64/
We're still in the process of setting it up to run for every PR that gets raised (called the precommit CI). In the meantime, could you please ping me or ask any of the committers to run the Windows CI against your private branch once you're ready and prior to merging? I'm requesting the Windows CI to be run for this change since it involves C/C++ related changes. We've done a lot of work to make HDFS native client to be cross platform compatible and want to make sure that there are no issues with this. Thanks, --Gautham On Sun, 2 Jul 2023 at 13:28, Xiaoqiao He <hexiaoq...@apache.org> wrote: > Thanks Ed for your feedback. > I think it is better to comment on JIRA HDFS-13585 directly. And feel free > to > submit PR there if interested and there will be some reviewers coming soon. > Please let me know if you will have any questions. > Thanks again. > > Best Regards, > - He Xiaoqiao > > On Sun, Jul 2, 2023 at 2:07 PM Ed Mancebo <edmanc...@gmail.com> wrote: > > > Hi, > > > > I'm new here. I'm wondering if folks will accept a contribution to fix > > https://issues.apache.org/jira/browse/HDFS-13585 ? > > > > I can repro the issue by creating a Java application that calls > > hdfsConnectNewInstance: > > https://gist.github.com/emancebo/e413b0f53e4005c80cbf410fdb4c9cb9 > > > > The crash occurs in hdfsThreadDestructor. It seems that any of the calls > > on the JNIEnv can cause a crash. I think in this scenario, the JVM > (there > > is only one - the one created for the Java program) is getting cleaned up > > as the application is exiting, hence it is unsafe to call any of the > > methods on JNIEnv in the destructor function. > > > > My idea is to add a check in getGlobalJNIEnv to see if we are already > > attached to a JVM (by calling GetEnv). If we're already attached, we > don't > > need to call AttachCurrentThread, and we can also skip the block of code > in > > hdfsThreadDestructor that calls DetachCurrentThread. We could add a flag > > in ThreadLocalState to indicate whether we need to perform the detach. > > > > Definitely open to other approaches though. Thanks in advance - > > > > Ed > > >
