点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
大家好,最近我们遇到了以下问题-
2018-03-02 23:58:34,607 [错误] [chdaePoolEventHandler]无法启动数据中心java.lang.RuntimeException:要在池此处的池名中发布的项目数超过了限制 由datahub.init.publishable.items.query.limit属性提供的100000。 请以创建-拖放模式重新启动Data Hub并重新发送或以标准模式重新启动Data Hub并在此处池名触发池的发布。 在com.hybris.datahub.lifecycle.ReinitializeCanonicalCacheHandler.initializePool(ReinitializeCanonicalCacheHandler.java:60)〜[datahub-in-memory-6.6.0.0-RC4.jar:6.6.0.0-RC4]
当我们将datahub.init.publishable.items.query.limit的值修改为更大的值时,此问题得到解决。 先前它使用默认值'10000',但是在尝试分析根本原因时,注意到以下内容
-
大多数状态为"成功"的规范项都在CanonicalItem表中。 尽管启用了以下属性,但没有被删除。 datahub.cleanup.publisheditems.enabled = true
-
池中的项目数由多少组成? 它是该池中原始和规范项的总数吗? 因为我们使用IN_MEMORY配置模式,所以不会保留目标项目。
-
是否可以通过API检查池大小以进行监视? 一旦接近阈值,我们就可以手动删除已处理的原始和规范项目。 还有其他更好的解决方案来避免此问题吗? 请提出建议。
Kauser,
问题的根本原因是DataHub不执行发布。 他们应该在构图完成后立即就学了,但事实并非如此。 检查日志中可能提示您但配置错误的内容。 阅读动态出版物文档。 最有可能的
target.system.publication.configuration
属性不存在或不正确。 它应包含以下格式的值:对于要将数据加载到的每个池,池与目标目标系统之间应有一个映射。 首先解决此问题以启用自动发布。
然后,没有简单的方法来解决发布缺失的结果,因此在考虑选项之前,让我回答您遇到的三个问题。
即使清除扩展程序配置正确并正在运行,它也不会删除未发布的规范项。 它仅删除已经发布的项目。 因此,现在让我们忽略它-datahub-cleanup可能没有任何问题。 以下是一些选项:通常,池包含原始项目,规范项目和目标项目。 在IN_MEMORY模式下,这是真的-没有目标项目。 但是,在您看到的异常情况下,它只是规范项目,其状态为SUCCESS,在CanItemPubStatus表中没有相应的记录。 尝试发布后,该表中将有一个已发布规范项的记录。
是的,有。 对于这种特定情况,可以使用
/pools/{poolName}/status-counts/canonical
来检索您拥有多少规范项(计数按项状态划分)和/pools/{ poolName}/status-counts/canonical-publication
可用于检索已发布项目的计数(计数按发布状态划分)。 可以在 REST API 中找到更多详细信息。 这些数字也暴露在DataHub仪表板上的Backoffice内部。现在,我想到了修复数据的选项:
如果可以将原始数据重新发送到DataHub,则来自异常的建议可能是最简单的。 将autoInitMode更改为create-drop,重新启动Data并再次开始发送数据。 在发送数据时,项目应发布,问题已解决。
再次增强了
datahub.init.publishable.items.query.limit
属性。 但是,显然有超过10万个未发布的规范项目,因此这可能导致:内存不足异常
表现很差
由于数据量大和性能差,还有一些其他意外错误。
在数据库中执行手动操作。 固定DataHub时,请确保没有新数据进入并且没有运行合成:
进行数据库备份。
确保CanonicalItem中没有状态为ARCHIVED的项目(否则让datahub-cleanup删除它们或手动删除它们)
将CanonicalItem中的项目状态更改为ARCHIVED(可能是1万个左右的项目除外)。
重新启动DataHub。 它应尝试发布状态为SUCCESS的剩余10000件商品。
将另一部分规范项从"已归档"状态更新为"成功",然后再次重新启动DataHub。
继续这样做,直到所有项目都发布为止。
重试在先前发布中未能发布的项目与重试以重新连接到目标系统(如果在发布期间未响应)之间存在混淆。 详细信息和
datahub.retry.multiplier
位于检查目标系统可用性 。 我怀疑datahub.retry.initial.interval.millis
配置错误,并且使出版物运行了很长时间。原始项目的增长会减慢合成速度,但与您的问题无关。 检查清除扩展是否有效。 项目应删除。
是的,我们已启用发布重试。 " datahub.max.publication.retry.count"设置为很高的值。 我们将重试间隔设置为24小时(87000000毫秒)。 我看到每个失败的规范项目每天尝试重试一次发布。 该属性究竟指定了什么" datahub.retry.multiplier"? 当前设置为" 0"。
大多数错误是依赖错误。 通过后台检查时的错误计数非常低。 但是,通过状态计数API检查时,数字很大。 还应注意,未删除任何已处理的原始项目。 所有这些都会导致池大小增加。 如果不删除已处理的原始项目,这是否是清理扩展中的错误?
在数据不断增长的情况下,单独的池将无济于事。 对于常量查找表很有用。 扩展清除扩展可能是最好的方法。 针对您遇到的异常发布一个单独的问题,并要求我提供答案。 将堆栈跟踪放到DataHub类。
此外,RawItems应该通过清理删除-奇怪的是它们没有被删除。 也值得研究。
我发现,有一种特殊的规范项类型是中间的,而不是任何目标对象的规范源。 它用于填充要发布的规范项中的某些字段。 由于中间对象在CanItemPubStatus表中没有条目,因此它永远不会删除。 我试图为此类对象实现数据清除,但是在注入以下属性'cleanupService,handlerRegistry'时出现异常。 我在依赖项中添加了清理扩展。 以下是 https://wiki.hybris后面的网址。 com/display/release5/Eliminate + Auditing + Records + to +改善+性能
一周热门 更多>