nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Workflow Memory prob.

dazzlad

Hi.

I am migrating Workflows from TS 5.52 to TS6.1 on Solaris

I have a problem where as everytime my external task is triggered i get the following in iwjoberrors.log:

[Fri Aug 20 11:41:51 2004] Could not run /usr/iw-home/iw-perl/bin/iwperl /iwmnt/default/main/www/_LibMod/STAGING/WorkFlow/dummy.ipl for task 7578; retrying in 1 minute

And a corresponding error in iwtrace.log:

[Fri Aug 20 11:41:51 2004] Unable to allocate shared memory for request

The dummy task is simply calling back (i removed all other code during debugging).

I am not too hot on Solaris as an OS, so has any seen this before and how did you get around it!

Thanks.
It's driving me mad.

Darren

Find more posts tagged with

Comments

dazzlad

Hmm.

Replying to my own post:

So anyway. I did a bit of research and celared up some now the error messages in the logs no longer appear.

If i create a workflow from the UI the external task hangs.

If i run it from the command line, the callback works and the transition to the next task happens.

Any ideas!
-------------------

#!/usr/iw-home/iw-perl/bin/iwperl

use Fidelity::Log;
use TeamSite::WFtask;
use TeamSite::Config;

my ($job_id, $task_id, $area) = @ARGV;
log("$job_id $task_id");

my ($task) = new TeamSite::WFtask($task_id)
or die "Error cannot generate task '$task_id'";
die "Error invalid task '$task_id'" unless ($task->IsValid());

$task->CallBack(0, "Added Files.");

Migrateduser

Could it be permissions on the script?

dazzlad

I don't think so....

the permissions look like:

-r-xr-xr-x 1 a346828 users 412 Aug 20 11:19 dummy.ipl

Thanks.
Darren

Michael

Hi

Just a wild stab in the dark sorry....

When you execute from the command line are you logged in as the same user that the external task executes as? Is it possible that the external task is executing as a user which is restricted in some way so that it can't execute scripts?

Cheers
Michael

Adam Stoller

What does log() do?
I'm assuming you checked the logfile that it writes to and verified that you don't get any entry for $job_id and $task_id ?
Can you show us the actual command statement for the externaltask in the wft?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

Hmm,

Thanks, but all containing directories and the script itself has rx permissions.

Darren

lhdavis

I've seen this scenario before. Maybe try and dump out your environment variables to determine some of the differences between executing it from the command line (when you are logged into the box) versus running it from the UI (where it's a SYSTEM account of some sort).

And it could be something like the SYSTEM account cannot access a directory required to execute iwperl or some other executable. Just a thought.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Edited by lhdavis on 08/20/04 05:57 AM (server time).

dazzlad

hi.

yes, log just writes or appends a logfile. As i said, i can run the task from the command line with a job and task id, and the callback works (also the task and job id appear in my logfile).

the workflow call is below.

This is driving me nuts!

------------------------------

<externaltask name="AddFiles"
owner = "__TAG__('iw_user');"
description = "Add Files to Workflow" start="t">

<areavpath v='__TAG__('iw_workarea');'/>
<successors>
<successorset>
<succ v = "StartFlow"/>
</successorset>
</successors>

<command v="/usr/iw-home/iw-perl/bin/iwperl /iwmnt/default/main/www/_LibMod/STAGING/WorkFlow/dummy.ipl" />

</externaltask>

Michael

Sorry, my post may have been unclear -- I was suggesting that the user specified in your wft may be causing the problem. eg
<externaltask name = "dummyExternalTask"
owner = "THIS_GUY"

Is this the user that you used to test your .ipl from the command line?

Cheers,
Michael

dazzlad

I've executed the task from the command line with the same user as the task owner.

I've also tried changing the task and job owner to root in the workflow (temporarily of course).

It doesn't seem to have any impact however.....

Smiley Sad

lhdavis

Have you tried to move the dummy.ipl under your <iw-home>/custom/bin directory and see if you can execute it from there in the UI? Maybe it's something with trying to execute a script from the STAGING area while in the UI.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Adam Stoller

Does the logfile already exist? What are the permissions on the logfile? What are the permissions for the directories leading up to and including the directory containing the logfile?

The task definition clearly shows you aren't passing any other parameters to your script (which is why I wanted to see it) - so the arg processing in the script looks fine.

You say the script runs fine from the command line, which would seem to rule out any problems in the Fidelity::Log module (the only unknown for those of us in the forum)

Assuming that log() opens a file for appending, writes to it, and then closes the file - I don't see any code-related issues that would explain the problems you are seeing. That leaves permission issues (although the original error messages you received seemed to indicate a possible memory shortage issue - just out of curiosity - how much memory is on your TS server and are there any other applications running on it?)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

Just tried it an nope!

I think some sinsister force is at work here!

dazzlad

I am fairly confident with Fidelity::Log, but just in case i took out references to it so my ext task now is just:

------------------------------------------------

#!/usr/iw-home/iw-perl/bin/iwperl

use TeamSite::WFtask;
use TeamSite::Config;

my ($job_id, $task_id, $area) = @ARGV;

my ($task) = new TeamSite::WFtask($task_id)
or die "Error cannot generate task '$task_id'";
die "Error invalid task '$task_id'" unless ($task->IsValid());

