nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Alfresco Enterprise (One/Content Services) vs Alfresco Community (HA)

liviu_ioan

Hello,

I would like to understand more about the technical differences on Enterprise vs Community.
I was not able to find any good (deep) resources on the subject.
(you can actually give me pointers in the Alfresco Enterprise code/components)

I am interested in a high availability (HA) context (2 Alfresco nodes).
A small number of users can be connected at the same time (< 10).
Less than 25 000 documents are inserted in Alfresco per day (usually, way less than 10 000 are deposited every day)
The scenario is well depicted here:
https://docs.alfresco.com/5.2/concepts/cluster-scenario-redundancy.html

My understand is the following:
the 2 Alfresco nodes share the same database
the needed Solr nodes operate in cluster mode
When Alfresco starts, it simply interrogates the database and Solr for the info needed.

Question: why can't I use Alfresco Community for the above HA scenario?
What is missing in Alfresco Community?

Thank you.
Regards,
Liviu

Find more posts tagged with

Alfresco Content Services

Accepted answers

afaust

Feature differences between Alfresco Community and Enterprise should be easy to find, either in the documentation or in the wider community, i.e. in an older comparison provided by Contentreich. Alfresco rarely provides low-level technical documentation beyond APIs, so if you are looking for technical details you'd have to get yourself familiar with the codebase a bit. Generally speaking, the technical differences are quite limited. Enterprise re-uses 100% Community code and only adds a handful of JARs that deal with clustering, JMX management, automatic shard registration, user license handling etc.

The reason you cannot (reliably) run two Community instances in such a scenario has to do with non-persistent data that cannot be communicated or kept in-sync between the two nodes in Community Edition. Such data includes ephemeral state such as short-lived locks, authentication tickets and some other bits only held by in-memory caches and not stored in the database. Additionally, some functional components store intermediary data structures in caches that have been derived from DB data - without inter-node communication of an active cluster, these structures run the risk of inconsistency when the DB is changed by an interaction with one of the nodes.

The key thing that is missing in Community Edition is a distributed caching and messaging layer. The core code shared between Community and Enterprise defines the common interface(s) of the layer, but only Enterprise contains a specific implementation that deals with distributed caching / messaging using Hazelcast as the library.

It is not impossible to add such functionality to Community Edition since the interfaces are public (I have done so in a proprietary module), but it certainly is not trival.

All comments

afaust

It is not impossible to add such functionality to Community Edition since the interfaces are public (I have done so in a proprietary module), but it certainly is not trival.

liviu_ioan

Thank you for your detailed reply, Axel!

I think I get the big picture (I know what locks & caches are).

One more question, to make sure I get a better understanding: could you give some basic, practical examples of what could go (terribly) wrong when using a LB, 2 Alfresco Community nodes, 1 database cluster and 1 solr cluster?

afaust

Well, imagine your users are using the Edit Online feature via AOS. One user (temporarily) locks a document for edit on server A, a second user tries to open that document and his request goes to server B. That server does not know about the lock and voila, you run into potential update conflicts where one user may override another users changes. (temporary locks are not stored in the DB)

If you configure a new data model via the Content Model Manager feature on server A, server B will not be aware of that since the initialised dictionary state is actually stored in a runtime cache, and there is no option to have it always "read-through" (that would be prohibitively expensive). As a result, users would not be able to access certain folders / documents on one server and SOLR would not be able to index new elements of that model.

There are various other effects, but I hope this should suffice...

liviu_ioan

OK, Axel. Again, thanks.

Yes, updating models on one node is a bad idea, if nodes are not clustered.

But what about if objects are not editable? Are there any concerns in this context? (only upload & read operations permitted)