SFS2X Docs / ExtensionsJava / old-thread-model
» SFS2X old thread model (before 2.9.x)
This article illustrates the threading model employed in earlier releases of SmartFoxServer prior to version 2.9. In version 2.9 a new architecture has been introduced which greatly simplifies the configuration and provides improved scalability. You can learn more about the new threading model here.
» Threading model
SmartFoxServer 2X runs all Extensions in a multithreaded environment. There are fundamentally two separate thread pools operating on an Extension: the ExtensionController and the EventManager. The former entity is responsible for processing client requests while the latter dispatches the server events such as USER_LOGIN, USER_DISCONNECT, etc.
Since these threads operate concurrently on the Extension code we need to make sure that access to shared state is properly synchronized. With the the help of the new Java 6 concurrent collections and locking features this should be pretty easy to implement in most cases.
The following diagram shows the basic thread architecture behind Extensions:
Network messages are routed to the server which in turn dispatches requests to the internal API (not shown in the diagram for the sake of simplicity) or to the Extension Manager. Additionally Server Events are produced and are also dispatched to the ExtensionManager.
The SFS2X API already take care of concurrency most of the times: all the calls done on the SFSApi class are thread safe and the same goes for the Game API and Buddy List API. There are however a few exceptions: SFSObject and SFSArray, for example, are not thread safe. Since these objects are mostly used for data transport, they are unlikely to be contended by multiple threads. In any case the javadoc specifies which object require extra care for thread safety.
» Tuning the thread pools
There are cases in which we might need to resize one or both thread pools when we have a powerful multicore CPU at our disposal or when the Extension code works with slow running processes such as HTTP calls or heavy database access.
The ExtensionController thread pool can be resized from the AdminTool in the Server Configurator. The EventManager is not exposed in the AdminTool yet and should be resized from code, typically in the init() method of your extension:
@Override
public void init()
{
// Resize to 5 threads
SmartFoxServer.getInstance().getEventManager().setThreadPoolSize(5);
}
- You need to fine-tune the amount of Extension Threads when dealing with many concurrent client requests that potentially could hold a thread for a long time (e.g. database query, backend http call)
- You need to fine-tune the amount of EventManager Threads when dealing with server events that could potentially hold a thread for a long time (e.g. a custom login that calls your database)
There are no set rules for fine tuning the number of threads at work, however we recommend to experiment with small increments (e.g. from 2 threads to 5 threads, then 8, etc). Threads are an expensive resource for the JVM and must be used wisely. With a little testing and a JVM monitoring tool (e.g. JConsole, VisualVM) you will be able to find the proper settings.
If you find yourself running hundreds of additional threads you probably have created a performance bottleneck in either your code or in the overall server side infrastructure (DB, HTTP servers, bandwidth, etc).