Recovery DB Not Working

This topic has 6 replies, 3 voices, and was last updated 17 years, 8 months ago by Sandy McQuay.

Creator

Topic
April 12, 2007 at 3:01 pm #49203
Sandy McQuay
Participant
Cloverleaf 5.2, AIX 5.2

We have one thread (that we are aware of) in a process that is losing queued messages when it is stopped/started. “Use Recovery database” checked on in NetConfig. We have unchecked this option, saved NetConfig, and bounced the process. Then we checked this option, saved NetConfig, and bounced the process again with no change. We have also reinitialized the db using hcidbinit -ACf.

We have other threads in the same process where recovery database does work.

Anyone run into this before?
Creator

Topic

Viewing 5 reply threads

Author

Replies
- April 12, 2007 at 3:47 pm #61089
  Bill Bertera
  Participant
  do the messages originate at all from within tcl? possibly using msgcopy or msgcreate? Maybe you’re splitting a single messages into multiple messages using tcl? If so, make sure you’re configuring the messages to use the RDB, its not the default…
- April 12, 2007 at 5:16 pm #61090
  Michael Hertel
  Participant
  Use recovery database refers to keeping the “inbound” message of that thread to the database.
  
  Therefore, when checked on outbound threads, it will keep the ACK messages coming into the thread in the database.
  
  You need to check “use recovery database” on the inbound source thread in order for the message to be saved on outbound threads.
  
  Bill’s point has bitten me more than once though.
- April 12, 2007 at 6:09 pm #61091
  Sandy McQuay
  Participant
  We’re not using “straight” tcl to create the messages. They are xlated messages from 2 other source threads. As far as we know, the recovery database was working for this particular thread until sometime last week.
  
  One of the source threads reads a file of 500+ records at once. These are translated and sent to the thread that’s having problems. An alert is set up that will stop/start the thread when the queue depth reaches 50.
  
  We started receiving complaints last week that some data was missing. On investigation, it appeared that the thread processed part of the file but not the complete file. We monitored the process and saw that when the alert was triggered and the thread stopped/started, whatever was queued up was lost when the thread came back up.
  
  This is not a new process and has been working extremely well in production for 2 – 3 years. No changes have been made to the configuration (until today that is).
  
  Thanks for any other ideas . . .
- April 12, 2007 at 6:16 pm #61092
  Michael Hertel
  Participant
  Do both inbound threads have “use recovery database” checked?
- April 12, 2007 at 6:50 pm #61093
  Sandy McQuay
  Participant
  Yes. “User Recovery database” in turned on in both threads as well as the one we’re having problems with.
  
  Thanks.
- April 25, 2007 at 8:18 pm #61094
  Sandy McQuay
  Participant
  I lied. There was some TCL code creating new messages and the
  
  -recover -type data switches were not used in the code. We changed the code from:
  
  set nmh [msgcreate $newmessage]
  
  To:
  
  set nmh [msgcreate -recover -type data $newmessage]
  
  and tested (stopped/started the thread) and no messages were lost. So, kudos to Bill Bertera, he nailed it on the head the first time.
  
  Thanks
Author

Replies

Viewing 5 reply threads

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