Daily Log for #alfresco IRC Channel

Alfresco discussion and collaboration. Stick around a few hours after asking a question.

Official support for Enterprise subscribers: support.alfresco.com.

Joining the Channel:

Join in the conversation by getting an IRC client and connecting to #alfresco at Freenode. Our you can use the IRC web chat.

More information about the channel is in the wiki.

Getting Help

More help is available in this list of resources.

Daily Log for #alfresco

2020-02-19 05:58:02 GMT <alfresco-discord> <sumit> Hello everyone, I request you for some help. How can we stop updating modified & modifier properties while updating a node property? On a custom action, I add an aspect to a node which helps generating a compliance report for the nodes. But here modifier and modified date shows updated on this action which we need to stop.

2020-02-19 07:30:14 GMT <alfresco-discord> <sumit> dear all, any idea on the above?

2020-02-19 08:39:36 GMT <alfresco-discord> <dgradecak> @sumit you should be able to disable the behavior for that specific node, aspect or all behaviors via org.alfresco.repo.policy.BehaviourFilter

2020-02-19 10:08:03 GMT <alfresco-discord> <sumit> Thanks @dgradecak for responding. I am going to try something like : policyBehaviourFilter.disableBehaviour(node.nodeRef, ContentModel.PROP_MODIFIED);

2020-02-19 10:09:22 GMT <alfresco-discord> <sumit> in an alfresco javascript. So that modified date and modifier not change only for this transaction.

2020-02-19 10:16:09 GMT <alfresco-discord> <dgradecak> I suggest that you omit the prop_modfied param and use just the nodref, or disable all behaviors for the current tx

2020-02-19 10:20:01 GMT <hi-ko> sumit: it's ASPECT_AUDITABLE you need to disable. It' not possible from js without extending the js api

2020-02-19 10:53:18 GMT <angelborroy> https://github.com/aborroy/auditable-aspect-disable

2020-02-19 10:53:19 GMT <alfbot> Title:GitHub - aborroy/auditable-aspect-disable: Alfresco Repository module to disable AUDITABLE ASPECT behaviour (at github.com)

2020-02-19 10:53:23 GMT <angelborroy> This is done with Java API

2020-02-19 11:28:44 GMT <hi-ko> solr4: too many merges; stalling... - does anybody have experience wwith this? First time I see this ...

2020-02-19 11:29:18 GMT <hi-ko> system has 124 segments and stops indexing

2020-02-19 11:33:34 GMT <hi-ko> angelborroy: I thought to read a note from you for an upcomming ASS release with optimized performance. Could you confirm that and if so which repo version do you support?

2020-02-19 11:37:40 GMT <angelborroy> I guess that will be 1.4.2 in pair of weeks

2020-02-19 11:37:46 GMT <angelborroy> Compatible with ACS 6.x

2020-02-19 11:38:19 GMT <alfresco-discord> <dgradecak> will that be solr 8?

2020-02-19 11:39:24 GMT <angelborroy> Not yet

2020-02-19 11:39:43 GMT <angelborroy> We need to deliver content store removal

2020-02-19 11:39:48 GMT <alfresco-discord> <dgradecak> any plans on that for now? I mean moving to a newer solr?

2020-02-19 11:39:56 GMT <angelborroy> And after that (I hope) SOLR 8

2020-02-19 11:40:13 GMT <alfresco-discord> <dgradecak> aha cool

2020-02-19 11:40:16 GMT <angelborroy> If plans not change, SOLR 8 will be ready in 3-4 months

2020-02-19 11:40:30 GMT <angelborroy> Not sure if that will include also SolrCloud

2020-02-19 11:40:38 GMT <alfresco-discord> <dgradecak> you used to do things faster before joining Alfresco πŸ˜‰

2020-02-19 11:41:28 GMT <hi-ko> all our 5.2 systems are somehow stucked due to bad search performance / resource consumtion in comparison to solr4. So I'm quite curious to any performance optimizations ...

