Update dependency org.reactivestreams:reactive-streams-tck to v1.0.3 - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.reactivestreams:reactive-streams-tck (source)	1.0.2 -> 1.0.3

---

Release Notes

reactive-streams/reactive-streams

v1.0.3

Compare Source

Announcement:

We—the Reactive Streams community—are pleased to announce the immediate availability of Reactive Streams 1.0.3. This update to Reactive Streams brings the following improvements over 1.0.2.

Highlights:

• Specification
  • Glossary term "External synchronization" has been superseded
  • No breaking/semantical changes
  • Rule clarifications
• Interfaces
  • No changes
• Technology Compatibility Kit (TCK)
  • Improved coverage
  • Improved JavaDoc
• Examples
  • No changes
• Artifacts
  • FlowAdapters artifact removed, FlowAdapters moved into the core jar (#​424)

Specification clarifications 1.0.3

Glossary term "External synchronization" replaced by "Serial(ly)"

1.0.2: Access coordination for thread safety purposes implemented outside of the constructs defined in this specification, using techniques such as, but not limited to, atomics, monitors, or locks.

1.0.3 In the context of a Signal, non-overlapping. In the context of the JVM, calls to methods on an object are serial if and only if there is a happens-before relationship between those calls (implying also that the calls do not overlap). When the calls are performed asynchronously, coordination to establish the happens-before relationship is to be implemented using techniques such as, but not limited to, atomics, monitors, or locks.

Publisher Rule 3 (Rule and Intent clarified)

1.0.2: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled in a thread-safe manner—and if performed by multiple threads—use external synchronization.

The intent of this rule is to make it clear that external synchronization must be employed if the Publisher intends to send signals from multiple/different threads.

1.0.3: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially.

The intent of this rule is to permit the signalling of signals (including from multiple threads) if and only if a happens-before relation between each of the signals is established.

Subscriber Rule 1 (Intent clarified)

1.0.2: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.

The intent of this rule is to establish that it is the responsibility of the Subscriber to signal when, and how many, elements it is able and willing to receive.

1.0.3: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.

The intent of this rule is to establish that it is the responsibility of the Subscriber to decide when and how many elements it is able and willing to receive. To avoid signal reordering caused by reentrant Subscription methods, it is strongly RECOMMENDED for synchronous Subscriber implementations to invoke Subscription methods at the very end of any signal processing. It is RECOMMENDED that Subscribers request the upper limit of what they are able to process, as requesting only one element at a time results in an inherently inefficient "stop-and-wait" protocol.

Subscriber Rule 5 (Intent clarified)

1.0.2: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription

The intent of this rule is to prevent that two, or more, separate Publishers from thinking that they can interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled.

1.0.3: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription

The intent of this rule is to prevent that two, or more, separate Publishers from trying to interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled. Failure to conform to this rule may lead to violations of Publisher rule 1, amongst others. Such violations can lead to hard-to-diagnose bugs.

Subscriber Rule 7 (Rule and Intent clarified)

1.0.2: A Subscriber MUST ensure that all calls on its Subscription take place from the same thread or provide for respective external synchronization.

The intent of this rule is to establish that external synchronization must be added if a Subscriber will be using a Subscription concurrently by two or more threads.

1.0.3: A Subscriber MUST ensure that all calls on its Subscription's request and cancel methods are performed serially.

The intent of this rule is to permit the calling of the request and cancel methods (including from multiple threads) if and only if a happens-before relation between each of the calls is established.

TCK alterations 1.0.3

• PublisherVerification.optional_spec105_emptyStreamMustTerminateBySignallingOnComplete fails if the publisher completes synchronously (#​422)
• IdentityFlowProcessorVerification throws NPE when createFailedFlowPublisher returns null (#​425)
• required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel does not wait for request before invoking onNext (#​277)
• Subscriber whitebox verification tests demand (#​280)
• Incomplete documentation on stochastic tests in TCK (#​278)
• TCK performance (#​446)
• TCK: Receptacle#expectError timeout approach (#​451)

Contributors

• Roland Kuhn (@​rkuhn)
• Ben Christensen (@​benjchristensen)
• Viktor Klang (@​viktorklang)
• Stephane Maldini (@​smaldini)
• Stanislav Savulchik (@​savulchik)
• Konrad Malawski (@​ktoso)
• Slim Ouertani (@​ouertani)
• Martynas Mickevičius (@​2m)
• Luke Daley (@​ldaley)
• Colin Godsey (@​colinrgodsey)
• David Moten (@​davidmoten)
• Brian Topping (@​briantopping)
• Rossen Stoyanchev (@​rstoyanchev)
• Björn Hamels (@​BjornHamels)
• Jake Wharton (@​JakeWharton)
• Anthony Vanelverdinghe(@​anthonyvdotbe)
• Kazuhiro Sera (@​seratch)
• Dávid Karnok (@​akarnokd)
• Evgeniy Getman (@​egetman)
• Ángel Sanz (@​angelsanz)
• shenghaiyang (@​shenghaiyang)
• Kyle Thomson (@​kiiadi)
• (new) James Roper (@​jroper)
• (new) Oleh Dokuka (@​olegdokuka)
• (new) Scott Mitchell (@​Scottmitch)

---

---

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled due to failing status checks.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

[oryan-block]

Waiting for

• graphql-java to update its dependency
• kotlin 1.5.x version update: Update kotlin.version to v1.5.0 #516