New Applications Pool API in 1.2
CppCMS 1.1 introduced a new API for cppcms::applications_pool
Why New API
CppCMS 1.0 API had some design issues
- It didn't allow unmounting of applications - once it is mounted we transfer ownership on the factory object.
- Ownership of asynchronous application was unclear.
- Installing asynchronous application directly does not allow increasing number of event loops transparently in future.
- Synchronous applications created in the event loop and if their generation is costly it may slow down entire system.
Also new API was introduced and old one is considered deprecated it is fully supported and works well. So no need to run and change all your code meanwhile
Another issue that exists in CppCMS 1.0 is that applications pool can generate much more applications that actually are in use.
All synchronous applications are created in the event loop when the request is ready and then transferred to thread pool for execution. It can create a situation where we have 5 threads with applications doing some hard job and accepted 20 more connections and created applications for them just to wait in the thread pool queue for execution.
This issue was fixed for old API as well. There will be no more synchronous applications than the number of threads
New API
In the nutshell:
cppcms::applications_pool::factory
is replaced bycppcms::application_specific_pool
- You create
application_specific_pool
by callingcppcms::create_pool<ClassType>([params])
similarly tocppcms::applications_factory<ClassType>([params])
create_pool
function returnsbooster::shared_ptr
instead ofauto_ptr
allowing to keep the reference to the pool.- synchronous and asynchronous mode specified by flags to
applications_pool::mount
- It is possible to provide multiple options for pool management
- It is possible to unmount a pool
Mount policy
Basic API for mounting an application is
void mount(booster::shared_ptr<cppcms::application_specific_pool> pool, cppcms::mount_point const &point, int flags = 0);
- First parameter is pool created by
create_pool
function - Second is mount point
Up to this it is quite similar to old API, what is different is flags option.
You can provide following flags that placed in namespace cppcms::app
:
Mode Flags:
cppcms::app::synchronous
- create simple synchronous application - the default. Note: applications will be created already in thread pool and not like in the old API in the event loop thread.cppcms::app::asynchronous
- create asynchronous application. Note: unlike the old API it will be generated in the same way like synchronous one, allowing extension of the model for multiple event loop in future.
Options:
cppcms::app::prepopulated
- create all application instances from the beginning - before the service runs - can save some latency if generation is heavy. Can be used with both asynchronous and synchronous applications.cppcms::app::thread_specific
- create synchronous application thread specific - so each application would live and die in the same thread rather than fetched from and returned to a pool.cppcms::app::content_filter
- create special filtering asynchronous application that handles incoming content.
HTTP Context Transfer
Now it is also possible to "send" existing connection from one pool/application to another one. Allowing more dynamic relations between the applications.
cppcms::http::context
has two new following member functions:
void submit_to_pool(booster::shared_ptr<application_specific_pool> pool,std::string const &url); void submit_to_asynchronous_application(booster::intrusive_ptr<application> app,std::string const &url);
You can transfer a connection from for example filtering asynchronous application to synchronous one or/and send back some request to asynchronous handling as well.