LRA Service Resilience

[Pet Mark]

I have some doubts if the LRA transaction manager solution is mature enough to implement an application in a productive ENVIRONMENT with high availability.  

I have read some old articles from 2018, and then, LRA could be a single point of failure due to the object store was included inside the service, instead to be distributed. 

We are evaluating the Redhat Fuse and the Apache Camel Saga EIP, but not sure if these are in conditions to go to the production.  

Is the LRA manager's resilience enough if the object store instance fails?, what is the resilience mechanism?, is it should valid for a production environment?

Thanks a lot in advance

[Michael Musgrove]

I'd like to see those articles from 2018 that say that LRA could be a single point of failure. Will you provide links? But do note that the LRA spec and therefore its implementation are not yet finalised. When they are we will provide documentation on the best practices for using LRA.

It is true that in the event of failure the system cannot make progress until the storage and application or "LRA coordinator" become available again but that is not a single point of failure, though I do acknowledge that availability will be compromised until the system is back up again. But this is no different from conventional transaction managers in the sense that all TMs rely on some form of persistent storage in order to recover from failures. The JTA transaction manager in the EAP product [1] is such an example and it also relies on persistent storage so in the event of a failure the application needs to be restarted.

When the LRA specification is released, the plan is to provide an implementation that runs on EAP and Quarkus. Like all EAP versions, production level support will be provided once it is out of the tech preview phase.

Until then you need to ensure that the transaction log storage is accessible. If you use a standalone coordinator then that needs access to the log storage and services need to be able to access the coordinator. If you bundle the coordinator with the application then it is your responsibility to manage the storage (for example you could do this by running your application in an app server).

[1] https://developers.redhat.com/products/eap/overview

[Michael Musgrove]

I would also like to say that all narayana transaction related projects and products build upon the same transaction engine [1]. This should give users the confidence that the code is robust and 'battle tested' over many years by many customers. The LRA implementation is a thin layer on top of that engine and although this layer is new we'd like to think it is still of high quality. But like all community projects we need community exposure and use to shake out any potential issues.

[1] https://narayana.io/arjuna-core/index.html

[Pet Mark]

Thank you very much for the answer, I understand that when they talk about a single point of failure, it may be related to what, as far as I know, it cannot be deployed in HA, is that so?, otherwise, how could the Narayana coordinator be configured in HA?

On the other hand, do you know when the final version of Narayana will be released? I know it depends on the microprofile specification, but is there some kind of estimation?

--
You received this message because you are subscribed to a topic in the Google Groups "narayana-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/narayana-users/TVKibFP5p20/unsubscribe.
To unsubscribe from this group and all its topics, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/79b302a0-ce50-4170-ac12-84429fa761c6n%40googlegroups.com.

[Michael Musgrove]

LRA asserts eventual consistency so other applications are not impacted by the delay to another service while it awaits the outcome of a long running action.

We do have an issue (JBTM-2959 and JBTM-2997) for running LRA in HA mode but that is quite low priority for a couple of reasons: firstly, restarting another server is a low cost operation on modern infrastructures such as EAP/Wildfly, kubernetes, quarkus, etc and that cost is not significant due to the long running nature of LRA transaction model.

Regarding your second question about release dates, that is a more difficult question to answer and in particular it depends upon resourcing the work. The plan is to cut another community version of narayana hopefully next week after which we will resurrect the quarkus pull request (6763) for a LRA quarkus extension. I would not like to hazard a guess as to when EAP support will be available, suffice to say that it is high on our priority list.

[Pet Mark]

Thanks so much Michael

[Mark Little]

Also worth pointing out that LRA layers on ArjunaCore which has been deployed in many production environment for over 30 years (including when it was written in C++). I don’t believe LRA is any less ready for primetime than, say, the WS-TX implementation or the JTS implementation, both of which use most of the same pieces.

Mark.

You received this message because you are subscribed to the Google Groups "narayana-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to narayana-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/narayana-users/da1a5618-6399-45f3-a0ae-5d3b2c932e74n%40googlegroups.com.

---
Mark Little
mli...@redhat.com

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)