客户系统上线前,发现在生产环境的Oracle Enterprise Linux 6.1上的UCM 11gR5打开文件时,一直显示索引错误,信息“Text
conversion of the file …… failed.
Content has been indexed with Info only. Resubmit should only be performed if
the problem has been resolved.”如下图所示:
打开indexer的trace,点击重新提交后,得到以下信息,初步判断是因为textexport找不到必要的库文件导致。
没有仔细看trace信息内容,开始在网上和oracle support网站找text conversion相关的信息,相关的解决方案主要是确认textexport的执行权限或者是设置LD_LIBRARY_PATH和ContentAccessExtraLibDir(在intradoc.cfg文件)几种方式,但是试过这几种方式都不奏效,如此试了几次,也只好放弃。
再一次回到正常分析的路子上来,从trace信息中可以看出是找到到共享库libz.,尝试在/usr/lib和/usr/lib64找libz.so,有64位的文件,但是没有32位的文件。难道象很多程序一样,UCM也是用32位的libz.so来执行text conversion的命令,google了一把,发现libz.so是zlib包里,用yum install zlib.i686实现相关包的安装,确认libz.so存在于相关的文件夹下,重新启动Content Server,再点击重新提交,问题解决。
在Repository Manager重新提交所有文档,再重建索引,完成已检入文件的全文索引支持。
打开indexer的trace,点击重新提交后,得到以下信息,初步判断是因为textexport找不到必要的库文件导致。
>indexer/7 01.13 14:10:03.450 index update work InputFilePath
is: </u01/app/oracle/Middleware/user_projects/domains/ecm_domain/ucm/cs/search/bulkload/~vault/1524pptx> indexer/7 01.13
14:10:03.450 index update work OutputFilePath is:
</u01/app/oracle/Middleware/user_projects/domains/ecm_domain/ucm/cs/search/ots1/bulkload/~export/gy-001524.txt>
>indexer/7 01.13 14:10:03.450 index update work Sending document to conversion >(internal)/7 01.13 14:10:03.496 TextExport #7531#8FDB#7A0B
'TextExport' #610F#5916#4E2D#6B62#3002 intradoc.common.ServiceException:
!csErrorReturnedByProcess,TextExport!$/u01/app/oracle/Middleware/Oracle_ECM1/ucm/idc/components/ContentAccess-linux/linux/lib/contentaccess/textexport:
error while loading shared libraries: libz.
(internal)/7 01.13 14:10:03.496 TextExport at intradoc.taskmanager.TaskLauncher.launchExe(TaskLauncher.java:381) (internal)/7 01.13
14:10:03.496 TextExport
at intradoc.taskmanager.TaskMonitor$1.run(TaskMonitor.java:116) (internal)/7 01.13
14:10:03.496 TextExport
at java.lang.Thread.run(Thread.java:662)
没有仔细看trace信息内容,开始在网上和oracle support网站找text conversion相关的信息,相关的解决方案主要是确认textexport的执行权限或者是设置LD_LIBRARY_PATH和ContentAccessExtraLibDir(在intradoc.cfg文件)几种方式,但是试过这几种方式都不奏效,如此试了几次,也只好放弃。
再一次回到正常分析的路子上来,从trace信息中可以看出是找到到共享库libz.,尝试在/usr/lib和/usr/lib64找libz.so,有64位的文件,但是没有32位的文件。难道象很多程序一样,UCM也是用32位的libz.so来执行text conversion的命令,google了一把,发现libz.so是zlib包里,用yum install zlib.i686实现相关包的安装,确认libz.so存在于相关的文件夹下,重新启动Content Server,再点击重新提交,问题解决。
在Repository Manager重新提交所有文档,再重建索引,完成已检入文件的全文索引支持。
评论
发表评论