Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.2.0
-
None
-
None
-
Centos 6.4
Description
A submitted job is able to affect the container classpath and cause failures at the container level.
The jar spec allows a user to specify a service provider via the Service Loader interface for things like XML implementations. These implementations can be provided by including files in META-INF/services that have a line declaring which implementation should be loaded by the JVM.
I've attached a contrived example that mimics what I witnessed at a client site. They had xalan and xerces jars in an Oozie lib directory as dependencies for a Pig workflow. The stacktrace is also attached.
There is a work-around for this problem - either include all necessary jars, e.g. serializer.jar, in your Oozie workflow lib, or rely on default xml providers. But, is this expected behavior from yarn/map-reduce?