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

TS 6.5 index CLT

System

I have the following questions regarding the index CLT commands for TeamSite 6.5:

1. I indexed a branch, then I added another extended attributed to the FieldMapping.xml. After that, I tried iwndxrefreshbr, but no file is re-index. Do I have to use iwndxrmbr to remove the index collection and then re-index the whole branch after changes being made to the FieldMapping.xml?

2. If I disable event-based updates, and also disable the Interwoven Event Subsystem, can we still run iwndxrefreshbr with -i (incremental) option? Is the -i option based on submit events?

Thanks.

Find more posts tagged with

Comments

smenon

To answer your questions in order..

1. Yes - you have to force the index manager to re-index all the files again and the best way to do that is to remove the collection and add the branch to the index again.

2. In theory - yes, but you will have to run the CLT a regular intervals to refresh your index to keep it current. Remember that your search result is only as accurate as the state of your index. The more important question is - why do you want to disable the event subsystem?

--Sunil Menon
Product Manager
Interwoven, Inc.

DavidMusser

I am considering the same thing. I do not have a DataBase available for the EventSubSystem, and heard that there is some type of issue with 6.5 if you do not have the EventSubSystem hooked to a database. I need to check with support to be sure, but that was what I had heard.

So what I am considering doing is to Turn off the Event SubSystem and then run the indexing nightly. For my client that will meet their search needs.

Can you tell me if the issue I heard about is true, and if so are there any plans to fix the default event subsystem? Since we are not running reporting or DAS I can not think of anything else that will be hurt by turning off the event subsystem. Am I missing anything?

-D

Migrateduser

Thanks for your response. I have the following additional comments:
1. Yes, I also realized by testing with the CLTs that I need to purge all existing index and re-index everything after changes FieldMapping.xml. I need to use iwndxpurgebr. iwndxrmbr doesn't help with this situation. My question is: why would I ever use iwndxrmbr?

2. The reason that I wanted to disable the event subsystem is that we don't have a RMDBS configured with it right now. The flat file grows over 10GB in just a few weeks of time on our dev box. IWOV support told me that we can manually shrink the size down when it's too big, then we just need to refresh index on the branches which unhandle submit events might have lost in the process. I think that's tolerable for short term. My question here is: is "iwndxrefresh -i" faster than "iwndxrefresh -b"? They both have to validate the index status of the entire collection for the branch, right? If so, why is -i faster?

Thanks again.

smenon

1. You might choose to not index a branch but not necessarily remove the collection - in case you want to reinstate the index at some point in the future. You can start where you left. This is equivalent to removing the branch from the branches.cfg file. In such a situation, you can use iwndxrmbr instead of iwndxpurgebr so that your collection is preserved for future use. If you really want to force a re-index, then you have to use iwndxpurgebr to force a re-index of all the content.

2. The difference between -b and -i is that the indexing is processed in two different queues - one for bulk indexing (which is what happens during baseline indexing) and the other for incremental indexing. Since incremental indexing occurs more frequently but takes up less time, depending on how current your index is, you might want to force the indexing the use the appropriate queue. For example, if your index is very stale, it might take a long time to refresh your index. You might want to use the buld indexer queue for this because you don't want to hold up other incremental indexing that comes in after this request. If your index is current, then it shouldn't matter which queue you use because you won't be holding up any other indexing from occuring.

Yes - you should be able to stop the event subsystem and delete your flat file (default database) and restart the event-subsystem at frequent intervals. Refreshing the index should be done in order to process any changes to the content during that down time of the eventsubsystem. However, why wouldn't you just use an RDBMS so you don't have to do this every once in a while? If purchasing an Oracle or SQL Server or DB2 license is too expensive, you can always use MySQL which is a fairly stable but much cheaper alternative.

--Sunil Menon
Product Manager
Interwoven, Inc.

kajjubee

Hi Sunil,
I had initially gone with the default flat file for the event subsytem while upgrading to TS6.5. I recently configured event subsytem to write to an Oracle DB instead of the flat file. But I still see that the flat file openjms.db is still constantly being written to and is still growing. How do I turn it off and direct all the output to the DB? Is there anyway I verify that its writing to the database and not the flat file anymore. I don't have the license for Event Reporting yet, is that the reason for this?
Platform: Solaris 9.

Thanks
K

Migrateduser

Sunil,

Thanks for clearing up my confusions on those CLTs. Will these answers be part of the CLT manual in the future? That will help many others as they start to use these tools.

Yes, we are going with a RDBMS in a few months after we get database server hardware. Just want to make sure the flat file database won't be a show stopper for us in the near term.