Camel
  1. Camel
  2. CAMEL-6630

Validation using JAXB format is not thread safe

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.11.1
    • Fix Version/s: 2.11.2, 2.12.0
    • Component/s: camel-core
    • Labels:
      None
    • Estimated Complexity:
      Moderate

      Description

      I'm using JAXB format for unmarshaling. It is defined like this:

      <dataFormats>
      <jaxb id="kofax" contextPath="com.indracompany.telefonica.assignmanager"
      schema="classpath:DocumentsDataForAssignManager.xsd"/>
      </dataFormats>

      And used in route like this:

      <unmarshal ref="kofax"/>

      Sometimes however I get following exception:

      org.xml.sax.SAXException: FWK005 parse may not be called while parsing.
      at com.sun.org.apache.xerces.internal.jaxp.validation.Util.toSAXException(Util.java:65) ~[na:1.7.0_21]
      at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:244) ~[na:1.7.0_21]
      at org.apache.camel.converter.jaxb.JaxbDataFormat.createUnmarshaller(JaxbDataFormat.java:347) ~[camel-jaxb-2.11.1.jar:2.11.1]
      at org.apache.camel.converter.jaxb.JaxbDataFormat.unmarshal(JaxbDataFormat.java:171) ~[camel-jaxb-2.11.1.jar:2.11.1]
      at org.apache.camel.processor.UnmarshalProcessor.process(UnmarshalProcessor.java:57) ~[camel-core-2.11.1.jar:2.11.1]

      Seems that the problem is same as in CAMEL-1565. That ticket was however related to <validate> element.

      Right now I have disabled validation on the jaxb format used for unmarshalling and put extra <validate> in the route. It would be however fine to have this issue fixed as well.

        Activity

        Hide
        Christian Müller added a comment -

        I created an unit test which shows this issue.

        The current implementation needs 9.9 seconds on my machine to unmarshall and 5.8 seconds to marshall 10000 sample xml strings/java objects (single threaded). Of course is fails in the multi threaded case...

        By implementing the simplest solution (creating a new SchemaFactory instance per exchange), we got a performance penalty by 20% - 30%.
        Because of this, I solved this by pooling the SchemaFactory instances using a LinkedBlockingQueue like we do it already in org.apache.camel.converter.jaxp.StaxConverter.

        Show
        Christian Müller added a comment - I created an unit test which shows this issue. The current implementation needs 9.9 seconds on my machine to unmarshall and 5.8 seconds to marshall 10000 sample xml strings/java objects (single threaded). Of course is fails in the multi threaded case... By implementing the simplest solution (creating a new SchemaFactory instance per exchange), we got a performance penalty by 20% - 30%. Because of this, I solved this by pooling the SchemaFactory instances using a LinkedBlockingQueue like we do it already in org.apache.camel.converter.jaxp.StaxConverter.
        Hide
        Christian Müller added a comment -

        The reason is, the SchemaFactory is not thread safe. WTF...

        Show
        Christian Müller added a comment - The reason is, the SchemaFactory is not thread safe. WTF...

          People

          • Assignee:
            Christian Müller
            Reporter:
            Ales Dolecek
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4h
              4h
              Remaining:
              Remaining Estimate - 4h
              4h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development