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 by `cppcms::application_specific_pool`
|
- You create `application_specific_pool` by calling `cppcms::create_pool<ClassType>([params])` similarly to `cppcms::applications_factory<ClassType>([params])`
|
- `create_pool` function returns `booster::shared_ptr` instead of `auto_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,i
|
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://cppcms.com/wikipp/en/page/cppcms_1_2_filtering).
|
|
|
## 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.
|
|
