[jira] [Updated] (YARN-11989) Timeline server logs SEVERE JAXB schema-generation error

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/YARN-11989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ASF GitHub Bot updated YARN-11989:
----------------------------------
    Labels: pull-request-available  (was: )

> Timeline server logs SEVERE JAXB schema-generation error
> --------------------------------------------------------
>
>                 Key: YARN-11989
>                 URL: https://issues.apache.org/jira/browse/YARN-11989
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: timelineserver
>    Affects Versions: 3.5.0
>         Environment: Observed on Hadoop 3.5.0 (rel/release-3.5.0), Jersey 2.46 (as pulled in by
> YARN's Jersey 2 migration), running the Timeline Server v1 (LevelDB storage,
> {{{}yarn.timeline-service.version=1.0f{}}})
>            Reporter: Dieter De Paepe
>            Priority: Minor
>              Labels: pull-request-available
>
> h3. Summary
> Since the Jersey 1 -> Jersey 2 migration landed in the 3.5.0 line, the Timeline
> Server (ATS v1) logs the following at SEVERE level on essentially every timeline
> request:
> {code:java}
> SEVERE org.glassfish.jersey.server.wadl.internal.generators.WadlGeneratorJAXBGrammarGenerator
> - Failed to generate the schema for the JAX-B elements
> {code}
> h3. Root cause
> {{TimelineEntity}} and {{TimelineEntities}} (ATS v1 DAOs, package
> {{{}org.apache.hadoop.yarn.api.records.timeline{}}}) expose {{{}Map{}}}/{{{}Set{}}}-typed
> fields via JAXB-annotated getters, e.g. in TimelineEntity.java:
> {code:java}
> // Required by JAXB
> @XmlElement(name = "relatedentities")
> public HashMap<String, Set<String>> getRelatedEntitiesJAXB() {
>   return relatedEntities;
> }
> {code}
> JAXB cannot generate an XSD for a generic {{{}Map{}}}/{{{}Set{}}} without a custom
> {{{}XmlAdapter{}}}, which these getters do not have. Jersey 2's
> {{WadlGeneratorJAXBGrammarGenerator}} builds a full JAXB-based XSD grammar for
> every registered resource class on each {{OPTIONS}} request, so this failure
> fires - and gets logged at SEVERE - on every OPTIONS request the server
> receives.
> This matters in practice because {{TimelineClient}} always issues one: it goes
> through {{TimelineConnector}} -> {{{}AuthenticatedURL{}}}, and both
> {{PseudoAuthenticator}} and {{KerberosAuthenticator}} send an OPTIONS request
> as their authentication probe before the real request. So every single
> TimelineClient call produces one SEVERE log line.
> h3. Relationship to existing issues
> This is effectively a regression of YARN-2804 (fixed in Hadoop 2.6.0, closed
> 2014), which reported the identical symptom
> ({{{}WadlGeneratorJAXBGrammarGenerator{}}} failing on these same Map-typed
> Timeline classes) under Jersey 1 ({{{}com.sun.jersey.server{}}}). That fix worked
> around the problem in Jersey 1's WADL generator; it does not carry over to
> Jersey 2's separate WADL implementation, so the underlying defect (Map/Set
> fields JAXB cannot describe) resurfaced once the server moved to Jersey 2.
> YARN-9554 and YARN-11877 both address the same underlying incompatibility
> (Map/Set fields incompatible with JAXB) but only for actual request/response
> (de)serialization - YARN-11877 registers dedicated Jackson-based
> {{{}TimelineEntityReader{}}}/{{{}TimelineEntityWriter{}}} providers so runtime JSON
> traffic bypasses JAXB entirely. Neither touches WADL generation, which is a
> separate code path that still attempts to build a JAXB grammar for these
> classes regardless of which provider actually handles the request payload.
> h3. Scope
> Only observed on the Timeline Server, unsure if other services are also affected.
> h3. Suggested fix directions
>  * Disable WADL generation by default for the Timeline Server context (as is
> effectively already necessary for correct operation, given no client reads
> the generated WADL and the JAX-B model cannot describe it), e.g. via
> {{ServerProperties.WADL_FEATURE_DISABLE}} set on the server's own
> {{{}ResourceConfig{}}}.
>  * Alternatively, add \{{XmlAdapter}}s for the Map-typed fields so WADL/JAXB
> schema generation succeeds, mirroring how YARN-9554 addressed the Set
> interface case.
> h3. Workaround
> Passing the following JVM system properties to the Timeline Server disables
> WADL generation entirely:
> {code:java}
> -Djersey.config.allowSystemPropertiesProvider=true
> -Djersey.config.server.wadl.disableWadl=true
> {code}
> ({{{}ALLOW_SYSTEM_PROPERTIES_PROVIDER{}}} is required for Jersey to honor
> {{WADL_FEATURE_DISABLE}} via a system property at all, since
> {{SystemPropertiesConfigurationModel}} only scans {{System.getProperties()}}
> for Jersey config when that flag is itself set - it's an opt-in mechanism
> added in Jersey 2.29.) This is necessary as an external workaround because the
> Timeline Server's {{ResourceConfig}} is constructed inside Hadoop's own code,
> so its properties cannot be set directly by a downstream deployer.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org