Thread takes forever to stop

This topic has 2 replies, 2 voices, and was last updated 14 years, 2 months ago by Eric Kavanagh.

Creator

Topic
November 10, 2010 at 2:31 pm #52099
Eric Kavanagh
Participant
Hi

I have plowed through all the cases, but I cannot find anything relating to this problem.

Its a simple script, just adds an edi envelope to a messsage and sends it on. The process takes as long to stop as the number of messages processes.

log message just repeats, in this case 42685 times

datum1……

datum42685 EDI_FPAS_add_frame {MSGID message0} {CONTEXT sms_ob_data} {ARGS {}} {MODE run} {VERSION 3.0}

It makes it almost impossible to have any sort of restart.

Regards

Eric M. Kavanagh
Creator

Topic

Viewing 1 reply thread

Author

Replies
- November 10, 2010 at 3:46 pm #73064
  Rob Abbott
  Keymaster
  The tcl you’re using contains a memory leak – it’s leaking dat handles. When the thread stops it dumps a list of all the leaked handles to warn you about the leak and aid you in debugging. In your case dat handles are created whenever you do a ‘grmfetch’.
  
  To fix this, you’ll need to do the following at the top of the run mode:
  
  set datList [datlist]
  
  then at the end of the run mode you do the following to clear out any dat handles created during this proc’s execution:
  
  hcidatlistreset $datList
  
  Hope this helps.
  
  Rob Abbott
  Cloverleaf Emeritus
- November 10, 2010 at 6:13 pm #73065
  Eric Kavanagh
  Participant
  Hi
  
  I am speechless, thanks. I put in the code, sent a few test messages, stopped the tread and the datumxxx never appeared.
  
  Should this always be used?
  
  Is there such a solution for the grmxxx
  
  grm0 EDI_FPAS_add_frame {MSGID message0} {CONTEXT sms_ob_data} {ARGS {}} {MODE run} {VERSION 3.0}
  
  set grmlist [grmlist]
  
  trying while asking!
  
  Regards
  
  Eric M. Kavanagh
Author

Replies

Viewing 1 reply thread

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