[Luke Anderson]

Have either of you seen where using this UPOC thread with Advanced Scheduling causes the process it’s in to panic if you turn off this thread and then turn it back on?

Thanks.

[Luke Anderson]

Our alert calls a bat file and sends three parameters in the call as below via an exec type action in the alert:

@echo off

REM arguments used:  %1  %2  %3

REM  1% = process name

REM  2% = thread name

REM  3% = site name

f:

cd healthvisioncis5.8integratorbin

call setroot f:healthvisioncis5.8integrator %3

hcicmd -p %1 -c “%2 pstop”

REM Wait for 5 seconds before re-starting thread

ping -n 5 localhost > NUL

hcicmd -p %1 -c “%2 pstart”

exit

We are a Window shop so I don’t know if this would work on a Linux box.

[Luke Anderson]

We have this problem with a couple of vendors that send to our Cloverleaf.  I installed an auto-bounce with the inactivity alert for these threads and that has taken care of the problem.  I usually set these up so the auto-bounce happens after 1 or 2 hours of inactivity.

[Luke Anderson]

Robert, I’m testing something similar to this and the thread I’ve setup only picks up my files at the time at the number of minutes after the hour that I have setup on the advanced scheduler.  (It also picks up when the thread is started but that’s not a major issue for me).  Have you tried separating your minutes by commas instead of a from – through kind of entry?  Try 44,45,46,47,48,49 in the minutes parameter instead and see if that works.

[Luke Anderson]

I have found out a little more on this problem scenario where I’m using a UPOC thread and Advanced Scheduling to generate a file at certain times.  When I first start the process and then the new UPOC thread, it performs as expected.  However, when I turn off the thread and attempt to re-start it, it causes the process to panic.  I turned up the EO config and it looks like it is failing on the restart when it goes to evaluate the number tcl procs used by the thread:

[pd  :pdtd:INFO/0:  d_adt_check:05/14/2013 14:25:26] Initializing Protocol Driver

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] *** Next Interval = 84584, Event(1) time = Wed May 15 13:55:10 2013

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] SCHEDULE EVENT DATA for EVENT 0

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Seconds(count = 1, type = TYPE_SINGLE) = 10

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Minutes(count = 1, type = TYPE_SINGLE) = 55

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Hours(count = 1, type = TYPE_SINGLE) = 13

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Monthday = * = NULL

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Month = * = NULL

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Weekday * = NULL

[is  :ISEv:INFO/0:  d_adt_check:05/14/2013 14:25:26] Number of procs = 896756067

[pti :sign:WARN/0:  d_adt_check:05/14/2013 14:25:26] Thread 2 ( d_adt_check ) received signal EXCEPTION_ACCESS_VIOLATION:

 The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.

[pti :sign:WARN/0:  d_adt_check:05/14/2013 14:25:26] PC = 0xffffffff

[pti :thre:INFO/0:  d_adt_check:05/14/2013 14:25:26] Thread 2 was told to shutdown

[msi :msi :INFO/0:  d_adt_check:05/14/2013 14:25:26] Updating shared memory to mark threads as dead.

PANIC: “0”

PANIC: Calling “pti” for thread d_adt_cmd

The first time I start this thread, the number of proces = 1 which is what I have setup on the thread.  But when I stop and start this thread, it somehow things that there are 896756067 tcl procs on this thread and panics.  Anyone seen anything like this before and been able to resolve?  Thanks.

[Luke Anderson]

Hi all, I’m seeing something very similar with a UPOC thread I am trying to setup using the Advanced Scheduling routine.  I can start the thread fine the first time but if I turn the thread off and then back on, it kills the process and throws the error below:

[prod:prod:INFO/0:d_adt_checkfile:05/09/2013 15:00:22] Starting protocol thread d_adt_checkfile as tid 2.

[prod:prod:INFO/0:d_adt_checkfile:05/09/2013 15:00:22] Applying EO config: ”

[pti :sign:WARN/0:d_adt_checkfile:05/09/2013 15:00:23] Thread 2 ( d_adt_checkfile ) received signal EXCEPTION_ACCESS_VIOLATION:

 The thread attempted to read from or write to a virtual address for which it does not have the appropriate access.

[pti :sign:WARN/0:d_adt_checkfile:05/09/2013 15:00:23] PC = 0xffffffff

