Solved: High Availability Extensions

rattmice · ‎Jun 24, 2022

Can someone explain when an extension may not be compatible in an active-active cluster? I see the haCompatible attribute documented in the Help Center but there is no guidance as to when that should be set to true or false.

I have a legacy extension from the defunct Market Place and several home-grown custom extensions and need to determine if they are compatible in high availability mode but I don't know how to make that determination. Would an example of one that wouldn't be compatible do something like keeping a local state or cache of data and that information would be lost if a different node handles the request?

I want to just add haCompatible="true" and repackage the extension but I don't know if that is advisable or not.

VladimirRosu · ‎Jun 27, 2022

All extensions that are widgets, will be compatible, since they are runtime only.

However, this differs in the case of Java extensions. There are some aspects:

1. The extensions that use lifecycle methods, like "initializeThing", "stopThing", starting ThingWorx 9.0, have an additional parameter, called ContextType. First, if you have any extension that's using these lifecycle methods, then you'd need to modify the source code to include this input parameter. That's the easiest way to check if any of your extensions need a re-work. If you don't recompile with 9.0 SDK, then those methods won't execute, since the signature differs. Now, you might not use those methods at all, but if you're using a "client" sort of Thing Template (that connects to a server), you'd need to think what is the behavior you want to have if you have two servers, that run the same lifecycle method - do you want both of them to connect to the server, or you want just one? the ContextType allows you to manage this situation. More details here. I believe the details you asked about are present in that webpage.

2. If you have Java extensions that don't use these, like Resources, then you basically don't care.

3. The haCompatible = true is not linked to point 1 above. You can set it to true, with no change in source code, and can still have extensions whose lifecycle methods won't execute and won't be effectively HA compatible.

View solution in original post

VladimirRosu · ‎Jun 27, 2022

All extensions that are widgets, will be compatible, since they are runtime only.

However, this differs in the case of Java extensions. There are some aspects:

1. The extensions that use lifecycle methods, like "initializeThing", "stopThing", starting ThingWorx 9.0, have an additional parameter, called ContextType. First, if you have any extension that's using these lifecycle methods, then you'd need to modify the source code to include this input parameter. That's the easiest way to check if any of your extensions need a re-work. If you don't recompile with 9.0 SDK, then those methods won't execute, since the signature differs. Now, you might not use those methods at all, but if you're using a "client" sort of Thing Template (that connects to a server), you'd need to think what is the behavior you want to have if you have two servers, that run the same lifecycle method - do you want both of them to connect to the server, or you want just one? the ContextType allows you to manage this situation. More details here. I believe the details you asked about are present in that webpage.

2. If you have Java extensions that don't use these, like Resources, then you basically don't care.

3. The haCompatible = true is not linked to point 1 above. You can set it to true, with no change in source code, and can still have extensions whose lifecycle methods won't execute and won't be effectively HA compatible.