recover_33, yet again

[Ryan Spires]

Hey Clovertechers,

I would like to get a confirmation.   I am using recover_33 in the following manor, which I believe is the typcial configuration.

Send Ok Procs: save_ob_msg

Await Replies (30 seconds)

Reply Generation: resend_ob_msg

TPS Inbound Reply: check_ack

I have setup a test thread (local host) to send data to.

I wanted to determine what was happening if the data was not getting an acknowlegement, so I did not put any reply ack procs on the connecting thread that I am sending to.  

The scenario:

4 threads:

inbound file thread (1 msg in file) recovery db selected –>

outbound tcp thread, recover_33 procs as described above, recovery db selected sending to localhost

inbound tcp thread, no acking procs, recovery db selected, receivng on port –>

outbound thread dev/null  (just to route the data somewhere)

Start with all threads dead,

turn on inbound file thread, read 1 message

I see msg in state 7  (outbound thread still off)

turn on outbound thread (opening) , msg to state 11

turn on inbound tcp thread (both tcp up)

stop outbound before 30 seconds

I see two messages  1 state 14 and 1 state 7,  (this is what I would expect)  I haven’t received an ack, so my message is in state 14, the other state 7 is the message on the inbound tcp thread.

turn outbound tcp thread back on, now wait for 30 seconds

while waiting, have state 14 and (2) state 7’s (also what I would expect)

However, now things get ugly.  after waiting 30 seconds (timeout) I continue to have state 7 messages piling up, from the resends every 30 seconds, but no longer have the state 14 message.

I bounce the outbound tcp connection, still no additional state 14 message, message is no longer getting resent.

We have effectively lost a message.

FYI, at no time did I bounce the process, just in case one thought it would matter.

Now for my question,

Am I naive and is this has always been the expected behavior of the recover_33.  Perhaps I knew this but effectively blocked the truth from my mind for fear of what that might ulitmately mean.

I know other recover_## procs exist that were written to accomodate other needs, but do any take this into consideration?

FYI, on AIX 5.0.

Thanks,

Ryan Spires

Topic

[Michael Hertel]

See https://usspvlclovertch2.infor.com/viewtopic.php?t=569

Look at Jonathan Hamilton’s reply.

You are missing the kill procs in TPS Inbound reply.

[Ryan Spires]

Sorry..

I forgot to list the kill_ob_save proc… I do have that as well…  Still losing the message.

ryan

[Michael Hertel]

The state 14 messages are being killed as the save ob msg /resend procs are requeing the message as state 11.

The multiple state 7’s are new messages entering rather than resends.

Turn up your EO config and check the process log.

I think you will find that you are not losing messages.

Also, make sure retries is set to -1.

[Russ Ross]

I have posted a word document on how I setup NetConfig to use recover_33 if you are interested take a look at URL:

https://usspvlclovertch2.infor.com/viewtopic.php?t=1898

Russ Ross
RussRoss318@gmail.com

[Author]

Replies