Duplicate state 14 messages in Cloverleaf 5.6

Homepage Clovertech Forums Read Only Archives Annoucements Technical Bulletins Duplicate state 14 messages in Cloverleaf 5.6

  • Creator
    Topic
  • #49928
    Rob Abbott
    Keymaster

    We have discovered the cause of the “duplicate state 14 message” issue that some customers have experienced in Cloverleaf 5.6.

    Rob Abbott
    Director, Product Management - Infor Cloverleaf

Viewing 7 reply threads
  • Author
    Replies
    • #64129
      Jim Kosloskey
      Participant

      Rob,

      Thanks for the information.

      Am I correct in guessing that the new auto acknowledgment handling is managing the just sent mesage and managing that message related to acknowledgment receipt?

      Am I also correct in guessing that the automated activity (loosely described above) is happening all the time even if it is not configured and that is why if using the Recover_33 procs set (or derivative) a second Saved message appears?

      Both guesses above being correct, can one expect there will be a correction in Rev1?

      Thanks,

      Jim Kosloskey

      email: jim.kosloskey@jim-kosloskey.com

    • #64130
      Rob Abbott
      Keymaster

      The extra state 14 message is not related to automated resend.  It’s related to a bugfix for recover_33 that made the resent message recoverable.  More details on this issue here: http://clovertech.infor.com/viewtopic.php?t=2160

      Automated resend is designed to completely do away with the need for recover_33 procs.

      Automated resend does not go into effect if it’s not configured.

      As the bulletin states we do plan to fix this in a rev, timing and method for a fix are unknown at this time.

      Rob Abbott
      Director, Product Management - Infor Cloverleaf

    • #64131
      Jim Kosloskey
      Participant

      Rob,

      OK so this situation (duplicate state 14 mesages only happens for those who did not heed Charlie’s post and correct their Recover_33?

      Thanks,

      Jim Kosloskey

      email: jim.kosloskey@jim-kosloskey.com

    • #64132
      Rob Abbott
      Keymaster

      No.  Anyone who didn’t heed Charlie’s advice is protected in 5.6 by the fix that is causing this issue.

      This situation affects anyone running 5.6 and recover_33.  If anyone running this combination stops a thread while it is waiting for a reply, duplicate state 14 messaages will result.  

      Until a fix is available, one of the two workarounds detailed in the bulletin must be used in order to avoid this situation.

      Rob Abbott
      Director, Product Management - Infor Cloverleaf

    • #64133
      Jim Kosloskey
      Participant

      Rob,

      OK I think that has finally sunk in  🙄 .

      Thanks again for the post.

      Jim Kosloskey

      email: jim.kosloskey@jim-kosloskey.com

    • #64134

      A question on check_ack. I understand from other threads that check_ack is used to validate acks. Currently, we’re using check_ack in every outbound tcp/ip thread. I’ve removed all of the other recover procs and configured the threads to use the built-in resend option. We don’t need to validate acks in all but two of our threads. So, if you don’t need to validate the ack, how should you configure outbound tcp/ip threads in 5.6?

      -- Max Drown (Infor)

    • #64135
      Jim Kosloskey
      Participant

      Max,

      You could just use hcitpsmsgkill to KILL the replies.

      Jim Kosloskey

      email: jim.kosloskey@jim-kosloskey.com

    • #64136

      Jim Kosloskey wrote:

      Max,

      You could just use hcitpsmsgkill to KILL the replies.

      Jim Kosloskey

      Will the ACKs still be written to the smat files?

      -- Max Drown (Infor)

Viewing 7 reply threads
  • The forum ‘Technical Bulletins’ is closed to new topics and replies.

Forum Statistics

Registered Users
4,964
Forums
28
Topics
9,104
Replies
33,616
Topic Tags
248