Most stable version of EventStore server for running system projections

EventStoreDB
#1

I realise that this is a subjective and likely contentious question, but still ever relevant for our business.

We are running EventStore with system projections (no custom ones), catch up subscriptions (no persistent subscribers) and overall modest volumes, (~ 10,000 events/day). We are currently running EventStore 3.7.0 on Google Cloud with persistent (network based/durable/slow) storage and modest CPU/RAM allocations.

Overall this has been running stable and behaved as expected, but we have recently ran into what appears to be https://groups.google.com/forum/#!searchin/event-store/projections$20shutdown$20master|sort:relevance/event-store/adkT_Y_z98Y/ba2AeAglBwAJ - system projections silently stopping - which has a big knock on impact on our platform.

In people’s experience, is it worth upgrading from 3.7.0 to 3.9.x to avoid this and other stability issues? 4.0.0? We have no need for any additional features or are not performance constrained.

Cheers,

Kristian

#2

for projections 4.0 is the most stable

#3

Is there any difference between custom and system projections in this regard? Or more specifically, are system projections internally also based on JavaScript and that runtime, or are they special, written in C# directly?

#4

system projections are written in C# not js

#5

System projections are C# projections which means that they’re definitions are in C#. With Javascript projections, their definitions are extracted from JS.
There have been some fixes to how timeouts for instance are handled which might be one of the issues you are encountering where projections have paused. If you see that your projection has or appears to be paused, does it start working again when you issue a request for the projection state via the HTTP projections API?

.e.g

curl -i http://projection/{projection-name}/state -H “accept:application/json” -u “admin:changeit”

``

#6

To be more specific in my question, is there any reason to expect any difference in reliability between system and custom projections due to the way they are implemented?

This issue has come up a couple of times on development boxes, and so far once in production. For the production issue, I forcefully killed the then master instance which “unfrooze” the projection. Next time this comes up, I’ll try the curl command.

#7

I am guessing these issues are mostly resolved in 4.x there was a lot
of effort in finding/removing them as part of the release.