[
https://issues.apache.org/jira/browse/MAPREDUCE-5855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miklavcic updated MAPREDUCE-5855:
-----------------------------------------
Attachment: oozie-error.tar.gz
yarn-stacktrace.txt
The key is xalan and xerces have use the ServiceLoader feature. Deploying a
simple Oozie workflow with a lib dir containing those 2 jars will cause the
stacktrace in the attachment.
> Oozie jobs able to affect container classpath
> ---------------------------------------------
>
> Key: MAPREDUCE-5855
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5855
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: applicationmaster, job submission, mr-am, mrv2
> Affects Versions: 2.2.0
> Environment: Centos 6.4
> Reporter: Michael Miklavcic
> Attachments: oozie-error.tar.gz, yarn-stacktrace.txt
>
>
> 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?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
