Had a user that ran into this on one of our clusters that upgraded to 2.8. They were running a pre-2.8 version of the S3AFileSystem code with their job and it failed like this:
The problem is that core-default in 2.8 removed fs.s3a.threads.core but changed the existing fs.s3a.threads.max to 10. The old pre-2.8 S3AFileSystem code had code defaults of 15 and 256, respectively. So when a 2.8 job client (in this case an Oozie server) submits the job, picking up the 2.8 core-default settings for fs.s3a.threads.max for job.xml but the job itself runs with the older S3AFileSystem code the job fails because it tries to initialize a threadpool with core threads=15 and max threads=10.
Not sure if this is considered simply an invalid setup, but I suspect this won't be the first case of someone submitting a job with a 2.8 or later client (e.g.: via an Oozie server upgraded independently of a user's job code) and failing because the user hasn't upgraded to the 2.8 or later S3AFileSystem code yet.
If we had added a deprecated core-default value for fs.s3a.threads.core then the older code would have gotten consistent values for core and max threads. As it is now, it gets half of the new default settings, and those aren't compatible with the older, other half of the defaults. Thoughts on whether this is worth doing in a followup JIRA?