Duplicate state 14 messages in Cloverleaf 5.6

[Rob Abbott]

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

Topic

[Jim Kosloskey]

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

[Rob Abbott]

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

[Jim Kosloskey]

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

[Rob Abbott]

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

[Jim Kosloskey]

Rob,

OK I think that has finally sunk in  🙄 .

Thanks again for the post.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com

[Max Drown (Infor)]

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)

[Jim Kosloskey]

Max,

You could just use hcitpsmsgkill to KILL the replies.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com

[Max Drown (Infor)]

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