001/************************************************************************ 002* Licensed under Public Domain (CC0) * 003* * 004* To the extent possible under law, the person who associated CC0 with * 005* this code has waived all copyright and related or neighboring * 006* rights to this code. * 007* * 008* You should have received a copy of the CC0 legalcode along with this * 009* work. If not, see <http://creativecommons.org/publicdomain/zero/1.0/>.* 010************************************************************************/ 011 012package org.reactivestreams.example.unicast; 013 014import org.reactivestreams.Publisher; 015import org.reactivestreams.Subscriber; 016import org.reactivestreams.Subscription; 017 018import java.util.Iterator; 019import java.util.Collections; 020import java.util.concurrent.Executor; 021import java.util.concurrent.atomic.AtomicBoolean; 022import java.util.concurrent.ConcurrentLinkedQueue; 023 024/** 025 * AsyncIterablePublisher is an implementation of Reactive Streams `Publisher` 026 * which executes asynchronously, using a provided `Executor` and produces elements 027 * from a given `Iterable` in a "unicast" configuration to its `Subscribers`. 028 * 029 * NOTE: The code below uses a lot of try-catches to show the reader where exceptions can be expected, and where they are forbidden. 030 */ 031public class AsyncIterablePublisher<T> implements Publisher<T> { 032 private final static int DEFAULT_BATCHSIZE = 1024; 033 034 private final Iterable<T> elements; // This is our data source / generator 035 private final Executor executor; // This is our thread pool, which will make sure that our Publisher runs asynchronously to its Subscribers 036 private final int batchSize; // In general, if one uses an `Executor`, one should be nice nad not hog a thread for too long, this is the cap for that, in elements 037 038 public AsyncIterablePublisher(final Iterable<T> elements, final Executor executor) { 039 this(elements, DEFAULT_BATCHSIZE, executor); 040 } 041 042 public AsyncIterablePublisher(final Iterable<T> elements, final int batchSize, final Executor executor) { 043 if (elements == null) throw null; 044 if (executor == null) throw null; 045 if (batchSize < 1) throw new IllegalArgumentException("batchSize must be greater than zero!"); 046 this.elements = elements; 047 this.executor = executor; 048 this.batchSize = batchSize; 049 } 050 051 @Override 052 public void subscribe(final Subscriber<? super T> s) { 053 // As per rule 1.11, we have decided to support multiple subscribers in a unicast configuration 054 // for this `Publisher` implementation. 055 // As per 2.13, this method must return normally (i.e. not throw) 056 new SubscriptionImpl(s).init(); 057 } 058 059 // These represent the protocol of the `AsyncIterablePublishers` SubscriptionImpls 060 static interface Signal {}; 061 enum Cancel implements Signal { Instance; }; 062 enum Subscribe implements Signal { Instance; }; 063 enum Send implements Signal { Instance; }; 064 static final class Request implements Signal { 065 final long n; 066 Request(final long n) { 067 this.n = n; 068 } 069 }; 070 071 // This is our implementation of the Reactive Streams `Subscription`, 072 // which represents the association between a `Publisher` and a `Subscriber`. 073 final class SubscriptionImpl implements Subscription, Runnable { 074 final Subscriber<? super T> subscriber; // We need a reference to the `Subscriber` so we can talk to it 075 private boolean cancelled = false; // This flag will track whether this `Subscription` is to be considered cancelled or not 076 private long demand = 0; // Here we track the current demand, i.e. what has been requested but not yet delivered 077 private Iterator<T> iterator; // This is our cursor into the data stream, which we will send to the `Subscriber` 078 079 SubscriptionImpl(final Subscriber<? super T> subscriber) { 080 // As per rule 1.09, we need to throw a `java.lang.NullPointerException` if the `Subscriber` is `null` 081 if (subscriber == null) throw null; 082 this.subscriber = subscriber; 083 } 084 085 // This `ConcurrentLinkedQueue` will track signals that are sent to this `Subscription`, like `request` and `cancel` 086 private final ConcurrentLinkedQueue<Signal> inboundSignals = new ConcurrentLinkedQueue<Signal>(); 087 088 // We are using this `AtomicBoolean` to make sure that this `Subscription` doesn't run concurrently with itself, 089 // which would violate rule 1.3 among others (no concurrent notifications). 090 private final AtomicBoolean on = new AtomicBoolean(false); 091 092 // This method will register inbound demand from our `Subscriber` and validate it against rule 3.9 and rule 3.17 093 private void doRequest(final long n) { 094 if (n < 1) 095 terminateDueTo(new IllegalArgumentException(subscriber + " violated the Reactive Streams rule 3.9 by requesting a non-positive number of elements.")); 096 else if (demand + n < 1) { 097 // As governed by rule 3.17, when demand overflows `Long.MAX_VALUE` we treat the signalled demand as "effectively unbounded" 098 demand = Long.MAX_VALUE; // Here we protect from the overflow and treat it as "effectively unbounded" 099 doSend(); // Then we proceed with sending data downstream 100 } else { 101 demand += n; // Here we record the downstream demand 102 doSend(); // Then we can proceed with sending data downstream 103 } 104 } 105 106 // This handles cancellation requests, and is idempotent, thread-safe and not synchronously performing heavy computations as specified in rule 3.5 107 private void doCancel() { 108 cancelled = true; 109 } 110 111 // Instead of executing `subscriber.onSubscribe` synchronously from within `Publisher.subscribe` 112 // we execute it asynchronously, this is to avoid executing the user code (`Iterable.iterator`) on the calling thread. 113 // It also makes it easier to follow rule 1.9 114 private void doSubscribe() { 115 try { 116 iterator = elements.iterator(); 117 if (iterator == null) 118 iterator = Collections.<T>emptyList().iterator(); // So we can assume that `iterator` is never null 119 } catch(final Throwable t) { 120 subscriber.onSubscribe(new Subscription() { // We need to make sure we signal onSubscribe before onError, obeying rule 1.9 121 @Override public void cancel() {} 122 @Override public void request(long n) {} 123 }); 124 terminateDueTo(t); // Here we send onError, obeying rule 1.09 125 } 126 127 if (!cancelled) { 128 // Deal with setting up the subscription with the subscriber 129 try { 130 subscriber.onSubscribe(this); 131 } catch(final Throwable t) { // Due diligence to obey 2.13 132 terminateDueTo(new IllegalStateException(subscriber + " violated the Reactive Streams rule 2.13 by throwing an exception from onSubscribe.", t)); 133 } 134 135 // Deal with already complete iterators promptly 136 boolean hasElements = false; 137 try { 138 hasElements = iterator.hasNext(); 139 } catch(final Throwable t) { 140 terminateDueTo(t); // If hasNext throws, there's something wrong and we need to signal onError as per 1.2, 1.4, 141 } 142 143 // If we don't have anything to deliver, we're already done, so lets do the right thing and 144 // not wait for demand to deliver `onComplete` as per rule 1.2 and 1.3 145 if (!hasElements) { 146 try { 147 doCancel(); // Rule 1.6 says we need to consider the `Subscription` cancelled when `onComplete` is signalled 148 subscriber.onComplete(); 149 } catch(final Throwable t) { // As per rule 2.13, `onComplete` is not allowed to throw exceptions, so we do what we can, and log this. 150 (new IllegalStateException(subscriber + " violated the Reactive Streams rule 2.13 by throwing an exception from onComplete.", t)).printStackTrace(System.err); 151 } 152 } 153 } 154 } 155 156 // This is our behavior for producing elements downstream 157 private void doSend() { 158 try { 159 // In order to play nice with the `Executor` we will only send at-most `batchSize` before 160 // rescheduing ourselves and relinquishing the current thread. 161 int leftInBatch = batchSize; 162 do { 163 T next; 164 boolean hasNext; 165 try { 166 next = iterator.next(); // We have already checked `hasNext` when subscribing, so we can fall back to testing -after- `next` is called. 167 hasNext = iterator.hasNext(); // Need to keep track of End-of-Stream 168 } catch (final Throwable t) { 169 terminateDueTo(t); // If `next` or `hasNext` throws (they can, since it is user-provided), we need to treat the stream as errored as per rule 1.4 170 return; 171 } 172 subscriber.onNext(next); // Then we signal the next element downstream to the `Subscriber` 173 if (!hasNext) { // If we are at End-of-Stream 174 doCancel(); // We need to consider this `Subscription` as cancelled as per rule 1.6 175 subscriber.onComplete(); // Then we signal `onComplete` as per rule 1.2 and 1.5 176 } 177 } while (!cancelled // This makes sure that rule 1.8 is upheld, i.e. we need to stop signalling "eventually" 178 && --leftInBatch > 0 // This makes sure that we only send `batchSize` number of elements in one go (so we can yield to other Runnables) 179 && --demand > 0); // This makes sure that rule 1.1 is upheld (sending more than was demanded) 180 181 if (!cancelled && demand > 0) // If the `Subscription` is still alive and well, and we have demand to satisfy, we signal ourselves to send more data 182 signal(Send.Instance); 183 } catch(final Throwable t) { 184 // We can only get here if `onNext` or `onComplete` threw, and they are not allowed to according to 2.13, so we can only cancel and log here. 185 doCancel(); // Make sure that we are cancelled, since we cannot do anything else since the `Subscriber` is faulty. 186 (new IllegalStateException(subscriber + " violated the Reactive Streams rule 2.13 by throwing an exception from onNext or onComplete.", t)).printStackTrace(System.err); 187 } 188 } 189 190 // This is a helper method to ensure that we always `cancel` when we signal `onError` as per rule 1.6 191 private void terminateDueTo(final Throwable t) { 192 cancelled = true; // When we signal onError, the subscription must be considered as cancelled, as per rule 1.6 193 try { 194 subscriber.onError(t); // Then we signal the error downstream, to the `Subscriber` 195 } catch(final Throwable t2) { // If `onError` throws an exception, this is a spec violation according to rule 1.9, and all we can do is to log it. 196 (new IllegalStateException(subscriber + " violated the Reactive Streams rule 2.13 by throwing an exception from onError.", t2)).printStackTrace(System.err); 197 } 198 } 199 200 // What `signal` does is that it sends signals to the `Subscription` asynchronously 201 private void signal(final Signal signal) { 202 if (inboundSignals.offer(signal)) // No need to null-check here as ConcurrentLinkedQueue does this for us 203 tryScheduleToExecute(); // Then we try to schedule it for execution, if it isn't already 204 } 205 206 // This is the main "event loop" if you so will 207 @Override public final void run() { 208 if(on.get()) { // establishes a happens-before relationship with the end of the previous run 209 try { 210 final Signal s = inboundSignals.poll(); // We take a signal off the queue 211 if (!cancelled) { // to make sure that we follow rule 1.8, 3.6 and 3.7 212 213 // Below we simply unpack the `Signal`s and invoke the corresponding methods 214 if (s instanceof Request) 215 doRequest(((Request)s).n); 216 else if (s == Send.Instance) 217 doSend(); 218 else if (s == Cancel.Instance) 219 doCancel(); 220 else if (s == Subscribe.Instance) 221 doSubscribe(); 222 } 223 } finally { 224 on.set(false); // establishes a happens-before relationship with the beginning of the next run 225 if(!inboundSignals.isEmpty()) // If we still have signals to process 226 tryScheduleToExecute(); // Then we try to schedule ourselves to execute again 227 } 228 } 229 } 230 231 // This method makes sure that this `Subscription` is only running on one Thread at a time, 232 // this is important to make sure that we follow rule 1.3 233 private final void tryScheduleToExecute() { 234 if(on.compareAndSet(false, true)) { 235 try { 236 executor.execute(this); 237 } catch(Throwable t) { // If we can't run on the `Executor`, we need to fail gracefully 238 if (!cancelled) { 239 doCancel(); // First of all, this failure is not recoverable, so we need to follow rule 1.4 and 1.6 240 try { 241 terminateDueTo(new IllegalStateException("Publisher terminated due to unavailable Executor.", t)); 242 } finally { 243 inboundSignals.clear(); // We're not going to need these anymore 244 // This subscription is cancelled by now, but letting it become schedulable again means 245 // that we can drain the inboundSignals queue if anything arrives after clearing 246 on.set(false); 247 } 248 } 249 } 250 } 251 } 252 253 // Our implementation of `Subscription.request` sends a signal to the Subscription that more elements are in demand 254 @Override public void request(final long n) { 255 signal(new Request(n)); 256 } 257 // Our implementation of `Subscription.cancel` sends a signal to the Subscription that the `Subscriber` is not interested in any more elements 258 @Override public void cancel() { 259 signal(Cancel.Instance); 260 } 261 // The reason for the `init` method is that we want to ensure the `SubscriptionImpl` 262 // is completely constructed before it is exposed to the thread pool, therefor this 263 // method is only intended to be invoked once, and immediately after the constructor has 264 // finished. 265 void init() { 266 signal(Subscribe.Instance); 267 } 268 }; 269}