Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed and reviewed
    • Affects versions: 6.4, 7.0
    • Fix versions: 6.5
    • Components: Backend Software
    • Labels:
      None
    • Severity:
      Incorrectly Functioning Without Workaround
    • Steps to reproduce:
      Hide
      Steps to reproduce:
      1. Try to publish or retract to/from OAI-PMH on a distributed cluster
       
       Actual Results:
      Fails with 100% failure rate.

      On the worker with the implementation:
      2019-05-07T18:10:42,394 | WARN | (HttpChannel:579) - /publication/oaipmh org.eclipse.jetty.http.BadMessageException: 501: Unsupported Content-Encoding

      On Admin:
      2019-05-07T18:02:05,497 | ERROR | (WorkflowOperationWorker:180) - Workflow operation 'operation:'retract-oaipmh', position:2, state:'FAILED'' failed
      org.opencastproject.publication.api.PublicationException: Unable to retract media package fc9ca451-e75b-4a49-81d7-224a2e550125 from OAI-PMH channel default using a remote publication service
      at org.opencastproject.publication.oaipmh.remote.OaiPmhPublicationServiceRemoteImpl.retract(OaiPmhPublicationServiceRemoteImpl.java:217) [110:opencast-publication-service-oaipmh-remote:8.0.0.SNAPSHOT]
      at org.opencastproject.workflow.handler.distribution.RetractOaiPmhWorkflowOperationHandler.start(RetractOaiPmhWorkflowOperationHandler.java:92) [74:opencast-distribution-workflowoperation:8.0.0.SNAPSHOT]
       
       
       Expected Results:
       Should work.

      Analysis:
      It seems that with different versions of Karaf respectively its implied dependency updates the behavior and strictness when encountering encoding schemes has changed (the code definitely used to work before).
      Testing with opencast/develop, the line that causes the problem is:
            entity.setContentEncoding(UTF_8.toString());

      whereas UTF_8 is of type CharSet (java.nio.charset.StandardCharsets.UTF_8).

      The OAI-PMH remote is the only code in Opencast that uses setContentEncoding(). Without digging into further analysis, the toString() method of the Standard UTF-8 CharSet likely does not return "utf-8" but something similar. But as said, no digging further here as solution is to simply do the same as all other remotes which is known to work.

      While I did not test whether 6.x is affected, I'm sure this won't break anything and therefore "fix" this in 6.x.




       
       





      Show
      Steps to reproduce: 1. Try to publish or retract to/from OAI-PMH on a distributed cluster    Actual Results: Fails with 100% failure rate. On the worker with the implementation: 2019-05-07T18:10:42,394 | WARN | (HttpChannel:579) - /publication/oaipmh org.eclipse.jetty.http.BadMessageException: 501: Unsupported Content-Encoding On Admin: 2019-05-07T18:02:05,497 | ERROR | (WorkflowOperationWorker:180) - Workflow operation 'operation:'retract-oaipmh', position:2, state:'FAILED'' failed org.opencastproject.publication.api.PublicationException: Unable to retract media package fc9ca451-e75b-4a49-81d7-224a2e550125 from OAI-PMH channel default using a remote publication service at org.opencastproject.publication.oaipmh.remote.OaiPmhPublicationServiceRemoteImpl.retract(OaiPmhPublicationServiceRemoteImpl.java:217) [110:opencast-publication-service-oaipmh-remote:8.0.0.SNAPSHOT] at org.opencastproject.workflow.handler.distribution.RetractOaiPmhWorkflowOperationHandler.start(RetractOaiPmhWorkflowOperationHandler.java:92) [74:opencast-distribution-workflowoperation:8.0.0.SNAPSHOT]      Expected Results:  Should work. Analysis: It seems that with different versions of Karaf respectively its implied dependency updates the behavior and strictness when encountering encoding schemes has changed (the code definitely used to work before). Testing with opencast/develop, the line that causes the problem is:       entity.setContentEncoding(UTF_8.toString()); whereas UTF_8 is of type CharSet (java.nio.charset.StandardCharsets.UTF_8). The OAI-PMH remote is the only code in Opencast that uses setContentEncoding(). Without digging into further analysis, the toString() method of the Standard UTF-8 CharSet likely does not return "utf-8" but something similar. But as said, no digging further here as solution is to simply do the same as all other remotes which is known to work. While I did not test whether 6.x is affected, I'm sure this won't break anything and therefore "fix" this in 6.x.    

      TestRail: Results

        Attachments

          Activity

            People

            • Assignee:
              staubesv Sven Stauber
              Reporter:
              staubesv Sven Stauber
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                TestRail: Cases