So what that setting does is disabling archiving, not the activity log itself.

I don't think there is an official, supported way to disable activity log. 

I also think there is an unofficial, unsupported way to do that, but Per probably recommends against that :)

Ah, I see. 

We are running a huge catalog import, and during the import the log is filled with errors like these:

2017-11-09 14:37:54,499 [56] ERROR lambda_method: One or more errors occurred.
System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: The event manager has been stopped.
   at EPiServer.Events.ChangeNotification.Implementation.ManagedChangeProcessor`1.ConsumeNotifyChangeResults(IEnumerable`1 items)
   at EPiServer.Events.ChangeNotification.Implementation.ChangeRouter.NotifyChanges(IEnumerable`1 changes)
   at EPiServer.Events.ChangeNotification.Implementation.ChangeNotificationManager.NotifyChanges[TChangedData](IEnumerable`1 changes)

Pretty much the same issue as this old unresolved post from 2015: https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2015/10/quotthe-event-manager-has-been-stopped.quot-duering-scheduled-job/

My initial thought was that to try to turn off activity logging, to see if that helped. But this error is maybe related to the general Events manager (like cahe notification)? 

Still, at the moment I have 694 869 rows in tblActivityLog - which I really don't need. So, Per is there an unsupported way? :)

I can be wrong here, but the ChangeNotificationManager should have nothing to do with ActivityLog. At least for Commerce, the changenotification is a persistent queue for catalog changes.

We can look into that and it would be possible to introduce an option to opt out from ChangeNotificationManager (For Catalog). 

There is a scheduled job that cleans that up eventually, features like projects will stop working so that is why we don't provide any way to disable it.

ChangeNotification is another system used by Commerce for indexing I think.

@Quan, I found this post where you are explaining ChangeNotification: http://world.episerver.com/forum/developer-forum/-EPiServer-75-CMS/Thread-Container/2014/12/what-is-changenotification-used-for/

So I understand what it is, but it seems to cause issues when running huge imports (processing 100 000 products). 

I would suspect it's something else, because we have customers imported even bigger catalogs and things have been fine.

But as I said, we will look into the option to opt out the ChangeNotification, if you don't want to use the eventual indexing.

We have made quite an effort in terms of performance and parallel processing of updates - right now the import can update 10 000 in 15 minutes. (We are using Azure Storage Queues, I am working on a blog post regarding the topic).

Could the parallell processing cause issues in terms of ChangeNotification?

Can be, I'm not sure but I think we avoid doing that because of "reasons".

It's really apple and orange but 10k products in 15 minutes seems to be low to me. I would expect 50k in a normal CatalogImportExport setup 

What about intercepting IChangeNotificationManager and just do an early exit in NotifyChanges, maybe conditionally if the changes are of type IBulkChangeItem<CatalogEntryChange> (to preserve functionality for other uses than commerce)?

That wouldn't remove the overhead of creating the IBulkChangeItem<CatalogEntryChange> instances in memory, but it would remove the overhead of actually storing them to the database.

@Quan: 50 000 items in 15 minutes items through the Episerver api? With real data?

@Magnus: Thanks, I will look into it. 

Yes, catalog.xml via CatalogImportExport, real data, on my averagely powerful desktop :) 

The ability to opt out from the eventual indexing queue (aka the ChangeNotification) will be available in an upcoming version of Commerce. Probably 11.6 or 11.5.2. 

For the record, here's how to disable it:

https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=COM-5861