[jira] [Commented] (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:comment-tabpanel&focusedCommentId=18116652#comment-18116652 ] 

ASF GitHub Bot commented on YARN-11989:
---------------------------------------

sankalpsthakur opened a new pull request, #8745:
URL: https://github.com/apache/hadoop/pull/8745

   Fixes [YARN-11989](https://issues.apache.org/jira/browse/YARN-11989)
   
   ### Description of PR
   
   Since the Jersey 1 → Jersey 2 migration, Timeline Server v1 logs `SEVERE` from `WadlGeneratorJAXBGrammarGenerator` on essentially every request. Timeline v1 DAOs (`TimelineEntity` / `TimelineEntities`) expose `Map`/`Set` fields that JAXB cannot describe, and Jersey 2 rebuilds a JAXB WADL grammar on each `OPTIONS` probe. `TimelineClient` always sends that `OPTIONS` as its authentication handshake, so every client call produces a SEVERE line.
   
   No Timeline client consumes the generated WADL. This change disables WADL generation on the Timeline Server `ResourceConfig` via `ServerProperties.WADL_FEATURE_DISABLE`.
   
   This is the same class of issue as YARN-2804 (Jersey 1); that workaround did not carry over to Jersey 2.
   
   ### How was this patch tested?
   
   - `TestTimelineServerRequests#testOptionsDoesNotFailWhenWadlIsDisabled` against a live `ApplicationHistoryServer`:
     - `GET /ws/v1/timeline` still returns 200
     - `OPTIONS /ws/v1/timeline` is not a 5xx
     - `GET /application.wadl` returns 404
   
   ### For code changes:
   
   - [x] Does the title of this PR start with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
   - [ ] Object storage: N/A
   - [ ] New dependencies: none
   - [ ] LICENSE/NOTICE: N/A
   
   ### AI Tooling
   
   - [x] The PR includes the phrase "Contains content generated by Cursor Grok 4.6"
   - [x] My use of AI contributions follows the ASF legal policy https://www.apache.org/legal/generative-tooling.html
   
   Contains content generated by Cursor Grok 4.6.
   
   ### Contributor notes
   
   - Apache ICLA may be required for this contribution. I am **not** claiming that an ICLA has been signed.
   - Please do not merge until a committer has confirmed CLA status and reviewed the change.




> 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
>
> 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