Duplicate state 14 messages in Cloverleaf 5.6

This topic has 8 replies, 3 voices, and was last updated 16 years, 8 months ago by Max Drown (Infor).

Creator

Topic
March 25, 2008 at 1:28 pm #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
Cloverleaf Emeritus
Creator

Topic

Viewing 7 reply threads

Author

Replies
- March 25, 2008 at 5:21 pm #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 29+ years Cloverleaf, 59 years IT - old fart.
- March 25, 2008 at 6:13 pm #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: https://usspvlclovertch2.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
  Cloverleaf Emeritus
- March 25, 2008 at 6:25 pm #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 29+ years Cloverleaf, 59 years IT - old fart.
- March 25, 2008 at 6:30 pm #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
  Cloverleaf Emeritus
- March 25, 2008 at 6:35 pm #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 29+ years Cloverleaf, 59 years IT - old fart.
- March 31, 2008 at 5:02 pm #64134
  Max Drown (Infor)
  Keymaster
  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)
- March 31, 2008 at 5:06 pm #64135
  Jim Kosloskey
  Participant
  Max,
  
  You could just use hcitpsmsgkill to KILL the replies.
  
  Jim Kosloskey
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- March 31, 2008 at 5:08 pm #64136
  Max Drown (Infor)
  Keymaster
  ~~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)
Author

Replies

Viewing 7 reply threads

The forum ‘Technical Bulletins’ is closed to new topics and replies.