PANIC: “0”

PANIC: Calling “pti” for thread d_adt_cmd

---

Scheduler State

---

Thread Events     State      Priority Runnable  PT Msgs

  0      0   SCHED_IDLE         0       0       0,0,0

  1      0   SCHED_IDLE         0       0       0,0,0

  2      0   SCHED_IDLE         0       0       1,0,0

The only tcl proc I have in this new thread is applied in the tps entry for the Event Properties in the Advanced Scheduler.  Any help with what is causing this would be much appreciated.  Thanks.

[Luke Anderson]

I used to work at a site that had around 500 threads broken into six or seven sites and it was running on a virtualized Windows platform with Cloverleaf 5.8.  The main problem we ran into was performance issues when a Windows task went to do something where it had to look at a folder with lots of files.  It didn’t so much seem to be a probelm with the size of the files but the number of files in the folder.  Something about how Windows works when it has to index a lot of files in a folder to do something like archiving – copying/deleting files from a folder with lots of files in it can cause it to consume high amounts of CPU resulting in problems with Cloverleaf processes not having enough CPU bandwidth to there job properly.  It even caused a site to freeze or panic sometimes.  We had to end up limiting the number of days we kept files around in our Cloverleaf archive folders in order to keep the file counts down.

[Luke Anderson]

We use Automate.  Pretty easy to setup a new scheduled task to pickup a file from one server and SFTP it to a destination.  The tool has a pretty good GUI to create the scheduled tasks along with associate file handling commands, etc.  Not sure if Cloverleaf can do SFTP without having to purchase the Secure Courier add-on?

[Luke Anderson]

I was wondering if you thought that the sleep command you are using would put everything running in the command thread to sleep as well for that brief period of time?  I thought I saw something about this in another Clovertech thread on a different subject but I’m not sure if that could be potential problem or not.  I am now able to control the thread consistently by using an alternative to the sleep command as below in my .bat file:

hcicmd -p %1 -c “%2 pstop”

REM Wait for 5 seconds before re-starting thread

ping -n 5 localhost > NUL

hcicmd -p %1 -c “%2 pstart”

The ping command is keeping the thread down long enough so that when the command interpreter comes to the pstart command, it can now see that the thread is actually down and executes the re-start consistantly.

Thanks all.

[Luke Anderson]

I checked the log and it did not show any activity.  I am having some luck getting the lastr alert to exec an hcicmd if I enter it as follows with “nt” added onto the command:

hcicmdnt -p p_other -c “cellnetix_r pstop”

hcicmdnt -p p_other -c “cellnetix_r pstart”

(I found this “nt” trick in another Clovertech entry – seems to be the only way to use hcicmd’s from tcl within tcl procs and also these alerts).

I also have the standard e-mail action sandwiched in between these two actions.  This worked once but the alert still leaves the thread in a “down” status sometimes.  The log shows “Thread is already running ‘problem_thread’” when this happens.  So it’s like the engine doesn’t know the status of the thread by the time it execute the pstart command and thinks it is still up.  As I noted before, this isn’t very clean but I’m going to do some more testing.

[Luke Anderson]

Thanks for taking a look James but I just now tried that and nothing happened.  The alert fired because I received an e-mail but the thread status never changed (this connection always changes to “opening” after you bounce it) and there is no evidence that the thread was touched in the process log.  I guess I’ll keep trying some other things.  Thanks.

[Luke Anderson]

Per a suggestion from the MyLawson support task I opened, I was able to get this to work by using just a comma to separate the user email addresses.  Evidently it has to do with what separator characters the email server is setup to recognize.

[Luke Anderson]

I gave that a try but still only sends to the first entry in the list.  I guess I might have to use a distribution group.

[Luke Anderson]

Jim, I’m glad you suggested I try the ORU_R01_ORU_R01 again.  I see now that when I tested with that Trx ID earlier, I still had a secondary filter on my destination thread that was actually causing the messages to fail.  So when I went back in and put the Trx ID you suggested back in after removing the secondary filter, the messages started showing up as expected in the destination thread.

Thanks again for taking a look.

[Luke Anderson]

Yes I have along with a couple of other combinations but so far, no luck.  Thanks for taking a look.

[Author]

Replies