User running into VFS-683 with Commons VFS 2.3

[dlmarion]

Describe the bug
The commons-vfs dependency was bumped from 2.1 to 2.3 as part of #1295. User is reporting running into issue VFS-683 with this updated commons-vfs dependency and rolling back the deployed commons-vfs jar to 2.1 resolves the issue.

Versions (OS, Maven, Java, and others, as appropriate):
rel/1.10.0
rel/1.10.1
rel/1.10.2
rel/2.0.0
rel/2.0.1

The version of commons-vfs in main is 2.9.0, not sure if that version presents the same issue. Based on the comments in VFS-683, my guess is that it does still have the issue.

[milleruntime]

So can we do a 1.10.3 release with the good commons-vfs 2.1 jar? This bug seems nasty enough that we don't want users to have to rebuild Accumulo on their own.

[ctubbsii]

We don't need to do a release for this. It's just a drop-in replacement on their class path. No need to rebuild Accumulo at all. I'd wait for a resolution upstream, bump to that version, then just include it in the next release. In the meantime, can update the release notes for the current version to add a "Known issues" section and link them to the VFS issue for a workaround/solution that works for them.

[dlmarion]

The AccumuloVFSClassLoader class in 1.10 has not substantively changed since 2014 according to the git log. My guess is that AccumuloVFSClassLoader is susceptible to the issue in VFS-683, but more recent versions of commons-vfs have increased the probability of it occurring.

[dlmarion]

I'm thinking we should move the commons-vfs version back to 2.1 in main and https://github.com/apache/accumulo-classloaders. We can move the version back to 2.1 for any future 1.x and 2.0.x releases. Thoughts?

[ctubbsii]

I'm thinking we should move the commons-vfs version back to 2.1 in main and https://github.com/apache/accumulo-classloaders. We can move the version back to 2.1 for any future 1.x and 2.0.x releases. Thoughts?

2.1 isn't bug free... every version of VFS has had some kind of seriously annoying bug. I think us chasing the right version of VFS to have on the class path is a lost cause. Why not just wait for upstream to patch and release a fixed version we can bump to? If users want a specific VFS version to avoid specific bugs and to tolerate other specific bugs in VFS, they can take some responsibility to manage their own class path to get their preferred bugset.

[dlmarion]

Closing based on the discussion. @ctubbsii made a suggestion in another discussion as a way to keep jars in HDFS and not use the VFS classloader. His suggestion was to create a script that copies the jars from HDFS to lib/ext before starting the Accumulo processes. You might be able to use the same script to update the jars on the local filesystem when an updated jar is pushed into HDFS.

[milleruntime]

His suggestion was to create a script that copies the jars from HDFS to lib/ext before starting the Accumulo processes. You might be able to use the same script to update the jars on the local filesystem when an updated jar is pushed into HDFS.

We could create a bash script for 1.10.3. We could include it in contrib and mention it in the release notes and readme.

[rverk]

Pls add this to the Known Issues of 10.2. We had to manually downgrade VFS to fix breaking issues with our iterators not properly loading. Having known this up front would have saved us the trouble.

[dlmarion]

@rverk - Thanks for the feedback. I created apache/accumulo-website#344 for this.

[dlmarion]

@ivakegg submitted a patch for VFS-683 that should be included in the VFS 2.10 release.