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}