2020-02-19 11:42:10 GMT <hi-ko> sorry I meant all migration attemtps to 6.x are somehow stucked ...

2020-02-19 11:42:30 GMT <alfresco-discord> <dgradecak> hi-ko: try to put more ram on the solr server πŸ˜‰

2020-02-19 11:42:45 GMT <hi-ko> no - doesn't help

2020-02-19 11:43:00 GMT <hi-ko> resources are not used.

2020-02-19 11:43:18 GMT <angelborroy> Let’s see if that 1.4.2 release helps

2020-02-19 11:43:49 GMT <hi-ko> neither cpu nor ram. only bad work around is to split everthing using shards on separate multiplicated hardware

2020-02-19 11:45:10 GMT <hi-ko> yes - so we will stay tuned

2020-02-19 11:48:54 GMT <hi-ko> angelborroy: have you experienced "solr4: too many merges; stalling..."?

2020-02-19 11:49:08 GMT <angelborroy> Not yet

2020-02-19 11:50:33 GMT <hi-ko> very strange - it's also the same for me: never seen befor but easy to reproduce by reindexing.

2020-02-19 11:52:08 GMT <alfresco-discord> <dgradecak> have try to update maxMergeCount in solr?

2020-02-19 11:52:17 GMT <alfresco-discord> <dgradecak> increase actually

2020-02-19 11:53:21 GMT <hi-ko> I tried this but without success. Now I found some discussions that increasing is a bad idea since this would result in worse performance

2020-02-19 11:53:35 GMT <alfresco-discord> <dgradecak> and you check maxThreadCount?

2020-02-19 11:53:48 GMT <hi-ko> so I now reduced alfresco's default of 6 to 1

2020-02-19 11:54:35 GMT <hi-ko> int name="maxMergeCount">${merger.maxMergeCount:6}

2020-02-19 11:55:26 GMT <hi-ko> I tried with maxThreadCount=12 wich didn't change the effect.

2020-02-19 11:55:36 GMT <alfresco-discord> <dgradecak> not sure if 1 is ok

2020-02-19 11:55:50 GMT <hi-ko> just for testing.

2020-02-19 11:55:52 GMT <alfresco-discord> <dgradecak> may thread has to be less tha max merge

2020-02-19 11:57:53 GMT <alfresco-discord> <dgradecak> I guess you read this https://lucene.apache.org/solr/guide/8_2/taking-solr-to-production.html#dynamic-defaults-for-concurrentmergescheduler

2020-02-19 11:57:55 GMT <alfbot> Title:Taking Solr to Production | Apache Solr Reference Guide 8.2 (at lucene.apache.org)

2020-02-19 11:58:49 GMT <alfresco-discord> <dgradecak> "This auto-detection works only on Linux and even then it is not guaranteed to be correct. On all other platforms, the disk is assumed to be rotational. Therefore, if the auto-detection fails or is incorrect then indexing performance can suffer badly due to the wrong defaults."

2020-02-19 11:59:39 GMT <hi-ko> something similar in an older version - yes.

2020-02-19 11:59:59 GMT <alfresco-discord> <dgradecak> I think those applies to older version also

2020-02-19 12:00:37 GMT <alfresco-discord> <dgradecak> but if this does not help, than you are left to your self πŸ˜‰

2020-02-19 12:46:00 GMT <alfresco-discord> <binduwavell> @sumit if you you have version on property changes you may also want to disable the Versionable aspect. It can be done from secure JavaScript if you grab the spring application context and grab the right beans. Takes a while to figure out.

2020-02-19 12:47:17 GMT <alfresco-discord> <binduwavell> Hi-ko I believe that solr is using memory mapped file IO so you need to leave lots of memory for the OS to disk cache indexes. Are you giving all RAM to the JVM or leaving plenty for the OS?

2020-02-19 13:07:28 GMT <hi-ko> binduwavell: by default I leave 50% RAM for the OS/fs cache

End of Daily Log

The other logs are at http://esplins.org/hash_alfresco