Question

我有一个Alfresco模型类型，其附加属性为d:content。当我尝试在其中存储大于32 KB的内容时，此属性会导致Solr异常。该属性的当前定义是

<property name="acme:secondContent">
  <type>d:content</type>
  <mandatory>false</mandatory>
  <index enabled="true">
    <atomic>true</atomic>
    <stored>true</stored>
    <tokenised>both</tokenised>
  </index>
</property>

如果我将大于32 KB的内容放入此属性，Solr在尝试索引时会抛出此异常：

java.lang.IllegalArgumentException: Document contains at least one immense term in field="content@s____@{http://acme.com/model/custom/1.0}secondContent" (whose UTF8 encoding is longer than the max length 32766), all of which were skipped.  Please correct the analyzer to not produce such terms.

更改index配置没有帮助，index的所有变体以及我尝试过的子元素都会引发错误。

在another question中，答案是：

底层Lucene索引中单个术语的最大大小为32776字节，我认为这是硬编码。

如何配置index属性的d:content，以便我可以保存并索引大于32 KB的内容？

修改

在contentModel.xml中，cm:content配置如下：

<index enabled="true">
  <atomic>true</atomic>
  <stored>false</stored>
  <tokenised>true</tokenised>
</index>

添加内容大于32 KB的简单text/plain文件可以正常运行。

我的自定义属性的index配置仍然失败。

更新

在Alfresco 4.2fCE下，问题确实不。所以这是Alfresco 5.0c和Solr 4.1.9中的一个错误。

更新2：

我filed a bug in the Alfresco JIRA。

Answer 1

假设1

如果您的内容包含类似的非常长的术语（长度为32k的单个单词），则必须实现自己的Lucene分析器以支持该特定类型的文本。这意味着它是与默认Lucene实现相关的问题，因为它是硬编码的。

假设2

否则，如果您的内容不是以上述方式构建的，那对我来说听起来很奇怪，可能是个错误。如果您没有使用tokenised = true进行求解，在这种情况下，可能的解决方法可能是基于更改内容模型以支持父节点与包含所涉及文本但使用默认cm的特定节点类型之间的关联：内容属性。我的意思是使用你应该解决的关联;）

希望这有帮助。

Answer 2

解决方案不是将完整的doc / part存储在索引中。因此，在具有＆gt;的大型属性上尝试避免store = true和tokenize = both / false。 32K。如果您的模型声明如下，则索引应该有效：

<property name="acme:secondContent">
  <type>d:content</type>
  <mandatory>false</mandatory>
  <index enabled="true">
    <atomic>true</atomic>
    <stored>false</stored>
    <tokenised>true</tokenised>
  </index>
</property>

缺点：在我的测试中，我不得不放弃整个索引。我不足以删除solr中的缓存模型

索引d：内容属性＆gt; 32 KB

2 个答案: