I have a question about load balancing that I can't find in the documentation, and I need for a project.
We use ICN to view data stored in CMOD, and use the round-robin approach to our servers for load balancing.

(We store the data currently in DB2 databases.)

My question is - Does ICN need persistence load balancing?   Or is the round-robin method for logging into ICN handling those potential needs.

Any assistance would be appreciated.

Had the exact same issue. Tracked it down to the following:
In your WebSphere Console navigate to Environment -> Shared Libraries
Select the ECMClientSharedLib and verify that the listed jar files are correct.

What I noticed is that the names did not match with the actual file names.

-SP

Hrm.  I was hoping the indexing parameters would be helpful, but I don't see anything there. 

It sounds like these are temporary files - is your ARS_TMP configuration parameter set to the same directory that you're loading from?  If so, changing it to another directory might move these out of the way, although it doesn't answer the question about what's in them.

You can use the UNIX/Linux 'file' command to see if the OS recognizes the file format:
  file Load.File.PDF.out?

This should give you the best guess for each data type.  If it can't determine what it is, the response will be 'data'.

-JD.

Just updating this to say that CMOD hasn't exposed any new errors in Db2 since my last update.

Ed

The extra files range in size from 20KB to several MB.  They appear to be the size of the PDF files that we trying to archive, with the exact same filenames but just with an extra .OUT1 extension.  The files are for various Applications, but they are all very simple PDF Indexer Applications with a single Trigger field zone and multiple index field zones, similar to the following:

COORDINATES=IN
TRIGGER1=UL(7.03,1.32),LR(7.54,1.59),*,'1',(TYPE=GROUP)
FIELD1=UL(0.35,1.31),LR(1.24,1.60),0,(TRIGGER=1,BASE=0)
FIELD2=UL(1.18,1.32),LR(3.53,1.59),0,(TRIGGER=1,BASE=0)
FIELD3=UL(3.70,1.31),LR(4.45,1.60),0,(TRIGGER=1,BASE=0)
FIELD4=UL(4.39,1.31),LR(5.13,1.60),0,(TRIGGER=1,BASE=0)
FIELD5=UL(1.02,2.43),LR(2.63,2.89),0,(TRIGGER=1,BASE=0)
FIELD6=UL(3.60,2.43),LR(5.09,2.89),0,(TRIGGER=1,BASE=0,DEFAULT='BLANK')
FIELD7=UL(5.63,2.45),LR(7.09,2.88),0,(TRIGGER=1,BASE=0,DEFAULT='BLANK')
FIELD8=UL(7.77,2.45),LR(8.42,2.92),0,(TRIGGER=1,BASE=0)
FIELD9=UL(0.35,1.67),LR(3.79,1.90),0,(TRIGGER=1,BASE=0)
INDEX1='RUNDATE',FIELD3,(TYPE=GROUP)
INDEX2='LOC',FIELD4,(TYPE=GROUP)
INDEX3='INVOICE',FIELD1,(TYPE=GROUP)
INDEX4='NAME',FIELD9,(TYPE=GROUP)
INDEX5='CONTAINER',FIELD2,(TYPE=GROUP)
INDEX6='MANIFESTID',FIELD5,(TYPE=GROUP)
INDEX7='TRACKINGNUM',FIELD6,(TYPE=GROUP)
INDEX8='HAWB',FIELD7,(TYPE=GROUP)
INDEX9='DESTCNTRY',FIELD8,(TYPE=GROUP)
INDEXSTARTBY=1
RESTYPE=ALL

Thanks,

Adding your PDF indexing parameters from your Application Definition, and showing the relative size of the files will help us figure it out.  :)

-JD.

We are trying to enable ODWEK trace on one of our JVM's running a custom ODWEK app. Unfortunately, we are out of support - and the only documentation that we've been given is that we need to recompile our code, adding information about the trace.. which does not seem possible.

Anyone in a similar boat?

I am finding several thousand files on the OnDemand v.10.5 RHEL server that have the files names that end in
.PDF.out0
.PDF.out1
.PDF.out2
.PDF.out3

We are using the PDF Indexer to index and load new PDF files. It seems that all new files have been loading successfully. Are these temp files?   What process added created these files?  Can they be deleted?

Any clues would be helpful.

Thanks,

Basic troubleshooting steps:

 - Make sure the command you're running specifies the full path to the stash file. (/home/archive/ARCHIVE.stash rather than ARCHIVE.stash)
 - Double-check your user id and permissions - does the OS allow you to access the file?

Easiest way forward would be to back up the original stash file and create a new one in its place -- if you don't know the current password, you can change it through the admin client to a new password and use that password to create the new stash file.

Of course, if you create a new one, make sure the OS ownership and permissions are restrictive enough to be secure.

Good luck, and please report back with a resolution.

Thanks.

-JD.