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

Performance issue with CLT

Ram_IWOV

Hi All,

We are facing performance issue with iwprv and iwattrib clt's.
Do we have any other alternatives for this?

Environment:
Teamsite 7.2
Solaris

Regards,
Ram

Find more posts tagged with

Comments

nipper

How are you using iwattrib? XML mode is much better for multiple EAs on each file.

You can use autoprivate.cfg to define private files as well.

Finally the CSSDK *may* offer some help. If you are doing a lot of files in a script, then you have a cost to executing a CLT, just the Unix process invocation.

Adam Stoller

How are you using iwattrib? XML mode is much better for multiple EAs on each file.

You can use autoprivate.cfg to define private files as well.

Finally the CSSDK *may* offer some help. If you are doing a lot of files in a script, then you have a cost to executing a CLT, just the Unix process invocation.

iwextattr is the CLT with XML mode - iwattrib does not have an XML mode - they're used for two different things.

CSSDK / Java code is likely to be more efficient when processing many files - regardless of whether you are looking at iwattrib or iwexattr.

Ram_IWOV

iwextattr is the CLT with XML mode - iwattrib does not have an XML mode - they're used for two different things.

CSSDK / Java code is likely to be more efficient when processing many files - regardless of whether you are looking at iwattrib or iwexattr.

Thanks Ghoti.
We are using custom cgi script for attach dependency task in workflow.Here we are using CLT's for chcking file modified date(iwattrib) and private file(iwprv),based on the values workflow will attach files to task.

Could you tell me any other way to get the above information using CGI script.

Regards,
Ram

Adam Stoller

Thanks Ghoti.
We are using custom cgi script for attach dependency task in workflow.Here we are using CLT's for chcking file modified date(iwattrib) and private file(iwprv),based on the values workflow will attach files to task.

Could you tell me any other way to get the above information using CGI script.

Regards,
Ram

Write the CGI as a CSSDK / JSP program instead of a Perl / CGI. It takes more effort (IMO) but the overall results should be more efficiency.

que_giro

We're using TS/OD 7.2.1 on a 64-bit Windows server. We tried deploying a workarea from one server to another, along with the TS Extended Attributes. Unfortunately the OD Receiver keeps running out of memory. We were told to adjust some Java parameters, which we did, to no avail. Our alternative is to deploy smaller folders.

We've been using the iwextattr command-line tool to export/import EAs, but it takes too darn long. Traversing through each file in the workarea and calling "iwextattr -x" on it is taking around 30 hours.

So, I'm willing to give CS SDK a try. I've looked under C:\Interwoven\TeamSite\cssdk\samples, but does someone have a Java program to "find" all files in a TS area and export their EAs? Could you share what you think might help me (e.g., by attaching the source code here or e-mailing it to me at iwoven_consultant@live.com)?

Many thanks,

S.

Adam Stoller

You probably should have started your own thread rather than side-tracking this pre-existing one, however ....

If you're using OpenDeploy, why don't you use it's built-in feature to transfer EAs rather than creating (and having to maintain) your own custom DNR to do the same?

Or is that what you started with that kept running out of memory?

How much RAM do you have on the sender?
How much RAM do you have on the receiver?

que_giro

If you're using OpenDeploy, why don't you use it's built-in feature to transfer EAs rather than creating (and having to maintain) your own custom DNR to do the same?

Or is that what you started with that kept running out of memory?

How much RAM do you have on the sender?
How much RAM do you have on the receiver?

Yep, deploying a large area with "applyExtAttrs=yes" kept resulting in OD crashes due to memory outages.

We have 16 GB on the sender and receiver, which are both Windows 2008 R2 Standard servers.

I think our best bet is a standalone Java program that uses the CS-SDK to traverse through all the directories in a TeamSite area and extract the EAs from the files found. I was hoping there was already such a program or a similar one out there that I could borrow : ).

Thanks,

S.

Adam Stoller

Yep, deploying a large area with "applyExtAttrs=yes" kept resulting in OD crashes due to memory outages.

We have 16 GB on the sender and receiver, which are both Windows 2008 R2 Standard servers.

I think our best bet is a standalone Java program that uses the CS-SDK to traverse through all the directories in a TeamSite area and extract the EAs from the files found. I was hoping there was already such a program or a similar one out there that I could borrow : ).

Thanks,

S.

Hmm - I would think that 16 GB RAM should be sufficient to do what you want to do with OD directly, especially if you bumped up the java parameters correctly.

Question - how large is your odnodes.xml file?

It may seem like an odd question, but at a previous customer's site we found there was a bug in OD 7.2 which manifested itself by reading in the entire odnodes.xml file whenever a deployment was performed and not releasing the memory it used each time. Granted, this was a HUGE odnodes.xml file at the time (if I recall, something on the order of 2000 or even 20000 lines). The way we figured it out was to look at the memory usage of OD after restarting it, and watching the memory usage after each deployment was kicked off. If the memory continues to grow significantly after each deployment without going back down towards the original size - then you've run into the same bug. We had a black patch created for us, but there may be an official patch or just perhaps upgrading to 7.3.1 OD might suffice. Although, doing a quick check, I don't see this bug listed as "known" or "resolved" in the 7.3 Release Notes...

Also, in 7.2 - there's a performance throttle setting you can play with - see the OpenDeploy 7.2 Administration Guide (page 211) for more details)

If you still cannot get it to work well, you should probably get Support [more] involved with helping you track down the source (and hopefully resolution) of the problem - because it doesn't sound like you're doing anything that shouldn't work.