Uploaded image for project: 'Bitrepository'
  1. Bitrepository
  2. BITMAG-1129

Attempting to send invalid messages kills the client thread with no information in the log or return value

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Major
    • 1.9
    • 1.8
    • Delete, Infrastructure
    • None

    Description

      Line 263 in ActiveMQMessageBus.java

          /**
           * Send a message using ActiveMQ.
           *
           * Note that the method is synchronized to avoid multithreaded usage of the providerSession.
           *
           * @param destinationID Name of destination to send message to.
           * @param replyTo       The queue to reply to.
           * @param recipient     The recipient of the message
           * @param collectionID  The collection ID of the message.
           * @param correlationID The correlation ID of the message.
           * @param content       JAXB-serializable object to send.
           */
          private synchronized void sendMessage(String destinationID,
                                                String replyTo,
                                                String recipient,
                                                String collectionID,
                                                String correlationID,
                                                Message content) {
              String xmlContent = null;
              try {
                  xmlContent = jaxbHelper.serializeToXml(content);
                  jaxbHelper.validate(new ByteArrayInputStream(xmlContent.getBytes()));
                  log.trace("The following message is sent to the destination '" + destinationID + "'" + " on message-bus '"
                          + configuration.getName() + "': \n{}", xmlContent);
      
                  javax.jms.Message msg = producerSession.createTextMessage(xmlContent);
                  String stringData = ((TextMessage) msg).getText();
                  String messageSignature = securityManager.signMessage(stringData);
                  msg.setStringProperty(MESSAGE_SIGNATURE_KEY, messageSignature);
                  msg.setStringProperty(MESSAGE_TYPE_KEY, content.getClass().getSimpleName());
                  if (recipient != null) {
                      msg.setStringProperty(MESSAGE_TO_KEY, recipient);
                  }
                  msg.setStringProperty(COLLECTION_ID_KEY, collectionID);
                  msg.setJMSCorrelationID(correlationID);
                  msg.setJMSReplyTo(getDestination(replyTo, producerSession));
      
                  producer.send(getDestination(destinationID, producerSession), msg);
              } catch (SAXException e) {
                  throw new CoordinationLayerException("Rejecting to send invalid message: " + xmlContent, e);
              } catch (Exception e) {
                  throw new CoordinationLayerException("Could not send message", e);
              }
          }
      

      If the validate method fails, a coordinationLayerException is thrown, but this is never caught ANYWHERE, so it bubbles to the surface and kills the thread.

      It seems the Thread have been made by the executur service in ReceivedMessageHandler.java
      There we see new ThreadPools being made, but with the default ThreadFactory. This is surprising as the BitRepository already includes a ThreadFactory that actually sets an UncaughtExceptionHandler
      org.bitrepository.common.DefaultThreadFactory

      Furthermore, even an UncaughtExceptionHandler would not really help the overall design, as the DeletingFile.java shows. When Preservica sends a DeleteFileMessage and waits for a reply, not reply will ever come. The message was never sent, as validate failed, but the sender is not informed, so he will wait until timeout.

      Attachments

        Activity

          People

            abr Asger Askov Blekinge (Inactive)
            abr Asger Askov Blekinge (Inactive)
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: