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

        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        7d 12h 1m 1 Christian Müller 20/Aug/13 22:34
        Christian Müller made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Christian Müller made changes -
        Fix Version/s 2.11.2 [ 12324654 ]
        Fix Version/s 2.12.0 [ 12323968 ]
        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.
        Christian Müller made changes -
        Field Original Value New Value
        Assignee Christian Müller [ muellerc ]
        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...
        Ales Dolecek created issue -

          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