There is no reason for this function, tokio already blocks automatically until all tasks are ended.
Another reason to remove this feature is `mpsc_background_tasks` unbounded channel. Recently this
channel was reporting too many unprocessed elements. We assume that this was a result of a lot of
very shot lived tasks that somehow flooded this channel.
* Use tokio runtime handle instead of TaskExecutor abstraction
Before this pr we had the `TaskExecutor` abstraction which theoretically
allowed that any futures executor could have been used. However, this
was never tested and is currently not really required. Anyone running a
node currently only used tokio and nothing else (because this was hard
coded in CLI). So, this pr removes the `TaskExecutor` abstraction and
relies directly on the tokio runtime handle.
Besides this changes, this pr also makes sure that the http and ws rpc
server use the same tokio runtime. This fixes a panic that occurred when
you drop the rpc servers inside an async function (tokio doesn't like
that a tokio runtime is dropped in the async context of another tokio
runtime).
As we don't use any custom runtime in the http rpc server anymore, this
pr also removes the `rpc-http-threads` cli argument. If external parties
complain that there aren't enough threads for the rpc server, we could
bring support for increasing the thread count of the tokio runtime.
* FMT
* Fix try runtime
* Fix integration tests and some other optimizations
* Remove warnings
* Run cargo fmt on the whole code base
* Second run
* Add CI check
* Fix compilation
* More unnecessary braces
* Handle weights
* Use --all
* Use correct attributes...
* Fix UI tests
* AHHHHHHHHH
* 🤦
* Docs
* Fix compilation
* 🤷
* Please stop
* 🤦 x 2
* More
* make rustfmt.toml consistent with polkadot
Co-authored-by: André Silva <andrerfosilva@gmail.com>
* Fix tracing tests (#8022)
* Fix tracing tests
The tests were not working properly.
1. Some test was setting a global subscriber, this could lead to racy
conditions with other tests.
2. A logging test called `process::exit` which is completly wrong.
* Update client/tracing/src/lib.rs
Co-authored-by: David <dvdplm@gmail.com>
* Review comments
Co-authored-by: David <dvdplm@gmail.com>
* Fix tracing spans are not being forwarded to spawned task (#8009)
* Fix tracing spans are not being forwarded to spawned task
There is a bug that tracing spans are not forwarded to spawned task. The
problem was that only the telemetry span was forwarded. The solution to
this is to use the tracing provided `in_current_span` to capture the
current active span and pass the telemetry span explictely. We will now
always enter the span when the future is polled. This is essentially the
same strategy as tracing is doing with its `Instrumented`, but now
extended for our use case with having multiple spans active.
* More tests
* Proper test for telemetry and prefix span
* WIP
* Fix test (need to create & enter the span at the same time)
* WIP
* Remove telemtry_span from sc_service config
* CLEANUP
* Update comment
* Incorrect indent
* More meaningful name
* Dedent
* Naming XD
* Attempt to make a more complete test
* lint
* Missing licenses
* Remove user data
* CLEANUP
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
* CLEANUP
* Apply suggestion
* Update bin/node/cli/tests/telemetry.rs
Co-authored-by: David <dvdplm@gmail.com>
* Wrapping lines
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Co-authored-by: David <dvdplm@gmail.com>
* Fix tracing spans are not being forwarded to spawned task
There is a bug that tracing spans are not forwarded to spawned task. The
problem was that only the telemetry span was forwarded. The solution to
this is to use the tracing provided `in_current_span` to capture the
current active span and pass the telemetry span explictely. We will now
always enter the span when the future is polled. This is essentially the
same strategy as tracing is doing with its `Instrumented`, but now
extended for our use case with having multiple spans active.
* More tests
* Initial commit
Forked at: 74655edebc
Parent branch: origin/master
* Move task_manager.rs to mod.rs
* Graceful shutdown for the task manager
* Await all background task JoinHandle at the same time
* Add tests
* Make future() wait also for exit signal + fix essential task failed
Probably related to https://github.com/paritytech/cumulus/issues/111
* add comments for non-obvious code
* Use clean_shutdown() in sc-cli
* Adapt code and upgrade tokio in sc-cli
* cleanup spacing in doc
* Add license
* I guess actually running the clean shutdown would be a good idea
* fix tests
* Update client/cli/src/runner.rs
Co-authored-by: Benjamin Kampmann <ben@gnunicorn.org>
* Improve error logging
* disable other tests (can't reproduce on my machine)
* Revert "disable other tests (can't reproduce on my machine)"
This reverts commit c133c590f33c253123ba0555ce719a71ededd60d.
* It is possible that the tasks are ended first
* Revert "It is possible that the tasks are ended first"
This reverts commit 502aba4a49fb5d892e704c412b8a81768a3f2c71.
* Use single threaded scheduler for more predictability
* enable_time
* Revert "enable_time"
This reverts commit 4e152140764a4bddeedff06a4e36ec701909e8c7.
* Revert "Use single threaded scheduler for more predictability"
This reverts commit ee5e13c5f13ff71e012dcda13579dffeb15f8ffc.
* Revert "Revert "It is possible that the tasks are ended first""
This reverts commit 1b91a8ca3eebbdc18be199c8ca188e88669ae649.
* This cannot be verified either with a threaded pool
* Apply suggestions from code review
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Co-authored-by: Benjamin Kampmann <ben@parity.io>
Co-authored-by: Benjamin Kampmann <ben@gnunicorn.org>
Co-authored-by: Bastian Köcher <bkchr@users.noreply.github.com>
Bastian Köcher