Fixing space.

Check for an isEmpty was added.

In D4740#140197, @tomek wrote:

So there are a lot of potential issues with detaching, and it doesn't seem necessary at this point. @max could you try to find a solution where detach isn't used?

In D4740#140130, @karol wrote:

Yet one more reason why I'd avoid detach here: https://stackoverflow.com/a/54207121/15854120

Long story short, accessing external resources from the detached thread causes undefined behavior. And here, in connect(), we use fields like: this->lastConnectionTimestamp, this->lastConnectionTimestamp (EDIT: Ok, sorry I missed the "static storage" thing, but still it brings a danger to the house).

In D4805#141290, @varun wrote:

I think max is planning some changes to this diff so i'm pushing it back to his queue

In D4805#141119, @jon wrote:

that being said, it's hard to use install(EXPORT when using add_subdirectory. Essentially someone would need to do cmake .. && make install. And then they would be able to use the install(EXPORT contents.

I'm okay with doing add_library(${namespace}::${_LIB_PATH_STEM} ALIAS ${_LIB_PATH_STEM}-total), I just don't think it's canonical. I believe https://cmake.org/cmake/help/latest/command/export.html#targets is the correct thing to use.
I just have no idea how to actually use the exported file, as it's not generated until after cmake configure.

Rebased on parent D4805 changes.

Removing of detect_cargo_target_architecture.
Check for an empty Rust_CARGO_TARGET was added.

Add flag_if_supported("-std=c++17") and rebased on a changes.

In D4861#140927, @karol wrote:

Ok, once your diff is landed, I'm going to rebase to it and take your version removing mine, no problem. How about the rest of this diff?

This might be hard for the docker environment as cmake_path is a very recent addition.

• Changes to use get_filename_component instead of cmake_path to support current CMake version.
• Fixing cmake-lint errors.
• Docstring were added to the function declarations.

In D4805#140773, @jon wrote:

It could be even easier using of the cmake_path function. We can remove this function completely in a favor of using just one line command.

This might be hard for the docker environment as cmake_path is a very recent addition.

Variable names should be fixed according to our new CMake Lint to address errors but seems this doesn't block the review.

Adding @jon and @varun as blocking reviewers, because of this cmake file can be used in all services.

Removing of _get_stem_name_of_path function in a favor of just use of cmake_path.

Please take a look at D4805, the diff is to add corrosion_cxx.cmake with the modifications for our needs instead of just copy pasting the rusty_cmake cmake file:

• Windows-related code was removed.
• Automatically detect Rust target architecture using detect_cargo_target_architecture function.
• Unnecessary comments were removed.

This diff shouldn't depend on D4859 and D4858. Seems that it's independent and the Tunnelbroker is successfully built without the parent diffs.

Joining message sending threads at the end of the test execution.

Remove threads joining.

In D4842#139958, @jon wrote:

What problem does this solve?

Keyserver build error is not related to these changes.

Thanks, @tomek, and @karol for the comments! I'll try to describe this case further...

Requesting review for @tomek comments.

Rebase on parent changes.

Remove old corrosion integration.

Changes to use log->error and info. Fix indentation.

In D4740#137928, @tomek wrote:

I've seen @karol had some comments about detach in another diff, so adding him as blocking.
Other than that, it looks like the code is now a lot safer. As you noticed, the reason behind my comment was to protect against initialization not being safe and not the usage of the manager itself.

According to the description of this diff (this is a follow-up for the current using approach):

Creating init() function following the existing approach that AWS-CPP client already uses. We are callinginit() to initialize AWS thread/client.

I don't think that following all the approaches is a good idea - we need to be sure that other approaches aren't better. In this case, is there anything wrong with moving this logic to the constructor? Doing that would simplify this significantly, as exactly once semantic would be basically free.

In D4767#138735, @tomek wrote:

This degrades performance but in a stress test, in D4768 it shows that we have enough throughput of nearly 2000 messages per second during send/receive in this blocking model.

the current performance looks ok for our needs at the moment.

What is the estimate for the throughput we should be able to handle?

Updating with the CXX instead of unsafe.

I've removed the local protoc using the homebrew uninstall protobuf and it works as expected. Seems that this is related to the ENG-1590 issue and interference with the locally installed dev tools and not related to this certain diff.

I got a protoc version mismatch when building services in a nix develop when testing this diff:

nix develop
cd services/backup
rm -dfr build
cmake -B build . && make -C build -j4

The errors are:

make[2]: Leaving directory '/Users/max/GitHub/comm/services/backup/build'
make[2]: Entering directory '/Users/max/GitHub/comm/services/backup/build'
make[2]: Leaving directory '/Users/max/GitHub/comm/services/backup/build'
make[2]: Entering directory '/Users/max/GitHub/comm/services/backup/build'
[ 20%] Building CXX object protos/CMakeFiles/comm-backup-grpc.dir/backup.pb.cc.o
[ 24%] Building CXX object protos/CMakeFiles/comm-blob-grpc.dir/blob.pb.cc.o
In file included from /Users/max/GitHub/comm/services/backup/build/protos/backup.pb.cc:4:
/Users/max/GitHub/comm/services/backup/build/protos/backup.pb.h:17:2: error: This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
 ^
/Users/max/GitHub/comm/services/backup/build/protos/backup.pb.h:18:2: error: incompatible with your Protocol Buffer headers. Please
#error incompatible with your Protocol Buffer headers. Please
 ^

Remove all logs with the userID, deviceID or sessionID.

Seems that this should be fixed from the tunnelbroker side to run it in a nix:

Unfortunately, the logic for finding the tunnelbroker.ini file still
assumes docker-only paths

I have created a task for it as ENG-1589.

In D4789#138353, @atul wrote:

Going to abandon this, it didn't have the effect on build times that I thought it would.

In D4769#138340, @ashoat wrote:

Any time we are printing something like deviceID, we should be EXTREMELY careful not to enable that in production. I'd be more comfortable if we simply did not have log statements that print things like deviceID and userID in checked-in code.

In D4769#138306, @tomek wrote:

I was thinking about this too, but to use debug we should rebuild the server from production mode.

It would be great if we could change the log level while the server is running, but that has some disadvantages. But having to rebuild in order to change log level sounds like a mistake and we should be able to do that - can we start supporting it?

Change to curly braces initialization.

In D4767#138286, @tomek wrote:

This diff introduces the use of C++17 std::scoped_lock

Does our compilation process support C++17?

In D4767#138282, @tomek wrote:

I'm slightly confused now. After this diff we can access the amqpChannel only from a single thread at a time. Is it going to degrade the performance? If the channel has to be accessed only from a single thread, maybe we should make it thread local and have an instance for each thread?

That's awesome! Thanks, @jon 🥳
Finally, I don't need to rebase my fork to get an instant build and IDE support ))

Raising this diff because D4751 was created as a duplicate and we need to fix this in a Tunnelbroker to run the tests from the CI.
We already have the same lines in a backup and blob Docker files. It's tested and works as expected.
This is an old diff and from that time @ashoat needs to be removed from reviewers and I think @tomek should be as blocking or I can commandeer this diff.