...yes, as long as you always configure instance before use...
Most of the ObjectMapper API is thread-safe after initialization. That means that if we want to call methods like ObjectMapper#enable and ObjectMapper#disable to control how the serialization/deserialization works, then we'd need to do it during some single-threaded initialization phase, such as process startup. After that, multiple threads may call the serialization/deserialization methods concurrently. I've used Jackson successfully this way in other multi-threaded codebases.
I'm thinking the method is not reentrant. ObjectMapper uses thread local buffer for parsers and generators to achieve thread-safety.
I'm curious why the question was brought up as re-entrancy instead of thread-safety. If we have a re-entrant call pattern, where the same thread ends up with more than one stack frame inside the serialization/deserialization methods, then the later call would stomp on the earlier call's usage of thread-local storage. AFAIK, we don't have a re-entrant call pattern in WebHDFS though, and we just need to worry about thread-safety. Am I missing something?
In addition to the changes in the current patch, I also see one more new ObjectMapper() call inside WebHdfsFileSystem. We probably need a comprehensive review across the whole codebase to look for this pattern, but we can keep the current JIRA's scope focused on WebHDFS, since we know it is causing a performance problem there.