Does the view counter initiate a reindexing of journal articles?

[Klaus Bachmaier，修改在7 年前。]

We wrote an index port processer for journal articles in one of our projects. At some point this post processor logs a message into the server logs. What we now see are thousands of very similar lines like this in the log files, which sum up to nearly 200MB log data per day:

08:38:50,574 INFO  [BufferedIncreament-AssetEntryLocalService.incrementViewCounter(long,String,long,int)-1][JournalArticleIndexerPostProcessor:122]  custom-search JournalArticle postProcessDocument(): ddmStructureName_de_DE = IMAGESLIDER 2015

Two strange things here: I've disabled the view counter in all Asset Publishers and as well in portal-ext.properties with this property:

asset.entry.increment.view.counter.enabled=false

So why is the AssetEntryLocalService.incrementViewCounter() function still running in the first place?

Why is the post indexer starting with each counter increment? Is this normal behaviour?

[Jorge Díaz，修改在7 年前。]

Hi Klaus,

About your questions:

Klaus Bachmaier:

Two strange things here: I've disabled the view counter in all Asset Publishers and as well in portal-ext.properties with this property:

asset.entry.increment.view.counter.enabled=false

So why is the AssetEntryLocalService.incrementViewCounter() function still running in the first place?

That portal.properties property was deprecated in 6.2, for 6.2 and 7.0 you must use the buffered.increment.* properties

For example, in order to avoid throughput issues, you can configure buffer increment functionality to increment values only once each minute or each 10000 requests: (requests are kept in memory and they are done grouped)

buffered.increment.standby.queue.threshold[AssetEntry]=10000
buffered.increment.standby.time.upper.limit[AssetEntry]=60

you can also disable the increment functionallity for AssetEntry setting:

buffered.increment.enabled[AssetEntry]=false

so in 6.1 you could only enable/disable the incrementViewCounter() functionallity and since 6.2 you can also configure the update frequency policy.

More info see:

• 6.1 portal.properties: https://docs.liferay.com/portal/6.1/propertiesdoc/portal.properties.html#Asset
• 6.2 portal.properties: https://docs.liferay.com/portal/6.2/propertiesdoc/portal.properties.html#Buffered Increment
• 7.0 portal.properties: https://docs.liferay.com/portal/7.0/propertiesdoc/portal.properties.html#Buffered Increment

Klaus Bachmaier:

Why is the post indexer starting with each counter increment? Is this normal behaviour?

That was a bug fixed in LPS-65978. This LPS was included in:

• Liferay 7 GA3
• Liferay DXP fixpack 1
• Liferay 6.2 EE fixpack 111

If you have throughput issues after that LPS, try configuring:

buffered.increment.standby.queue.threshold[AssetEntry]=10000
buffered.increment.standby.time.upper.limit[AssetEntry]=60

adjust that values in your environment, perhaps you have to enter bigger or smaller values.

[Klaus Bachmaier，修改在7 年前。]

Thank you Jorge for your advice.

Jorge Díaz:

That was a bug fixed in LPS-65978. This LPS was included in:

• Liferay 7 GA3
• Liferay DXP fixpack 1
• Liferay 6.2 EE fixpack 111

That's strange, as we just updated the customers server to SP17 (Fixpack 135) recently, and still see this behaviour.
I'll try the new property settings (Looks like I've been a little bit too fast with "copy & paste" of the property setting, that I've found in an obviously outdated Liferay book )

[Jorge Díaz，修改在7 年前。]

Klaus Bachmaier:

That's strange, as we just updated the customers server to SP17 (Fixpack 135) recently, and still see this behaviour.

Fixpack 135 is greater than Fixpack 111, so it includes LPS-65978.

As seems you are using Liferay 6.2 EE, in case of having issues with the product, you should open a LESA ticket to Liferay support team.