Daniel NicolettiBrazil, São Paulo http://dantti.wordpress.com 57 Posts
Cutelyst a Qt web framework got a new version, this version has one important fix for async apps using FastCGI or HTTP2, also fixes for SO_REUSEPORT, and as a new feature is has support for listen queue backlog on UNIX, sadly QTcpServer doesn't support both of these (I need to find time to write some patches...).
Cutelyst is available for many Linux distributions but doesn't for Debian/Kubuntu, so I'm also adding the CPack deb built will all but uWSGI support for 20.04 amd64.
When developing Qt applications be it Desktop, Mobile or Web that need to talk directly with a database the use of QtSql is usually the best choice, it has many database drivers, comes ready on their installer, but has a blocking API, which means a query will block you GUI thread.
My Cutelyst Web projects also used QtSql, and for low traffic this isn't a big issue because you are not freezing users GUI, but you are freezing the request queue instead.
One of the Cutelyst apps I developed this year has a very high traffic, and a side effect of blocking came in play, I've about 3k TVs connected via websockets, once a TV connects it does an authentication query, it takes ~17ms, now when there is an event PostgreSQL notifies the application which does some 20 other queries a little more expensive (~30ms) and send them to the TVs, this event also blocks the Cutelyst process.
Every TV does a websocket ping each 15 seconds to check if the connection is stalled, when that event happens plus some latency added 15s timeout and the TV disconnect, this of course happens with lots of TVs, so 1k TVs reconnecting will take around 17 seconds, this means new TVs disconnecting and the snow ball is done, system only recovers if I increase the DB hardware on AWS.
How can async fix this, you might be wondering, well the problem is that the 15s timeout happened to do a DOS on my own system, I can increase the value but when there are 10k TVs this will still be a problem, there are of course other ways to deal with this, but if the SQL query doesn't block the Cutelyst process it will be able to timely reply the Websocket's pongs.
ASql only supports PostgreSQL at time (PR are welcome), and depends on QtCore and libpq (PostgreSQL library), it can be used on Desktop apps and is 100% async from connection to queries, there's even a class to help with DB versioning and migration.
Check it out: https://github.com/cutelyst/asql
Cutelyst the web framework based on Qt and SimpleMail the SMTP library got another update.
The current scenario has made me a lot less productive, after all 4 kids at home all the time it's really hard to concentrate. Still many fixes and a few features have landed both.
Simple mail had issues building on Windows, and also got some docs fixes.
Cutelyst got some Session parameters available on config, an WebSocket improvement to avoid setting a null body to skip RenderView processing, and a new view called Cutelee.
This year I got a big project, one that is pushing scalability on Cutelyst further, but it also requires that things progresses faster, and this means Grantlee was starting to become an issue. A while ago it's maintainer proposed to move it's code to KDE, got my hopes high, but that got postponed to Qt6, I couldn't wait for that and I also had an years old Pull Request waiting there, making in fact Cutelyst pages less safer as an escaping code wasn't escaping one special character. A Cutelyst contributor also had patches pending there, I tried my best to avoid this, the author is a great programmer, did an awesome job but we needed something that can move a little faster.
Cutelee was born, and already have many commits, it also got some performance improvements, like not converting QDate(Time) to an string and converting back to use the :date "yy/dd" formater, another important change was that it can inject filters without the hassle of creating a Qt Plugin, putting it into the right and error prone directory hierarchy, %with% tag also supports the new Django syntax, and I hope we can keep improving it at a faster rate.
I didn't do a new release of it yet, as some installation issues raised at Grantlee weren't fixed yet on Cutelee.
Cutelyst the C++/Qt Web framework and SimpleMailQt just got new releases.
Cutelyst received many important bugfixes and if you are compiling it with View::Email it also requires SimpleMail 2, the latter got an Async API which is on production for a few months, allowing for a non-blocking send mail experience.
Check them out!
On my last post I talked about the new async simplemail-qt API that I wanted to add, yesterday I finished the work required to have that.
SMTP (Simple Mail Transfer Protocol) as the name says it's a very simple but strict protocol, you send a command and MUST wait for the reply, which is rather inefficient but it's the way it is, having it async means I don't need an extra thread (+some locking) just to send an email, no more GUI freezes or an HTTP server that is stalled.
The new Server class has a state machine that knows what reply we are waiting, and which status code is the successful one. Modern SMTP servers have PIPELING support, but it's rather different from HTTP PIPELING, because you still have to wait for several commands before you send another command, in fact it only allows you to send the FROM the RECIPIENTS email list and DATA commands at once, parse each reply and then send the mail data, if you send the email data before you are allowed by the DATA command the server will just close the connection.
So in short we only save a few (but important) round trips, this new version also includes support for the RESET command, this is useful for example when you have a long list of emails, and some of them have malformed RECIPIENTS email, you will get an error for the command but instead of closing the connections and start the long SMTP handshake you just RESET and try to send the next email.
Cutelyst master is already using this new class if you set ViewEmail::setAsync(true);. With that set you won't get the SMTP mail queued reply but will still be able to process more HTTP requests while waiting for the SMTP reply.
I plan to do a 2.0.0 stable release in the following weeks so if you use this library please test and suggest API changes that you may like.