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; } } }

All files are not displayed in Browser

Subhash

Hi,

I am getting weird error while executing workflow.

There are around 35 files attached to workflow. I am able to see them all in Review stages. Before deploying to Production I have "ViewListOfFileReadyToDeploy" cgitask where .ipl loops through all attached files and displays to user. While displaying the browser only displays 22 file details and part of 23 and stops. Infect the page is not fully displayed. I am able to see all attached 35 files in earlier stages.

I tried to refresh the browser; sometimes one extra character in the file-path is displayed. I even tried with separate browser instance but no luck.

The same workflow is running fine in other environment. In that the browser displays 20 files in one shot then displays remaining 15 after break of 3-4 seconds.

The code in the .ipl is
"foreach my $file (@testFiles)" { ...}
which is very straight forward.

Can anybody help me, what can be the reason?? Has anybody come across such issue?

Thanks and Regards,
Subhash

Find more posts tagged with

Comments

ISCBorisB

Hi,

I am getting weird error while executing workflow.

There are around 35 files attached to workflow. I am able to see them all in Review stages. Before deploying to Production I have "ViewListOfFileReadyToDeploy" cgitask where .ipl loops through all attached files and displays to user. While displaying the browser only displays 22 file details and part of 23 and stops. Infect the page is not fully displayed. I am able to see all attached 35 files in earlier stages.

I tried to refresh the browser; sometimes one extra character in the file-path is displayed. I even tried with separate browser instance but no luck.

The same workflow is running fine in other environment. In that the browser displays 20 files in one shot then displays remaining 15 after break of 3-4 seconds.

The code in the .ipl is
"foreach my $file (@testFiles)" { ...}
which is very straight forward.

Can anybody help me, what can be the reason?? Has anybody come across such issue?

Thanks and Regards,
Subhash

Exceeded command line length or too many Files attached as a command line arguments. Here is your [post=116005]Fix[/post]

Subhash

Hi,

Thanks. I read the Fix you suggested.

All files are not added later, those are the files referred in DCR hence they gets attached as workflow starts. I can see all files are correctly attached in every step before this one (4 stages) which displays all files in pagination. Before getting error the workflow deploys successfully in QA (which acts as preview stage) in one of the earlier stages of the same workflow.

The same workflow runs fine in QA environment. It also ran with 45 files successfully.

My "cgitask" calls .ipl script which in turn is responsible for displaying all files. The code snippets are as follow:

my @taskFiles = $task->GetFiles();
..... (some code here)
foreach my $file ( @taskFiles )
{
my ($lastUser,$cmdLastUser,$fullName) = "";

$count++;

$cmdLastUser = "iwattrib Y:$area"."\\"."$file lastuser";
$lastUser = qx($cmdLastUser);
chomp($lastUser);

#call userprofile method to get fullname
if ($lastUser ne "")
{
$fullName = getRealNameFromConfig($lastUser);
}

print qq~

$count. $file $fullName

~;

}

Hope this will give you more clear picture.

Thanks
Subhash

ISCBorisB

Hard to tell something definitive from few bits of code...

Chances are, you may be facing Web Server Time-out issues. You have system calls in the loop, overhead of such
approach can grow really fast with the growing number of processing Files. Note also that both Web Server Time-out
settings and average System call time span can (and usually do) differ in different Environments

Subhash

Hi,

I will try to look into that aspect, Thanks.

The response is very fast. The first 21 file details get displayed in 3 sec.s then it goes into infinite wait loop. Also after refresing the same page some times extra letter of the file-path is getting displayed.

Also one thing I could not understand is how come half part of the file-path (content\FMO_Library\FMONewYork\AG50614-NY.pdf ) is getting displayed ie
soemtimes "cont"
1. Content\FMO_Library\FMONewYork.ascx
2. content\FMO_Library\FMONewYork\0908_Sat.pdf
3. content\FMO_Library\FMONewYork\0909_Sun.pdf
...
21. content\FMO_Library\FMONewYork\0915_Sat.pdf
22. cont

and sometimes

1. Content\FMO_Library\FMONewYork.ascx
2. content\FMO_Library\FMONewYork\0908_Sat.pdf
3. content\FMO_Library\FMONewYork\0909_Sun.pdf
...
21. content\FMO_Library\FMONewYork\0915_Sat.pdf
22. conte

Any clue??
---------------------
Just now I looked at the timeouts details at the server level but could not find any objectionable. I think TeamSite has its own webserver for user (GUI)responses, are there any specific configuration I should look at?

Thanks
Subhash

ISCBorisB

TeamSite Host normally has two webservers, iwwebd (TomCat, default port 80) to render TS GUI and such + customer Web Server (user choice,
default Port 81) for virtualization and preview. Custom CGI is rendered through iwwebd, default timeout there is 5 mins - so, nothing to look at.

If I were you I would have run a CGI from the command Line mode or perhaps log-out the output somewhere. Examine the output. The very fact that
something is showing on your Page indicates that CGI Process has been terminated. It is possible that under some conditions CGI (or perhaps
nested script you call within it) dies or terminates prematurely.

Matter of fact, partial output or slightly different output may be a tale-tell sign of exactly that sort of problem. The reason is that STDOUT (or any
other stream) buffer flushing is not synchronised with the process that writes there. Even if the process dies on repeated runs executing the same
command the output may differ slightly.

Adam Stoller

Try making the following highlighted change to your script:

...[near top of code]...
$|=1; # forces a flush right away and after every write or print
...[look at end of next line]...
 print qq~<div class="iw-base-plain-text"><b>$count.</b>&nbsp;&nbsp;$file &nbsp;&nbsp;&nbsp;&nbsp;$fullName</div><br>\n~;
...

My guess is that you may be hitting a buffer limit in the rendering of a single line of HTML code and that embedding the newline might help fix that (there was a similar problem with iwsend_mail.ipl a number of years ago).

It may seem a bit far-fetched, but it certainly shouldn't hurt anything and it might actually fix the issue.

Subhash

Hi,

Thanks for your suggestions.

The workflow problem happening only in Production and QA stream is working fine. For any code changes in Production I need to simulate the issue in QA, find out the solution , implement in QA and then only I can promote the code in Production.

Since I am unable to simulate in QA the situation is tricky. Hence I wanted to tryout anything except code changes and wanted to keep it as last option. Looks like I need to discuss with my manager for this exceptional approval.

Thanks once again for your help

Regards,
Subhash