$task->CallBack(0, "Added Files.");

___________________________

I ran this from the command line and again all works well.
iwtrace.log and iwjoberrors.log are no longer reporting any problems, but i think there must be something strange going on.

The server only runs TS and opendeploy, and i don't have a clue to find out how much memory it has Smiley Happy

I guess i'll raise a support case and wait 10 weeks for them to figure it out Smiley Happy

Thanks
Darren

lhdavis

Hmmmm, well here is how the CallBack subroutine changed in the WFTask.pm from 6.0 to 6.1 (I'm assuming 5.5.2 and 6.0 versions were similar)"

6.0 CallBack
sub CallBack
{
my ($this, $retcode, $comment) = @_;

$this->{xml_valid} = 0;

my $imm;
if ($comment =~ /^\s*$/)
{
$imm = `$iwhome/bin/iwcallback $this->{id} $retcode`;
}
else
{
if ($^O eq "MSWin32")
{
# Under Windows, CLT interface requires the command line arguments to be passed
# in Native encoding. We will assume the native encoding to be IW Server native
# encoding...
my ($NativeComment) ;
$NativeComment = UTF8ToNative_2($comment);

# CLT should anchored to IW Server locale... Use "-a" to instruct the CLT to
# anchor to IW Server Locale
$comment =~ s/"/\\"/g; # escape the double quote char
$imm = `$iwhome\\bin\\iwcallback -a $this->{id} $retcode "$NativeComment"`;
}
else
{
# Under Unix system, UTF8 data can be passed in as command line argument.
# Since no LANG info is provide, CLT will be forked and run in C locale
# due to the implementation of TI18NUtils.cpp
# The command line argument will not be converted and the UTF8 data
# will be passed through to TeamSite server...
$comment =~ s/"/\\"/g; # escape the double quote char
$imm = `$iwhome/bin/iwcallback $this->{id} $retcode "$comment"`;
}
}

chop($imm);
my @ret = ($? == 0, new TeamSite::WFtask($imm));
}

6.1 CallBack
sub CallBack
{
my ($this, $retcode, $comment) = @_;

$this->{xml_valid} = 0;

my $imm;
my $program = "$iwhome/bin/iwcallback";
if ($comment =~ /^\s*$/)
{
$imm = `$program $this->{id} $retcode`;
}
else
{
$comment =~ s/"/\\"/g; # escape the double quote char
# CLT interface expects the command line arguments to be passed in
# in Native encoding.
# We will assume the native encoding to be IW Server native encoding...
my $NativeComment = UTF8ToNative_2($comment);

if ($^O eq "MSWin32")
{
$program = "$iwhome\\bin\\iwcallback";
}

# CLT should anchored to IW Server locale...
# Use "-a" to instruct the CLT to anchor to IW Server Locale
$imm = `$program -a $this->{id} $retcode "$NativeComment"`;
}

chop($imm);
my @ret = ($? == 0, new TeamSite::WFtask($imm));
return @ret;
}

Seem very similar but there are some subtle differences.

Have you verified (when you had your log script) that the job and task id's were being passed properly to your external task when executed by the UI? The syntax looks correct but I just wanted to check.

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

dazzlad

Hmm.

I have this in iwtrace.log now

[Fri Aug 20 14:47:38 2004] No free slots in external process queue. If server not busy, consider restarting TeamSite.

And i know that i am the only person using the server.....

D.

dazzlad

It wasn't even getting as far as logging the task id's.

I don't think my script was called at all unless i ran it at the command line....

D.

Adam Stoller

Try running:
/usr/sbin/prtconf | grep Memory

That will, I believe, tell you how much memory is on the server.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

Thanks!

512MB apparently which considering the Install guide recommend 1GB per CPU is probably inadequate.

It's only a dev server and very rarely used but still....

BTW, i didn't set it up. I'm just a contractor!

Thanks
D.

Adam Stoller

My guess is that you're running into problems with the memory available on the server.
If you have the ability to do so - *** as root *** - try stopping/starting the TeamSite server processes and see if it works them (/etc/init.d/iw.server stop ... wait ... /etc/init.d/iw.server start)
If it still doesn't work - see about getting the server rebooted.
If it still doesn't work - see if you can get more memory added to the server (though frankly, if nothing else is running on the server, I'd think 512Mb would be sufficient for single-user development tests like this)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

dazzlad

Guess what.

I rebooted and the workflow ran correctly first time!

Guess it may make sense to do scheduled reboots.....

Thanks for all the help.

Darren

Migrateduser

I didn't read the whole thread, so I don't know if anyone has mentioned this, but it's not a good idea to have a die statement in your externaltask scripts. If you die, you'll never reach the callback, your output will never be displayed anywhere the user can see it, and your externaltask will be hung. Not desirable.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Dwayne

]it's not a good idea to have a die statement in your externaltask scripts

I'd normally agree with you, but these were appropriate uses of die. They were only being used when it wasn't possible to get a valid task object. No valid task object == no way to do the callback anyway.

--

Current project: TS 5.5.2/6.1 W2K

Edited by Dwayne on 08/20/04 08:39 AM (server time).

dazzlad

Definitely.
they'll be replaced with some sort of logging.

I was just using the simplest out of the box example to try and get something working.

Thanks
Darren.