Backup the service-chatserver.xml file in the chatserver directory, then execute ant again to generate a new service-chatserver.xml for the comparison.

From the comparison result, we could find that the release version has two extras attributes of the Provider element.

className="chat.chatserver.SessionManager"
classSingleton="getInstance"

It is the initial entrance. Actually, the SessionManager inherits from the ProviderListener, which means a ProviderListener object should be provided for the Provider interaction through getInstance to obtain a singleton. If there is no this attribute, the system obtains it through new chat.chatserver.SessionManager().

In general, when implementing the own service, the ProviderListener must be implemented, then modify the configure file.

SessionManager.java:

private void openListen() {
	try {
		manager.openListen();
	} catch (IOException e) {
		if (Trace.isErrorEnabled())
			Trace.error("SessionManager.openListen", e);
		getManager().close();
	}
}
public void onManagerInitialized(Manager manager, Config config) {
	this.manager = (ServerManager) manager;
	......................
	if (table.Hallnamecache.get().getCacheSize() == 0)
		GlobalId.runOnValidation(() -> {
			insertDefaultChatrooms();
			openListen();
		});	
	else {
		setViewHallsFromCache();
		openListen();
	}
}

After the internal initialization of the system finishes, the onManagerInitialized method is called firstly to inform the Provider to execute the initialization. The initialization has two steps: first prepare the necessary resource for the Provider, then through calling openListen inform the switcher server that the Provider is ready and allow the user to connect.

The Provider has two ways to prepare the resource here: the setViewHallsFromCache loads the chatroom configuration information when the chatroom exists in the database, and creates the default chatroom if the chatroom does not exist. Because creating the chatroom depends on the GlobalId server to maintain the name, the creation of the default chatroom must be successful. So GlobalId.runOnValidation is called to submit a task to guarantee that it is executed after the GlobalId server connects successfully.

It should be noted that the task submitted by the GlobalId.runOnValidation is executed in the application thread pool of the Engine. If the GlobalId.Exception is thrown because of the failure from the GlobalId server when executing, such as the connection disconnection, the re-schedule issue should be considered.

To use the GlobalId service, the correct configuration is below:

service-chatserver.xml:

<GlobalId autoReconnect="true" remoteIp="127.0.0.1" remotePort="10210"/>

SessionManager.java:

public void onManagerUninitialized(Manager manager) {
}

This method is called when the Provider service stops to release the resource allocated by Provider.

SessionManager.java:

public void onTransportAdded(Transport transport) throws Exception {
	if (Trace.isInfoEnabled())
		Trace.info("onTransportAdded " + transport);
}

The user login and this method is called after the initialization of the View resource related to the user finishes.

SessionManager.java:

public void onTransportRemoved(Transport transport) throws Exception {
	if (Trace.isInfoEnabled())
		Trace.info("onTransportRemoved " + transport);
}

The user leaves and this method is called after the reclaim of the View resource related to the user finishes.

SessionManager.java:

public void onTransportDuplicate(Transport transport) throws Exception {
	if (Trace.isInfoEnabled())
		Trace.info("onTransportDuplicate " + transport);
	manager.close(transport);
}

This method reports the issue that user re-login and give a chance to deal with the re-login issue. The transport parameter here is the transport of the previous session. When throwing the exception or closing this transport, the previous session is kicked off and the next session could login. If this method does nothing, the next session is blocked and the re-login is forbidden.