@Override
public boolean mergeAvailabilityReport(AvailabilityReport availabilityReport) {
AvailabilityReportSerializer.getSingleton().lock(availabilityReport.getAgentName());
try {
String reportToString = availabilityReport.toString(false);
if (log.isDebugEnabled()) log.debug("Processing " + reportToString);
long start = System.currentTimeMillis();
AvailabilityManagerLocal availabilityManager = LookupUtil.getAvailabilityManager();
boolean ok = availabilityManager.mergeAvailabilityReport(availabilityReport);
long elapsed = (System.currentTimeMillis() - start);
if (elapsed > 20000L) {
log.warn(
"Performance: processed "
+ reportToString
+ " - needFull=["
+ !ok
+ "] in ("
+ elapsed
+ ")ms");
} else {
if (log.isDebugEnabled()) {
log.debug(
"Performance: processed "
+ reportToString
+ " - needFull=["
+ !ok
+ "] in ("
+ elapsed
+ ")ms");
}
}
return ok;
} catch (Exception e) {
log.info(
"Error processing availability report from ["
+ availabilityReport.getAgentName()
+ "]: "
+ ThrowableUtil.getAllMessages(e));
return true; // not sure what happened, but avoid infinite recursion during error conditions;
// do not ask for a full report
} finally {
AvailabilityReportSerializer.getSingleton().unlock(availabilityReport.getAgentName());
}
}
// @PostConstruct // when AS7-5530 is fixed, uncomment this and remove class
// StartupBeanToWorkaroundAS7_5530
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void init() throws RuntimeException {
secureNaming();
initialized = false;
log.info("All business tier deployments are complete - finishing the startup...");
// get singletons right now so we load the classes immediately into our classloader
AlertConditionCacheCoordinator.getInstance();
SessionManager.getInstance();
AlertSerializer.getSingleton();
AvailabilityReportSerializer.getSingleton();
// load resource facets cache
try {
resourceTypeManager.reloadResourceFacetsCache();
} catch (Throwable t) {
log.error("Could not load ResourceFacets cache.", t);
}
// Before starting determine the operating mode of this server and
// take any necessary initialization action. Must happen before comm startup since listeners
// may be added.
initializeServer();
// The order here is important!!!
// IF YOU WANT TO CHANGE THE ORDER YOU MUST GET THE CHANGE PEER-REVIEWED FIRST BEFORE COMMITTING
// IT!!!
//
// If we start the scheduler before the comm layer, what happens if a stored job needs to send a
// message?
// But if we start the comm layer before the scheduler, what happens if a message is received
// that needs
// a job scheduled for it? I think the former is more likely to happen than the latter
// (that is, a scheduled job would more likely need to send a message; as opposed to an incoming
// message
// causing a job to be scheduled), so that explains the ordering of the comm layer and the
// scheduler.
startHibernateStatistics();
initScheduler(); // make sure this is initialized before starting the plugin deployer
startPluginDeployer(); // make sure this is initialized before starting the server plugin
// container
startServerPluginContainer(); // before comm in case an agent wants to talk to it
installJaasModules();
startServerCommunicationServices();
startScheduler();
scheduleJobs();
// startAgentClients(); // this could be expensive if we have large number of agents so skip it
// and we'll create them lazily
// startEmbeddedAgent(); // this is obsolete - we no longer have an embedded agent
registerShutdownListener();
registerPluginDeploymentScannerJob();
logServerStartedMessage();
initialized = true;
return;
}
