Merge pull request #119 from reactive-streams/wip-fix-114-√

Fixes #114 by removing the outdated test in the TCK and adding guideline...

Author: viktorklang

README.md

@@ -166,6 +166,9 @@ public interface Processor<T, R> extends Subscriber<T>, Publisher<R> {
 | <a name="4.1">1</a>      | A `Processor` represents a processing stage—which is both a `Subscriber` and a `Publisher` and MUST obey the contracts of both [1] |
 | <a name="4.2">2</a>      | A `Processor` MAY choose to recover an `onError` signal. If it chooses to do so, it MUST consider the `Subscription` canceled, otherwise it MUST propagate the `onError` signal to its Subscribers immediately |
 
+While not mandated, it can be a good idea to cancel a `Processors` upstream `Subscription` when/if its last `Subscriber` cancels their `Subscription`,
+to let the cancellation signal propagate upstream.
+
 ### Asynchronous vs Synchronous Processing ###
 
 The Reactive Streams API prescribes that all processing of elements (`onNext`) or termination signals (`onError`, `onComplete`) MUST NOT *block* the `Publisher`. However, each of the `on*` handlers can process the events synchronously or asynchronously. 

tck/src/main/java/org/reactivestreams/tck/IdentityProcessorVerification.java

@@ -426,19 +426,6 @@ public void onError(Throwable cause) {
 
   ////////////////////// OTHER RULE VERIFICATION ///////////////////////////
 
-  // A Processor
-  //   must cancel its upstream Subscription if its last downstream Subscription has been cancelled
-  @Test
-  public void mustCancelItsUpstreamSubscriptionIfItsLastDownstreamSubscriptionHasBeenCancelled() throws Exception {
-    new TestSetup(env, processorBufferSize) {{
-      final ManualSubscriber<T> sub = newSubscriber();
-      sub.cancel();
-      expectCancelling();
-
-      env.verifyNoAsyncErrors();
-    }};
-  }
-
   // A Processor
   //   must immediately pass on `onError` events received from its upstream to its downstream
   @Test