Deleting messages from the engine

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Deleting messages from the engine

  • Creator
    Topic
  • #49825
    Mark Thompson
    Participant

      An observation for people who delete messages from the recovery database and assume they are deleted from the engine.  Not always true.

      For the most part, messages exist 2 places: in engine memory and in the recovery database (assuming you are using RDB).  Deleting a message from the recovery database does not delete it from engine memory.

      Example 1:  Say an application has been down for a while and has 20 messages piled up (pending) in an outbound engine thread.  The thread shows “Opening” as the protocol status.  The app owner calls and says “Can you please kill off the messages because we entered them manually.”  The 20 messages are in state 11 (already been translated, OB post-TPS) so we delete them from the recovery database.  The application starts up their side of the interface, status changes to “Up” and presto, they get the 20 messages.  Moral of the story: Stop the outbound thread when deleting its state 11 messages.  This forces the thread to create a new “pending” list during start-up based on what is in the recovery database.

      Example  2: An outbound thread is stopped on the engine (“Down”) and messages are waiting to be delivered to that outbound thread.  The recovery database shows the messages as state 7 (Post xlate).  You delete the messages from the recovery database and then start the outbound thread.  Presto, all the messages are delivered to the outbound thread and on to the external application.  It could be embarassing, or worse, if you thought they were deleted.  These messages were hiding in the translate thread, not a protocol thread.  Even though they don’t show up in the recovery database after they are deleted, they can still get delivered.  Moral of the story: Since you can’t directly control the translate thread, stop the entire process to remove state 7 messages from memory.

      It doesn’t matter whether you use the command line or GUI to remove the RDB messages.  They only remove the messages from the Recovery Database, not from engine memory.

      We are running Cloverleaf 5.5 & 5.6 on AIX 5.3, but I don’t think this is particularly version or OS dependent.  Perhaps someone running other platforms can confirm this.

      Hope this saves someone from having to explain how deleted messages actually got delivered.

      - Mark Thompson
      HealthPartners

    Viewing 0 reply threads
    • Author
      Replies
      • #63745
        David Burks
        Participant

          I can confirm this has nothing to do with which OS or version you are running.  Mark is right.  The messages are in memory and that memory is owned by the process.  To get rid of them from memory stop the process, not the thread.  The rule I use is if you are going to delete messages from the recovery database stop the process first.  Follow that and you are guaranteed success every time.

      Viewing 0 reply threads
      • The forum ‘Cloverleaf’ is closed to new topics and replies.