深入浅出 jackrabbit 六 文本提取（上)

核心提示：用lucene作过索引的同学一定对文本提取不会陌生，但凡有binary需要作索引的地方，深入浅出 jackrabbit 六 文本提取（上)，那就离不开文本的提取，而jackrabbit是可以存储二进制数据的，因为一般来说大文本做索引的实时性要求并不是很高，所以因为同步文本提取这个原因导致系统的并发量急剧下降，而这些二进

用lucene作过索引的同学一定对文本提取不会陌生，但凡有binary需要作索引的地方，那就离不开文本的提取，而jackrabbit是可以存储二进制数据的，而这些二进制数据中包含的文本也是需要被搜索到的，所以jackrabbit里建索引的过程中自然离不开文本提取。

那么看到本文的标题，有经验的同学一定会问，前面都已经讲过索引的提交了，为什么到现在才讲文本提取呢。要回答这个问题，我们必须来回顾一下jackrabbit中建索引的流程（简单的划分为4个步骤，如下）：

1创建document-----2加入到volatileindex的pending缓存中---------3生成index数据到内存-------4将内存中的二进制数据刷到文件系统。

那么哪里需要提取文本呢，很显然是在创建document的时候。那这个话题是不是应该放到创建document一文中阐述比较好呢，非也，这个问题之所以放到索引提交后面阐述是有原因的。

一般来说，文本提取的耗时长度和文本的大小有直接关系，当文本的大小超过一定的量之后，提取的速度会比较慢。那么当前的WorkThread就会一直耗在这块地方，也就是上述流程中的第一步，这样WorkThread一定要等到文本提取之后才能返回，不知道有多少用户有这个耐性等待下去呢。而且这里还有另外一个问题，那就是WorkThread如果因为这种操作而阻塞住，那么它回线程池的时间就会延后，新的请求过来因为拿到不到线程池中的 WorkThread而不得不等待，一直到池中有可用线程为止，或者选择timeout返回，那么如果因为WorkThread都耗在文本提取这个地方，那么就太冤了，因为一般来说大文本做索引的实时性要求并不是很高，所以因为同步文本提取这个原因导致系统的并发量急剧下降，用户就会开始抱怨，你们这个破玩意怎么会这么慢？