Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.1.x] Backports tracker from 3.2 to 3.1.6 #1111

Closed
4 tasks done
simonbasle opened this issue Mar 6, 2018 · 0 comments
Closed
4 tasks done

[3.1.x] Backports tracker from 3.2 to 3.1.6 #1111

simonbasle opened this issue Mar 6, 2018 · 0 comments
Assignees
Milestone

Comments

@simonbasle
Copy link
Contributor

simonbasle commented Mar 6, 2018

Reference this issue and the cherry-picked commit id in the commit message of each backport, like so:

This is a backport of #XXXX (commit abcd1234), as tracked in #1111

  • Avoid interrupting WorkerTask Future if cancelled race.
    This is a backport of #1108 (commit a0b752a), as tracked in #1111 ✅(e8f7867)
  • StepVerifier.withVirtualTime(...).verify() mutually exclusive
    This is a backport of #1104 (commit 1bd4968), as tracked in #1111 ✅(65e7d62)
  • NonBlocking thread check
    This is a backport of #1109 (commit 92df4ab), as tracked in #1111 ✅(5291239)
  • avoid error swallow in fromCompletionStage, onErrorDropped logs
    This is a backport of #1126 (commit 7e29da8), as tracked in #1111 ✅(97d110f)
@simonbasle simonbasle added this to the 3.1.6.RELEASE milestone Mar 6, 2018
@simonbasle simonbasle self-assigned this Mar 6, 2018
simonbasle added a commit that referenced this issue Mar 6, 2018
This commit prevents the undesirable interruption of the WorkerTask's
thread when a cancellation happens within the run() method (eg. a
MonoNext is cancelling upon first onNext downstream).

This would previously lead to a race condition between the cancellation
and the setFuture, which would interrupt if called AFTER the dispose.

This is a backport of #1108 (commit a0b752a), as tracked in #1111
simonbasle added a commit that referenced this issue Mar 7, 2018
This commit adds a lock to the StepVerifier that is only used when
virtual time is activated, resulting in the VirtualTimeScheduler
activation, publisher verification and VTS reset to be mutually
exclusive with other StepVerifier.withVirtualTime verify() invocations.

This prevent different StepVerifier from side-effecting each other, as
the StepVerifier is installed using a global hook.

This is a backport of #1104 (commit 1bd4968), as tracked in #1111
simonbasle added a commit that referenced this issue Mar 12, 2018
…uler

`block`, `blockOptional`, `blockFirst`, `blockLast`, `toIterable` and `toStream`
all check if the executing thread is NonBlocking and throw an
`IllegalStateException` if it is.

This is a backport of #1109 (commit 92df4ab), as tracked in #1111
simonbasle added a commit that referenced this issue Mar 19, 2018
This commit makes the MonoCompletionStage drop errors that are thrown
inside the future.whenComplete block (which can happen with fatal
exceptions). Additionally, the default onErrorDropped behavior also logs
the dropped error.

This results in these errors being visible in the logs, where they were
previously swallowed by CompletionFuture.whenComplete.

This is a backport of #1126 (commit 7e29da8), as tracked in #1111
simonbasle added a commit that referenced this issue Jul 18, 2022
This commit reworks the reactor-core-micrometer module in several ways:

 - made the context-propagation dependency optional
 - added `Micrometer#isContextPropagationAvailable` to detect it at
 runtime
 - also added `Micrometer#isTracingAvailable` as a bonus
 - reworked MicrometerObservationListener to check context-propagation
 is available and fallback to exclusively use Reactor Context to deal
 with Observation hierarchy:
  - read Observation from Context
  - don't open a scope, but rather start new Observation setting old one
  as parent explicitly
  - store the new Observation in the ContextView
 - when context-propagation is there, focus on Micrometer.Observation
 ContextSnapshot key using a predicate in eg. `captureUsing`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant