- Boost - lists.boost.org

Decommissioning Trac (svn.boost.org)
by Glen Fernandes 31 Jan '23

31 Jan '23

We have Trac in read-only mode after we migrated to Git, but we're still paying for the server. Do people still want to preserve any part of the content in some way? The wiki aside, there are old issues, with comments, and some of them have patches attached. Peter had the idea of generating static HTML content from Trac and hosting that on an archive section on boost.org. (I don't know how difficult this is to do). Thoughts? Suggestions? Glen

5 7

Boost TCP socket read/write issues
by Rahul K R 31 Jan '23

31 Jan '23

Hello All, As part of my project activity, I have to create an asynchronous TCP server application using the boost library. I have created a sample application and it's working. But the issue I am facing is the boost::asio::read API takes a long time to read from the TCP socket, almost 5 seconds. I am using boost library version 1.76.0. I have the following queries regarding this, 1. Is there any known issues for boost::asio::read to consume more time? 2. I am doing reading and writing to the same socket from two threads parallelly, Is that possible with the boost? 3. Is the boost lib can perform well if we get too many requests at a time and process parallelly? I am attaching the sample application code herewith. Please let me know your feedback asap. Regards Rahul

2 1

GSoC 2023 (Google Summer of Code)
by David Bellot 31 Jan '23

31 Jan '23

Hi Boost community, the GSoC 2023 organisation application is now open. Boost is again a candidate this year. We're just waiting for the results to see if we're accepted. In the meantime, we are "recruiting" mentors. Some of you already contacted me a few weeks ago, but maybe some others would be interested to join this fascinating journey. Please contact me now, by mailing list or private email if you're interested. Best, David

2 1

Building the proposed Boost.Mustache
by Peter Dimov 30 Jan '23

30 Jan '23

It's been pointed out that the proposed Boost.Mustache https://github.com/pdimov/mustache (whose formal review is upcoming) is relatively hard to evaluate, because the contents of the repository are in a form that is intended for inclusion into a Boost release. Here's how to build the library, starting from scratch: 1. Clone Boost from Github: git clone --recurse-submodules https://github.com/boostorg/boost 2. Clone the Mustache library into the Boost tree: cd boost/libs git clone https://github.com/pdimov/mustache cd .. 3. Build b2: ./bootstrap.sh (We assume Linux and g++ from now on. On Windows, it's just `booststrap`.) 4. Generate the header links in the boost/ directory: ./b2 headers 5. Build the Mustache library and its dependencies (e.g. JSON): ./b2 --with-mustache This will place the compiled libraries into the stage/lib directory. It should contain libboost_container.a/.so, libboost_json.a/.so, and liboost_mustache.a/.so. You can now build and run the Mustache examples by using e.g. g++ libs/mustache/example/html.cpp -o html -I . -L stage/lib -lboost_mustache -lboost_json ./html

1 1

aedis is ACCEPTED into boost with conditions
by Klemens Morgenstern 28 Jan '23

28 Jan '23

Boost.aedis is ACCEPTED with conditions. Accept: 3 ( + 1 late one) Conditional: 1 Reject: 4 All but one rejections asked for changes that were not fundamental to the design, but rather were about particular implementation details or high-level API design issues. Thus I conclude, based on the reviews, that there is no need for another mini-review. This is also based on Marcelo's engagement, so I am confident that many issues will be addressed in the future . These are the conditions - name it boost.redis - clearly document/specify the behaviour of async_exec, async_receive & async_run, how they interact and all the edge cases (and unit test them) - unit tests for error handling, especially for pipes. - add a design discussion & FAQ page. That should mostly copy & paste from the review discussions. - from_bulk & to_bulk should either us tag_invoke or be be renamed to aedis_from_bulk or aedis_to_bulk - remove memory_resource usage and optimize the allocation strategy of a request object (using new/delete), so that it ideally allocates once and then reuses the memory Please note that the inclusion into boost does not mean that it has to be shipped with the next release. I also strongly recommend development of typed commands, possibly with code generation. This is however not a condition and does not need to be in the first release that's included in boost. Another recommendation is to add some very basic explanation of redis, as some users will read your doc before they look into redis. I want to thank everyone who submitted reviews, especially Ruben who really drilled down on some details and brought in his experience from MySQL. Thank you Zach for getting the discussion started on type-safe command access; based on the discussions I am confident that some feature like that will be added on top of the existing APIs. Similarly I want to thank Дмитрий, Sam & Alan, who's review helped me to formulate the conditions. I am also grateful for (who I think are) first time reviewers, Mohammed Nejati, Robert Leahy, Sam Hartsfield & Miguel, and of course our boost veterans Vinnie & Christian. Likewise I want to thank Marcelo for all his responses to reviews and questions and of course for all the work that went into developing aedis. Congratulations Marcelo!

5 6

[Aedis] Formal Review: We could have done better
by Vinnie Falco 26 Jan '23

26 Jan '23

In hindsight, I feel like perhaps we collectively failed the review process. I think that Boost.Aedis was in fact not ready for a review and it did a disservice both to the library and the author that we rushed to review it. Instead, the relevant subject matter experts such as I, Alan de Freitas, Klemens Morgenstern, Reuben Perez, to a lesser extent Christian Mazakas, Mohammed, and a few others should have taken Aedis under our wing and helped to "get it into shape" before the review. Speaking for myself I wish I had put more time into helping the author get the library into the best possible condition. Instead of waiting until the review, I should have helped Marcelo address the flaws ahead of time. For example: <https://github.com/mzimbres/aedis/issues/51> and <https://github.com/mzimbres/aedis/issues/47> The library should not have gone into the review without one or more revisions to the documentation so that common questions that came up during the review were already answered, perhaps in a FAQ section. In particular, reviewers should not have had to ask why async_run or async_exec (see my example exposition in issue 51 above). I also think that the library would have benefited from a concerted effort to get it in the hands of users. I spent a bunch of energy ahead of time to get users for Beast before submitting it for review. It was already deployed in production systems, and there were other projects that started integrating it both open source and closed. We should have at the very least advertised Aedis in places like the redis++ repository (perhaps with a new GitHub issue). Forums, and such. And looked for individual C++ projects already using Redis and informed them of Aedis. For any new libraries we should look at the lesson of Aedis and consider whether or not a similar treatment would result in a better review of the candidate library. Regardless, I have the highest regard for Marcelo as he demonstrates a mastery of Asio and a commitment to quality, even if the library's outcome of the review is not favorable. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

4 6

Fwd: aedis review starts today
by Vinnie Falco 25 Jan '23

25 Jan '23

The following review came in after the review period ended. I am reposting it with permission. A copy was also sent by the reviewer to the review manager. ---------- Forwarded message --------- From: M P <miguelportilla64(a)gmail.com> Date: Wed, Jan 25, 2023 at 11:14 AM Subject: RE: [boost] aedis review starts today To: <klemensdavidmorgenstern(a)gmail.com>, Vinnie Falco <vinnie.falco(a)gmail.com> > Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. I ACCEPT this library into boost. My only concern is that although Redis may be the flavor of the day, project popularities fade. If Redis is supplanted, I wonder how effective boost maintainers down the road will be to remove it. > Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. > Additionally, stating your knowledge of redis and asio would be helpful for Me. I had no prior knowledge of Redis before reviewing Aedis, but I am familiar with Boost and Asio. Before diving into Aedis, I began by studying Redis, its RESP protocol, and real-world use to help me understand why the Aedis project might be useful to the c++ community. It quickly became apparent that Redis is very popular. It is the most popular database used on Amazon Web Services, the world’s largest cloud service provider. It is also ranked first in its category and the top ten of all categories by DB-Engines. In today’s full-stack web applications, users expect responsiveness, and Redis is an important component in scaling architecture to meet demands. Aedis grants c++ developers Redis access, empowering their software to participate in this evolving sphere of technologies. I spent about three days learning about Redis, RESP3, and Aedis. While evaluating Aedis, I built the project in Linux and Windows and performed tests using Visual Studio 2022. The project examples provide a variety of scenarios that may be useful as starting points for folks with different requirements. > - Does this library bring real benefit to C++ developers for real world use-case? Absolutely. Any c++ project with heavy utilization of Relational Databases can benefit from the cache performance Redis provides. Projects that do use a Relational Database may also be able to use Redis as a mechanism to share data across servers. There are many real-world use cases ranging from web, multi-user games, fintech, and blockchain. > - Do you have an application for this library? I do not have a software application at the moment that uses Redis. I am working on a project that might end up using Redis and if so, would likely use Aedis. > - Does the API match with current best practices? Yes, the API is well-matched with current practices. Aedis is based on Asio and it does a good job of keeping in line with it. > - Is the documentation helpful and clear? The documentation within the sources (Doxygen) is helpful. The project readme.md file can be improved. Having steps to build the project for various operating systems would be nice. Providing cmake examples to generate project solutions for Visual Studio might be a good idea. Eg. cmake -G "Visual Studio 17 2022" -A x64 -B bin64 -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake Although seemingly trivial to some, it helps reduce friction (and frustration) to newcomers and increase adoption. > - Did you try to use it? What problems or surprises did you encounter? Yes, I built the included examples and tested them with a Redis server. It may not be obvious to new users that most functions can throw an exception. Some exception messages should be elaborated. For instance, upon a failure to a server that refused a connection, the exception message was "multiple exceptions". Small nits… May want to consider renaming the function 'healthy_checker' to 'health_check'. Rename the abbreviated response variable 'resp' in the examples to `response`. `resp` can be confusing in this context considering RESP is an acronym for the communication protocol. It might be helpful to use an enumeration (or something else) for request commands. Not only would it provide type safety but it also aids in knowing the commands without having to reference them in the docs. > - What is your evaluation of the implementation? Overall I believe Aedis is well-designed and written, Marcelo has done an excellent job. Unfortunately, this library requires c++ 17 with an emphasis on c++ 20. This likely eliminates a large population of c++ users. Best, Mickey -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

aedis review period has ended
by Klemens Morgenstern 25 Jan '23

25 Jan '23

The review for aedis has concluded. I will announce the result soon. Thanks to everyone who participated in the review and discussion.

1 0

aedis review starts today
by Klemens Morgenstern 24 Jan '23

24 Jan '23

The formal review of the aedis starts today (15th) and ends next week on Tuesday (24th). The library was developed & submitted by Marcelo. Aedis ================= Aedis is a Redis client library built on top of Boost.Asio that implements the latest version of the Redis communication protocol RESP3. Some of its distinctive features are * A connection class that provides high-level functions to execute Redis commands and receive server pushes concurrently. * Automatic pipelining of commands. * Support for STL containers and serialization of user-defined data types. * Low-latency: Responses can be read in their final data-structure without creating copies. Aedis links Github: https://github.com/mzimbres/aedis Homepage: https://mzimbres.github.io/aedis/ Git tag: v1.4.1 Tarball: https://github.com/mzimbres/aedis/archive/refs/tags/v1.4.1.tar.gz Redis Links: Redis: https://redis.io/ RESP3: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Pipelines: https://redis.io/docs/manual/pipelining/ Redis commands: https://redis.io/commands/ Local Redis =========== Redis can be also easily installed on your local machine, for example, on Debian run "apt install redis". You might also want to use docker https://www.docker.com/blog/how-to-use-the-redis-docker-official-image/ Redis server for the Boost review ================================= We also have a public aedis server available for testing, please contact me or Marcelo for the details. Review ======== Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Some questions to consider: - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? Additionally, stating your knowledge of redis and asio would be helpful for me. More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html Reviews can also be submitted privately to me, and I will not disclose who sent them. I might however cite passages from those reviews in my final decision. Thanks to Marcelo for providing us with a new library & thanks for all the reviews in advance.

13 43

Fwd: Aedis review (Mohammad Nejati)
by Klemens Morgenstern 24 Jan '23

24 Jan '23

