You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that parallel-stream is likely to be a source of many spawned tasks, it's probably useful to add additional log points. This would help trace where tasks are coming from, which is useful when debugging systems.
Also zooming out slightly; this marks another point for why parallel-stream is useful outside of manually spawning tasks for a loop. It's unlikely that regular business logic would consistently add trace points when spawning tasks. Instead by abstracting the parallelization into a library we can do this once, and provide this for everyone.
The text was updated successfully, but these errors were encountered:
Hmm I wonder if going with tracing would be beneficial compared to the classic log fascade. One benefit definitly will be the use of scopes to structure the logs and avoid the "async mess" you end up with log not knowing where which log came from in what context/task.
Given that
parallel-stream
is likely to be a source of many spawned tasks, it's probably useful to add additional log points. This would help trace where tasks are coming from, which is useful when debugging systems.Also zooming out slightly; this marks another point for why parallel-stream is useful outside of manually spawning tasks for a loop. It's unlikely that regular business logic would consistently add trace points when spawning tasks. Instead by abstracting the parallelization into a library we can do this once, and provide this for everyone.
The text was updated successfully, but these errors were encountered: