Cluster aware services

[Fin Steenbjerg]

When working with JBoss EAP, I have often used the HA singleton service concept to get a job executed at one and only one node in the cluster (like described here: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html/development_guide/clustering_in_web_applications#clustered_ha_singleton_service). In JBoss, it also works in Openshift by using the Openshift.DNS_PING functionality. It is a simple way to make for instance a scheduler cluster aware. I can't find a similar functionality in Quarkus. Is this intentional? Does anyone have a suggestion for how to get such a functionality in Quarkus? Of course, I could implement this via a database or another shared resource, but it is not as elegant as the HA singleton service. 

[Sanne Grinovero]

Hi Fin,

that's indeed intentional, but could be revisited based on such feedback.

We brainstormed such topics in the past; as far as I remember the
consensus was that for small services which are designed to scale
up/down frequently, such levels of statefullnees as required by a
cluster don't belong in the application; especially not for
cloud-native and microservice applications. So there is for example no
support for "server stored state" for sessions either, moving the
preference to use client side state, or like you suggested to store
important state into a storage service.

An exception is local caching; since it's "just caching" there is no
need for cross-node coordination when the data access patterns don't
require eviction or read/write locked operations; so the Infinispan
2LC extension can be used to cache RDBMS operations via Hibernate ORM;
this is based on Caffeine and the recommendation is to only use it on
read-only data.

There also is support for Infinispan used as "remote cache": you run a
separate cluster to store state in an Infinispan datagrid. This is
different than a database in various ways: easier to scale, more cloud
friendly, and a focus on the Map API. Of course not a full replacement
for regular databases, but complementary to it; it similarly supports
transactions, and likely better performance, but query capabilities
are more limited. Should be a great fit for such requirements.

I remember we talked briefly about HA singletons as well; as far as I
remember the opinion for a "clean" architectural replacement would be
to run such a singleton on a dedicated service, which you'd not allow
to scale beyond 1 node. I think that's quite elegant, as either way
one node is "special" and it becomes harder to apply different rules
to such special node - with such solution you make it explicitly
different, and can possibly better tune the performance aspects
required for this different instance.

But please let us know how this works out for you. There also is the
possibility to simply run the same technology rom EAP's singletons:
while ATM we're inclined to think that's not the best choice, it would
not be too hard to port it over; in fact the code to support
Infinispan Embedded is already part of Quarkus - just not advertised
as it's in very early stages, and not meant for application
developers: this extension is meant for the DataGrid service itself to
run on Quarkus.

Thanks,
Sanne

On Fri, 18 Oct 2019 at 11:21, Fin Steenbjerg <fin.ste...@gmail.com> wrote:
>
> When working with JBoss EAP, I have often used the HA singleton service concept to get a job executed at one and only one node in the cluster (like described here: https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.2/html/development_guide/clustering_in_web_applications#clustered_ha_singleton_service). In JBoss, it also works in Openshift by using the Openshift.DNS_PING functionality. It is a simple way to make for instance a scheduler cluster aware. I can't find a similar functionality in Quarkus. Is this intentional? Does anyone have a suggestion for how to get such a functionality in Quarkus? Of course, I could implement this via a database or another shared resource, but it is not as elegant as the HA singleton service.
>

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/9bf90c66-5b08-4502-93a0-33bceb85e4c3%40googlegroups.com.

[Emmanuel Bernard]

We do have orchestration platforms like Kubernetes in mind.
In these platform it is super easy to declare that one app /
microservice should run one and only one and have the instance be
respawn in case of failure.
In that model, I would separate my app to have my singleton objects run
that way.

You can even develop the feature as part of a "bigger" microservice and
have env variable be read to know whether the instance is meant to be
the singleton owner or not.

Would that satisfy the needs you have Fin?

> https://groups.google.com/d/msgid/quarkus-dev/CAFm4XO0pSNq0aWKiqkRizX5Bv8O0Yhmph_CA5dKCtEKVMH4v_Q%40mail.gmail.com.