---------- Forwarded message --------- From: Mohammad Nejati [Ashtum] <ashtumashtum(a)gmail.com> Date: Tue, Jan 24, 2023 at 7:02 PM Subject: Aedis review (Mohammad Nejati) To: klemensdavidmorgenstern(a)gmail.com <klemensdavidmorgenstern(a)gmail.com> First I want to say thank you to Marcelo for the effort he put into creating such a library and improving the ecosystem around Asio. >Does this library bring real benefit to C++ developers for real world use-case? Yes, Redis is extensively used in server-side services, so having a high-quality asynchronous C++ library is a need for this type of application. >Do you have an application for this library? Yes, I work on backend services and use Redis as a key-value storage and a message broker (Redis streams) and I am in need of an asynchronous Redis library. >Does the API match with current best practices? >Did you try to use it? What problems or surprises did you encounter? Yes, I am a user of Aedis already and have used it in an application too. There are some issues that I have found in the practical usage of this library, some of them are related to the API and some of them have performance implications. The connection being reconnectable seems a design flaw: The idea behind having a reconnectable connection seems to be there to make the user's life easier (by keeping the user's request and retrying them on reconnect) but there are some issues: A network disconnect leaves the user's request in an undefined state (they might have applied on the server or not) we can't simply retry them after a reconnection it requires the user's intervention to handle a reconnect. For example, we can't simply retry an INCRBY command, it might increment the value twice. Because of the possibility of reconnecting the handshake process has to be done by users (by sending HELLO command as the first request) and on a reconnect this should be repeated again, this affected the implementation in a way it has to check for each command to see if it is a HELLO command or not. If a user is using async_receive there is no way to detect a disconnect, users have to use some form of async condition variable (which Asio doesn't have at the moment) to signal the disconnect event. On a reconnect all Redis subscriptions are dropped and again a user has a hard time signaling the async_receive part of the code to subscribe again. Because of the possibility of reconnecting, each request gets a lot of boolean config parameters to handle the reconnect scenario (cancel_on_connection_lost, cancel_if_not_connected, cancel_if_unresponded, hello_with_priority) that made the API difficult to use and understand. So if all these efforts have a limited use case (implicitly retrying the requests that are read-only or do not matter if executed twice) I think a user can handle this scenario with a custom wrapper type would be better instead of making the whole connection reconnectable. There are a lot of rescheduling for reading a single push event (performance issue): At the moment the demultiplexing of Redis events seems to happen with a strategy https://github.com/mzimbres/aedis/blob/master/include/aedis/detail/guarded_… The problem is that for reading each event message around 4 rescheduling on executor happens (it might be less or more than 4 it is hard to be sure from the code) and that has degraded the performance of reading push events (rescheduling on Asio executors is not a cheap operation). There is no possibility of reading push events in batches (performance issue): Redis pub/sub receives its messages as push events and because it is a way of broadcasting messages it is sometimes used at rates like 50,000 messages per second, with the current API there is no possibility for reading these messages in batches which made the reading operation very costly. Creating an Asio timer for each request (performance issue): Currently, Aedis creates an Asio timer for each request in the queue to act as an async condition variable, but it seems it can be eliminated if the exec_op is converted into a polymorphic type which can be resumed externally, after this change would a need for an Asio service too, to destroy paused operation on a service shutdown. >Is the documentation helpful and clear? I find them very clear and well written but it would be nicer to have more examples of real-world usages of Redis, I see documentation links to the example directory for examples. It would be nice if add a couple of them to the document and explain what is going on. There is no example of how we should use this library to work with Redis streams. The echo server benchmark doesn't carry any information and is misleading in my opinion, if there is some benchmark it should be a practical usage example. >Please indicate the time & effort spent on the evaluation and give the reasons for your decision. Because I had some previous experience with this library I think in total it should be around 4 days of debugging and evaluation. >Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost I think this library needs to see more practical usage to find its shape in terms of the quality of implementation and the quality of the provided user interface. There are various modes we can use Redis (key-value storage, message broker, pub/sub) and each one can reveal shortages in the performance or API. At this stage, I think it is too early for inclusion in the boost.

2 1