Unknown Document Conversion Error 260

[hoonsong]

Hi, I am getting the above error. And restarting the DCS process does not help. After setting the log level to 4 the dcs log file reveals the following:

Successfully written entries:7
Start Commit Transaction
Failed to commit shared IPool [260]
Start Rollback transaction
Failed to rollback shared IPool [2502]
Start Rollback transaction
Failed to rollback shared IPool [2502]

My iPool and external file storage is residing in the SAN and shared out by another server. I have stopped my anti-virus completely in the server that is sharing out the folders and it still does not work. Any help would be appreciated! =)

Hoon Song

 

[appnair]

after stopping admin server service look in the ipools for any folders/subfolders that *does not* start with 0000.Typical problems will be a huge message file above 2 GB that
java cannot parse,a corrupt ipool file etc.At this point the normal protocol is to get OT to look at it.they will ask you to do somethings without corrupting your index
In the corrupt ipool messages will be all the dataid's that livelink thinks it should index.if you or any process lock it then you will get errors.typically once search has been running and you run into errors ot support is the best avenue

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in

 

[hoonsong]

Thanks for your reply.

The dataflow directory is only 100MB and the index directory is only 700MB. So there are no message file above 2GB. And there i did a recursive directory listing and couldn't find one that starts with '214' that indicates a start of a rollback transaction (though I did not stop the admin server when i did that).

Opening a ticket with Opentext requires an internal process within my company that might take a while. I am thinking since the index is pretty small, re-indexing might be a faster option. I remember there is Enterprise Data Source Folder Maintenance link that provides the options "Re-extract the data from the source" and "Purge the data flow, recontruct the index, and then extract the data from the source." Would any one of this help? If yes which one?

 

[appnair]

I am saying this form memory so may not be correct.Many times the errors will only show on disk after you stop the process locking it like java(admin server is java)
Re-extracting source is a very lightweight process as all it is doing is finding the min and max of dtree and asking it to go through the indexer again
Purging I think is a much higher process where it will delete the data_flow and re-construct everything.When you are on the page "click help for the page" link and it will tell you official documentation.
Say you are no having problems trying to clone a prod server for some testing/upgrade process?


Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in

 

[hoonsong]

A downtime can be arranged for the re-indexing but of course the shorter the period the better. Do you think re-extracting the source will purge the data flow (and maybe removing whatever that is causing the error) and kickstart the indexing processing from where it left off?

 

[appnair]

I think you will find yourself in the same boat unless and until when the re-indexing occurs your database and EFS contents has changed which may not hold water.If you simply look at what is going on OT just takes batches of object dataid's these are the ipool messages and hands it over to the Java code (search and indexing). The real livelink server has no way control on what is going on there it is just waiting for the other guys to do whatever is needed.however that "whatever" is blackboxed to the entire world because nobody shows/shares searching algorithms or they would be out of the business.Flukes can occurs,have occurred where things will move sometimes forward but my opinion is if you want a true livelink search you should work wih OT to resolve it.

Again I can only say this I remember you posting a few months back saying you wanted to kill indexing at source or something like that.In my 15 years of livelink experience search has never been a concern for me as I knew what it needs space a lot of it and stay away form its internals.Occasional hiccups OT will solve for you.many orgs cannot re-index because the search would take between 30 to 45 days to complete

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in

 

[hoonsong]

Yes indeed previously we wanted to kill the indexing at the source because the requirement hasn't been properly scoped out, now that it has and the necessary resources allocated we are following up on it.

We have managed to purge and re-index the ecm over the weekend and it seems to be working fine. I have also asked the anti-virus to exclude the dataflow and index folders. I have a question do I need to exclude the External File Storage folder as well from being scanned?

I will also try to work out a faster internal process to open tickets with Opentext Support since you mentioned that the indexing process might get stuck again and re-indexing might not be a feasible as the index gets bigger.

Thanks =)

 

[appnair]

In most organizations EFS is managed by a storage team so they have strict guidelines to catch viruses/trojans that web users (including our livelink users) so I find it apparently very unintuitive for OT to give such guidance.Perhaps they stress only the application binaries.If a virus laden file somehow passes form a users's desktop, somehow beating the user's av protection livelink will simply burn the file in the file store.If you don't have av on the file store chances are that the livelink server who does not know anything about viruses et al will index(copy file locally or at the EFS) and people will get possibly the virus laden file.If an AV caught it the it will be quarantined or removed.If the indexer finds the file thru the db it will index system metadata and report in the indexing log.In very new livelink systems search has a lot of administrative gui tools to help admins determine if any such action was happening or not tally files etc. If you are interested grab the search and indexing documents(champion tool kit, knowledge base etc) to see how powerful and useful it is.Frankly when I saw your post a few months back I was wondering what sort of company is this that would not make use of that amazing search architecture...

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in

 

[hoonsong]

Thanks for your reply. Really appreciate your technical advice. I will leave the AV running for the EFS.

We have been monitoring the indexing process the last couple days and noticed that the update distributor and indexing engine coughs up errors whenever backup is taking place. Is there a way to schedule stop and start the indexing process so that it doesn't have to be done manually? I would think this might be the reason for the initial 260 error. I want to put in measures to minimize chances of that happening again.

 

[hoonsong]

I have been guided to a document on how to configure virus scan for content servers. Thought I might share it here for those who have access to the KB. The EFS can still be scanned but with some configurations changes

https://knowledge.opentext.com/knowledge/cs.dll/open/4039549

A quote from the doc which I find useful "When scanning the EFS, it is important to not allow the scanning software to repair, inoculate, quarantine, or delete. Have the virus scanning software log or mark files and notify you (for example, report but take no corrective action). You can then identify the document associated with that file, download it from CS2010, and then delete it or the document version(s) through the GUI. The CS2010 GUI will also have information about the document's version, namely, who added it to CS2010 and when.
After cleaning the downloaded file, you should upload it back into CS2010 as a new version...."