[ https://issues.jboss.org/browse/TEIID-4251?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4251: --------------------------------------- It will need to fully babysit that load - if the delegated pod goes down, then the load needs to be restarted. Very abstractly yes. Also consider that the existing logic is based upon: internal - all jgroups coordination external - jgroups coordination and atomic status table updates Both have a very weak notion of periodic invalidation - just based upon a local timer at startup, which means that if the pods come up in a disparate fashion they are all making very different time checks or if a single pod goes down in the middle of a long cycle, it will be off for a while the next time it comes up. So we'll obviously retain the status table update, but the jgroups coordination for detecting members that drop out or for all of the internal materialization coordination is effectively missing. It adds guarantees to the the load and status logic, and reduces the amount of ddl we have to generate. Keep in mind that anything that externally kicks off the load requires some sort of service account, which has some of the issues discussed on the other jira. However if it's just calling materialization procedures, then it's a lower level service account as it doesn't need to see/read everything. -- This message was sent by Atlassian Jira (v7.12.1#712002)