Systems and methods for reactive flattening maps for use with microservices or other computing environments

Abstract

According to embodiments, described herein are systems and methods for providing reactive flattening maps for use with microservices or other computing environments. In a cloud computing environment, reactive programming can be used with publishers and subscribers to abstract execution from execution threads while providing strict coordination of various state transitions. The described methods provide support for handling data flows involving one or more publishers and subscribers by using a multi-plane map publisher component to flatten or otherwise combine events concurrently emitted by multiple publishers into a single event stream for use by downstream subscribers.

Description

[0001] Copyright Notice

[0002] A portion of the disclosure in this patent document contains copyrighted material.

[0003] Protected material. The copyright owner does not object to anyone using the patent document or...

[0004] The content of the patent disclosure is based on the patent documents or records at the Patent and Trademark Office.

[0005] Fax copying as described in the text, but otherwise in any...

[0006] All copyrights are reserved under all circumstances.

[0007] Priority claims:

[0008] This application claims priority to U.S. Patent Application No. 17 / 410,729, filed August 24, 2021, entitled “SYSTEM AND METHOD FOR REACTIVE FLATTENING MAP FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT”; and to U.S. Provisional Patent Application No. 63 / 074,886, filed September 4, 2020, entitled “SYSTEM AND METHOD FOR REACTIVE FLATTENING MAP FOR USE WITH A MICROSERVICES OR OTHER COMPUTING ENVIRONMENT”; each of these applications is incorporated herein by reference. Technical Field

[0009] The embodiments described herein generally relate to cloud computing, software development, and microservice architectures, and are particularly aimed at providing a reactive flattening map for use with microservices or other computing environments. Background Technology

[0010] A microservices environment presents software applications as a loosely coupled collection of services that can be deployed independently and communicate with each other over a network. For example, the microservices approach can be used to develop software applications delivered as cloud services in a cloud computing environment. In such environments, microservices can provide resilience and efficiently utilize computing resources. Summary of the Invention

[0011] According to embodiments, this document describes systems and methods for providing reactive flattening mappings for use with microservices or other computing environments. In cloud computing environments, reactive programming can be used with publishers and subscribers to abstract execution from execution threads while providing strict coordination of various state transitions. The described methods provide support for processing data streams involving one or more publishers and subscribers by using a multi-plane mapping publisher component to flatten or otherwise combine events concurrently emitted by multiple publishers into a single event stream for use by downstream subscribers. Attached Figure Description

[0012] Figure 1 The illustration depicts an example microservice environment that provides a software development framework according to an embodiment.

[0013] Figure 2 The illustration depicts an example Helidon SE microservice environment according to an embodiment.

[0014] Figure 3 The illustration depicts an example Helidon MP microservice environment according to an embodiment.

[0015] Figure 4 The illustration depicts communication in a microservices environment according to an embodiment.

[0016] Figure 5 The illustration shows the use of a reactive environment in a microservices environment according to an embodiment.

[0017] Figure 6 The use of the reactive environment according to the embodiment is further illustrated.

[0018] Figure 7 The use of the reactive environment according to the embodiment is further illustrated.

[0019] Figure 8 The use of the reactive environment according to the embodiment is further illustrated.

[0020] Figure 9 The illustration depicts a multiplane mapping publisher used with microservices or other computing environments, according to an embodiment.

[0021] Figure 10 The illustration further illustrates a multiplane mapping publisher for use with microservices or other computing environments, according to an embodiment.

[0022] Figure 11 The illustration further illustrates a multiplane mapping publisher for use with microservices or other computing environments, according to an embodiment.

[0023] Figure 12The illustration further illustrates a multiplane mapping publisher for use with microservices or other computing environments, according to an embodiment.

[0024] Figure 13 The illustration further illustrates a multiplane mapping publisher used with microservices or other computing environments according to an embodiment.

[0025] Figure 14 The illustration depicts a process or method, according to an embodiment, for providing a multiplane mapping publisher for use with microservices or other computing environments. Detailed Implementation

[0026] As mentioned above, a microservices architecture can present software applications as a loosely coupled collection of services that can be deployed independently and communicate with each other over a network. For example, the microservices approach can be used to develop software applications that are provided as cloud services in a cloud computing environment. In such an environment, microservices can be used to provide resilience and efficiently utilize computing resources.

[0027] Software development frameworks such as Helidon facilitate the development of microservices. For example, Helidon provides a Standard Edition (SE) and MicroProfile (MP) programming models or environments, each of which includes a collection of software libraries that support features such as configuration, security, or web server functionality; and provides software developers with the foundation for creating microservices.

[0028] In general, Helidon reduces the need for software developers to program according to specific tools or deployment models and allows microservices to run without an application server. The Helidon library can interoperate with other software development, deployment, and / or monitoring tools, such as Docker, Kubernetes, Prometheus, or OpenTracing.

[0029] Microservices environment (Helidon)

[0030] Figure 1 The illustration depicts an example microservice environment that provides a software development framework according to an embodiment.

[0031] like Figure 1 As shown, according to an embodiment, the Helidon microservice environment 100 provides both: a standard version (SE) and a microprofile (MP) programming model or environment.

[0032] According to an embodiment, the Helidon SE environment 110 may include various libraries, APIs, or other components, such as, for example, a reactive web server 111 that provides asynchronous and reactive APIs for creating web applications; a configuration API 112 that provides a Java API to load and process configuration attributes in key / value form into configuration objects, which applications can then use to retrieve configuration data; and a security component 113 that provides authentication, authorization, and outbound security; and may also include metrics 114, health checks 115, and tracking 116, or other components.

[0033] According to an embodiment, the Helidon MP environment 120 may include various libraries, APIs, or other components, such as, for example, JAX-RS 122, JSON-P 126, CDI 124, metrics 128, health checks 130, fault tolerance 132, MicroProfile configuration 134, and JWT authentication 136 components. According to an embodiment, the web server may be provided by a non-blocking client / server / web framework 118 (such as, for example, Netty). The microservice environment can also enable interaction with the cloud, database, or other systems or services 140.

[0034] Figure 2 The illustration depicts an example Helidon SE microservice environment according to an embodiment.

[0035] like Figure 2 As shown in the examples, the Helidon SE environment supports a functional programming style that allows direct use of web servers, security, and configuration components; provides software developers with transparency and control; and supports Java features such as reactive streaming, asynchronous, and functional programming. The Helidon SE environment provides a framework through which software developers can build lightweight, reactive microservices.

[0036] Figure 3 The illustration depicts an example Helidon MP microservice environment according to an embodiment.

[0037] like Figure 3 As shown, according to an embodiment, the Helidon MP environment supports a declarative programming style by using a family of MicroProfiles of APIs built on top of the Helidon library. (For example, MicroProfile definitions specified by the Eclipse MicroProfile project) can be used to support application portability across multiple MicroProfile runtimes.

[0038] According to embodiments, a microservices environment can present software applications as a loosely coupled collection of services that can be deployed independently and communicate with each other over a network. For example, the Helidon microservices environment can support the use of remote procedure call (e.g., gRPC) frameworks or components, enabling (client and / or server) applications to communicate within the microservices environment to build connected systems.

[0039] Figure 4 The illustration depicts communication in a microservices environment according to an embodiment.

[0040] supply Figure 4 The examples shown and described are intended to illustrate one type of communication supported by a microservices environment; other types of communication may be supported according to other embodiments and examples.

[0041] like Figure 4 As shown in the illustration, according to an embodiment, the Remote Procedure Call (RPC) framework enables the definition of services and methods that can be invoked remotely. A server or service can handle calls from clients via a local object (stub) at the client's location. This local object allows the client application to directly invoke methods on the server application as if it were a local object. The server / service implements methods for handling client calls, including decoding incoming requests, executing service methods, and encoding service responses. The local object (stub) implements the same methods as the service, wrapping the parameters for the call in an appropriate protocol buffer message type and then providing it as a request to the server.

[0042] According to an embodiment, the microservice library enables client applications to access and communicate with microservices or interact with the cloud, database, or other systems or services to access data, process transactions, or perform other operations associated with these systems or services.

[0043] Reactive environment

[0044] In a traditional message-driven environment, the producer sends a message to the consumer when it becomes available; however, if the consumer cannot process the message in real time, the received message will be stored in a buffer, which may lead to performance issues.

[0045] According to embodiments, a microservice environment can provide a reactive environment, such as a reactive engine or a reactive messaging API, for use with activities such as transaction processing, asynchronous messaging channels, or reactive streaming.

[0046] Figure 5 The illustration shows the use of a reactive environment in a microservices environment according to an embodiment.

[0047] supply Figure 5The examples shown and described are examples of one type or use of a reactive environment supported by a microservices environment; other types and uses of reactive environments may be provided according to other embodiments and examples.

[0048] like Figure 5 As shown, according to an embodiment, reactive environment 200 enables client application 220 to perform reactive communication with services (as publishers and subscribers) within a microservice environment. Connector 212 can be used to provide publishers and subscribers with access to reactive messaging channels, or to provide support for using reactive messaging with Kafka, JMS, or other types of messaging, message queuing, or stream processing environments.

[0049] According to an embodiment, a reactive environment enables asynchronous stream processing with non-blocking backpressure—subscribers notify publishers how much data they can process, and publishers send the appropriate amount of data according to the subscribers' requests.

[0050] Figure 6 The use of the reactive environment according to the embodiment is further illustrated.

[0051] like Figure 6 As shown, according to an embodiment, publisher 231 (referred to as Publisher in some examples herein) operates as a producer of data based on the needs requested by its subscribers. Subscriber 232 (referred to as Subscriber in some examples herein) operates as a consumer of the data produced by the publisher. Subscription (referred to as Subscription in some examples herein) 234 defines the relationship between subscribers of the publisher and provides a mechanism for subscribers to request more data (from the publisher).

[0052] Figure 7 The use of the reactive environment according to the embodiment is further illustrated.

[0053] like Figure 7 As shown, according to an embodiment, processor 240 (referred to as Processor in some examples herein) operates as a message / data processing level and (via subscriptions 242, 244) as both a subscriber and a publisher.

[0054] Figure 8 The use of the reactive environment according to the embodiment is further illustrated.

[0055] like Figure 8As shown in the example, when a subscriber is delivered to a publisher, the subscriber receives a call to the `onSubscribe(Subscription)` method, but does not immediately begin receiving data items or other events. The subscriber only receives data items when it calls the `request(long)` method within its subscription, which signals to the publisher the need for more data.

[0056] According to the implementation, subscribers can receive data by calling the `Subscriber.onNext` method, which is called with the next item and can be called multiple times (n times), as determined by the long value passed to the subscriber's `request(long)` method. In case of an error while processing the stream, the `Subscriber.onError()` method can be called. When there is no further data to process, the `Subscriber.onComplete()` method can be called. In the event of calling both `onError()` and `onComplete()`, the publisher will not emit new data, even if the `request(long)` method is called again.

[0057] Highly efficient reactive flattening mapping

[0058] According to embodiments, microservices or other computing environments may include the use of reactive flattening mappings. In cloud computing environments, reactive programming can be used with publishers and subscribers to abstract execution away from the threads of execution while providing strict coordination of various state transitions. The described method provides support for processing data streams involving one or more publishers and subscribers by flattening or otherwise combining events concurrently emitted by multiple publishers into a single event stream for use by downstream subscribers through the use of multi-plane mapping publisher components.

[0059] According to embodiments, the technical advantages of the described method include, for example: in the presence of concurrent errors and cancellations, multiple event master orders from multiple concurrent publishers are added to a single event master order; there is a fast path; a queue that organizes concurrent events into queues, and prefetching makes the process efficient; conditions for entering the fast path; management of the status and resources of multiple concurrent subscriptions, and the type of queue used to capture status based on the specific circumstances of the problem.

[0060] Figures 9-13 The illustration depicts a multiplane mapping publisher used with microservices or other computing environments, according to an embodiment.

[0061] like Figure 9As shown, according to various embodiments, the system includes or operates a multi-FlatMap Publisher component or process 250 (referred to herein as MultiFlatMapPublisher in some examples) that concurrently flattens or otherwise combines events (e.g., data items A260, A'270 emitted by upstream publisher 251 via multiple internal publishers A 262, B272) into a single event stream for use by downstream subscriber 252.

[0062] According to an embodiment, a multi-plane mapping publisher operates as one or more internal publishers to efficiently consume upstream publishers to produce a stream of items, which is constructed from each item produced upstream and flattens out the stream of items (e.g., as [A]→[[B]]→[B], such that the stream of data item A is transformed into a stream of streams of B, and then flattened into a single stream of B). The multi-plane mapping publisher assumes that each internal publisher is allowed to progress independently of other publishers, therefore the order of the produced items is partial; only the order of items produced by one internal publisher is preserved.

[0063] According to the embodiment, at position 282, the multiplane mapping publisher serializes all interactions with downstream subscribers, protecting the drain() call with a ticket lock (254). The ticket lock acts as an atomic counter that counts how many competitors pass through. Since concurrent state changes generally eventually attempt to call drain(), the ticket lock ensures that all concurrent changes are observed and appropriately signaled downstream. Because state information can be stored as a non-thread-safe structure, correctness guarantees and resource management can be provided by observing drain().

[0064] According to the embodiment, at point 283, whenever an upstream publisher generates a data item, an internal publisher is constructed from that item. Each of these publishers is assigned an internal subscriber 264, 274, which ensures that any prefetched items have been requested. This helps reduce the cost of requesting items from upstream and reduces latency while waiting for items.

[0065] According to the embodiments, using the described method, the upstream Publisher (251) can generate data items from which multiple internal Publishers (262, 272) can be constructed sequentially. The multiple Publishers can generate items independently of each other. The items generated by the multiple independently operating Publishers are then compiled or flattened into a single stream of data items, as observed by the downstream Subscriber (252).

[0066] like Figures 10-11As shown, according to an embodiment, at 284, internal subscribers store the items they receive in private internal queues 266, 276 (e.g., as a stream of items B 261, B'271); and store references to themselves 268, 278 in a read-ready queue 256 (referred to as readReady in some examples herein) shared with all internal subscribers.

[0067] like Figure 12 As shown, according to an embodiment, at 285, the read-ready queue is polled in response to requests from downstream subscribers. At 286, when retrieving a read-ready internal subscriber, an item is removed from the head of that internal subscriber's internal queue.

[0068] like Figure 13 As shown, according to an embodiment, at 287, simultaneously, internal subscribers track how many items have been removed from their internal queues, and when that number exceeds a certain threshold, they request more items from the internal publishers they have subscribed to. When an internal subscriber enters a terminated state, it requests new items from an upstream publisher (e.g., upstream Publisher 251) to maintain the same level of concurrency.

[0069] According to an embodiment, if a multiplane mapping publisher is configured to lazily signal errors, then the error (onError) is only signaled to downstream subscribers after all internal subscribers have entered the terminated state.

[0070] According to an embodiment, if a multiplane mapping publisher is configured to urgently signal an error, then all items that an internal subscriber may hold in its internal queue are discarded, and the onError signal is immediately delivered downstream.

[0071] This behavior ensures that during the cleanup of the internal queue, or after delivery of onError, no items from the internal queue or any items received from the internal publisher's future onNext will be delivered downstream, as this would be considered an out-of-order signal that violates the publisher's specification.

[0072] According to one embodiment, if a downstream subscriber requests to cancel its subscription, then the multiplane mapping publisher eventually stops generating any signals, and in turn requests all internal subscribers to eventually stop generating any signals. Resources held by the internal subscribers are discarded. The cancellation behavior can be implemented using a mechanism similar to eager error delivery, except that the onError signal is not delivered.

[0073] drain()

[0074] According to an embodiment, the system may include a `drain()` function or component that assumes the caller has acquired the ticket lock. The main function of `drain()` is to re-examine the state whenever concurrent contenders are observed. A loop is constructed that assumes only one thread has reached the ticket lock and performs an atomic update to the contender counter after each iteration, thereby subtracting the number of contenders seen at the start of the last iteration.

[0075] If this subtraction results in 0, it means that no new competitors passed the ticket lock during the iteration, and any state changes not observed in the previous iteration will be observed in future iterations—due to the obligation to attempt to enter `drain()` after any such state change. Changes that would lead to this attempt include: changes to `cancelPending`; urgent error delivery canceled by any Publisher and downstream Subscriber; changes to the `readReady` queue; changes to requests from downstream Subscribers; or the `MultiFlatMapPublisher` becoming static.

[0076] According to the embodiment, the state transition operation is as follows:

[0077] When no request stops generating onNext, the readReady queue is not empty, and the downstream Subscriber's demand is not met, an item is taken from the head of the internal queue of the first read-ready inner Subscriber and delivered downstream. Once cancelPending is observed, the onNext call cannot be implemented.

[0078] If the loop stops due to `cancelPending`, then cleanup—releasing resources pinned by the `readReady` queue and any active internal Subscribers, signaling the Subscription to cancel (unless the upstream is known to be quiescent), and signaling any active internal Subscribers to cancel their subscriptions. This can happen concurrently with the creation of new internal Subscribers, so they should ensure that cleanup routines can observe references to them, or they should perform cleanup and Subscription cancellation themselves.

[0079] If an urgent error notification is needed, or if all Publishers are static and there are no more items in the readReady queue, then the downstream Subscriber is notified. After this MultiFlatMapPublisher is shown as canceled, onError and onComplete are no longer accessible. This can happen concurrently with an inner Subscriber attempting to deliver new items, so the cleanup routine is still accessible: any items added to the readReady queue via such concurrent calls will be removed by or on behalf of this inner Subscriber.

[0080] Detection of static

[0081] According to the implementation, the system must detect quiescence to ensure the correct order of termination signals relative to other signals. This is achieved by tracking the number of publishers (including upstream) that may deliver any signal. `onError` or `onComplete` is only delivered when all publishers have reached the termination state and error signals are lazily delivered. Initially, the `awaitingTermination` atomic counter increments from 0 to 1 to interpret upstream publishers. Then, the atomic counter increments each time `onNext` is received from upstream; it decrements when a termination signal is received from either upstream or any internal publisher. Upstreams signal the termination state by decrementing the counter by adding (-1) mod 2^31 or `MAX_VALUE`. Adding such a number to a 32-bit number that is necessarily positive results in a negative number. This aids in subscription management and helps detect when requesting or canceling an item from upstream is futile.

[0082] Subscription Management

[0083] According to the implementation, MultiFlatMapPublisher uses a FlatMapSubscriber to manage state. The FlatMapSubscriber is only allowed to be used once, thus ensuring that onSubscribe is successfully called only once. This is achieved by tracking the value of the awaitingTermination counter: a subscription is only accepted when the awaitingTermination atomic counter is zero and can atomically progress from 0 to 1. If this fails, then a Subscription has been accepted, and the onSubscribe call failed. Furthermore, the awaitingTermination counter never actually becomes 0 throughout its entire lifetime, so the above process ensures that one (and only one) Subscription is accepted. To achieve this, the most significant bit is set to 1 when the upstream Publisher generates a termination signal, so MultiFlatMapPublisher is in a quiescent state no earlier than the awaitingTermination value is MIN_VALUE. A negative awaitingTermination value is observed to indicate that the upstream has reached its termination state.

[0084] According to the implementation, when an upstream Subscription is accepted, a downstream Subscription is executed once (and only once). The onSubscribe signal is excluded from other downstream signals because they do not occur until any Publisher is generated from the item received from the upstream. This does not happen before a request is invoked on the upstream Subscription (which is executed after the downstream onSubscribe completes).

[0085] Cancellation and Error Notification

[0086] According to the implementation, downstream Subscribers can concurrently cancel their subscriptions at any time. Errors can also occur concurrently—especially when a downstream Subscriber makes an invalid request. The tracking of these two conditions is similar—the only observable difference is whether the `canceled` flag is set, and if lazy error notification is configured, the error will not be observed until the MultiFlatMapPublisher is in a static state. If `canceled` is observed by `drain()`, it is assumed that the MultiFlatMapPublisher is in a canceled state, and the error is ignored (even if it occurred).

[0087] According to an embodiment, the cancellation operation is performed to: notify the upstream that its signal is no longer needed; notify all internal Subscribers that the signal is no longer needed; and release any resources.

[0088] According to the implementation, in order to notify the internal Subscriber, FlatMapSubscriber keeps track of all current internal Subscribers in the Subscriber collection. Because cancellation can occur concurrently with any other event, internal Subscribers must verify whether their presence in the Subscriber collection is observable: if cancelPending is observed to be false after an internal Subscriber is added to the collection, then cleanup is guaranteed to be in the future; otherwise, the internal Subscriber should perform cleanup of its Subscription and resources. Therefore, performing this check once in the internal Subscriber's onSubscribe() method is sufficient.

[0089] According to an implementation, internal Subscribers remove themselves from the Subscriber collection upon reaching a termination state because there is no longer a need to interact with the internal Subscription, and a single reference to such a Subscriber can be found in the readReady queue. In effect, such Subscribers do not observe any cancellation, and cleaning up the resources consumed by them is equivalent to discarding all references from the readReady queue during cleanup.

[0090] Resource Management

[0091] The reactive nature of interacting with MultiFlatMapPublisher requires it to retain a limited number of resources in the presence of publishers that conform to the reactive specification. There is also an obligation to retain resources for the shortest possible time when necessary, in the event of ineligible subscribers or malformed pipelines that may retain references to MultiFlatMapPublisher indefinitely. These challenges necessitate tracking the needs of downstream subscribers and ensuring that upstream and internal publishers retain a limited number of items. More items are only requested from upstream after the last item in the internal subscriber queue has been consumed—this ensures that all internal subscribers retain no more than maxConcurrency*prefetchitems.

[0092] According to the implementation, the system can ensure that `cleanup()` remains available even after the system has entered a terminated state, in case concurrent internal Subscribers fail to observe cancellations or eagerly delivered errors before queuing more items. Furthermore, internal Publishers are not obligated to immediately observe cancellations and can spawn more items over an unspecified period (only requiring them to eventually stop spawning items).

[0093] The last item in the detection queue conditions

[0094] According to the implementation, internal Subscribers add themselves to the readReady queue for each item they are ready to produce. Additionally, when they reach a termination state, they add themselves to the readReady queue once more. The drain() loop eventually observes such internal Subscribers at the head of the readReady queue, but finds their internal queue empty. This is interpreted by the drain() loop as an indication that the last item has been consumed by the internal Subscriber, and it executes a request for more items from upstream to effectively replace the just-completed Publisher with a new internal Publisher.

[0095] Specifically, the order in which the readReady queue is checked for emptiness before checking for requests from downstream Subscribers ensures that this condition is observed and that requests from upstream are signaled, while downstream Subscribers do not need to signal any requests.

[0096] empty()

[0097] According to the implementation, as long as any internal Subscriber exists at the head of the readReady queue, the empty() check removes the head of the readReady queue, leaving its internal queue empty. It then requests as many items from upstream as the number of such internal Subscribers found at the head of the readReady queue. Furthermore, after this operation, the readReady queue is either empty or contains internal Subscribers (whose head is a non-empty internal queue).

[0098] Fast path

[0099] According to the embodiments, there are use cases in which significant performance gains can be obtained by eliminating interaction with the readReady queue, such as: sequential flattening of all internal publishers (e.g., maxConcurrency = 1); coordinated concurrent internal publishers: several internal publishers are producing items in a general order established by out-of-band means.

[0100] If the downstream Subscriber is faster than the Publisher in these situations, or is able to consume multiple items simultaneously, the readReady queue may appear empty most of the time. In such cases, the Publisher often adds the first item to the readReady queue, and items that should appear in a partial order of all items have already been consumed. It is possible to directly deliver such items to the downstream Subscriber, thus avoiding the readReady queue, as long as the overall order of all signals to the downstream Subscriber is maintained.

[0101] According to the implementation, the internal SubscriberNext, onError, and onComplete attempt to acquire the ticket lock (attempting to atomically update the contender counter from 0 to 1), and if successful, then verify the same conditions as drain(): if cancelPending or the readReady queue is not empty, or there is insufficient demand from the downstream Subscriber, then fall back to the slow path, put the item into the internal queue, put itself into the readReady queue, and call drain(); otherwise, it is safe to assume exclusive access to the FlatMapSubscriber's state and the signal for serialization downstream, and eventually enter drain() to observe whether any other state changes occur concurrently.

[0102] According to the implementation, onError and onComplete can verify weaker conditions: the internal queue is empty, and the queue is not readReady. These signals do not cause any signals to be sent downstream, so there is no need to order these signals with respect to any read-ready internal Subscriber in the queue.

[0103] Read-Ready queue

[0104] According to the implementation, most of the readReady queue and the internal queue of the internal Subscriber are accessed by a single thread:

[0105] The put() method to the readReady queue can be executed concurrently by any internal Subscriber.

[0106] The put() function to the internal queue can be executed by the internal Subscriber and is executed in a single thread; this is guaranteed by the overall order of events signaled by the internal Publisher.

[0107] The peek(), poll(), empty(), and clear() methods of the readReady queue are called by the ticket lock owner in a single thread.

[0108] The ticket lock owner calls the internal queue's peek(), poll(), empty(), and clear() functions in a single thread.

[0109] According to the implementation, poll() on the inner queue of the inner Subscriber is not implemented unless the Subscriber is found at the head of the readReady queue. Although the inner Subscriber and drain() appear to concurrently access the head and tail of the inner queue, drain() does not attempt to access parts of the queue other than the tail element as observed before readReady.put().

[0110] According to an embodiment, concurrent calls to `put()` on an internal queue can exist, which are executed to clean up resources after cancellation or urgent error delivery. Since `clear()` may not observe that the tail of the queue has been updated, additional methods can be provided to `clearTail()` for internal Subscribers to execute when they observe that concurrent `clear()` calls may exist.

[0111] put()

[0112] According to the implementation, put() operates like a ConcurrentLinkedQueue—for use by internal Subscribers, adding themselves to the readReady queue.

[0113] poll(), peek(), empty() and clear()

[0114] According to the embodiments, these functions are guaranteed to be safe unless the following conditions are met:

[0115] Concurrent poll() and peek().

[0116] Use deserialized load and store (non-volatile read and write) to read and update the head.

[0117] In the presence of concurrent `put()` or `putNotSafe()` calls, modifying `head.tail` in `clear()` makes `tail.v` invisible to `poll()`, `peek()`, and `clear()`. Internal Subscribers adding items to the `readReady` queue should ensure references are discarded, as the Subscriber may become inaccessible via `readReady`. Since references to internal Subscribers escape through the internal `Publisher.subscribe` queue and should be assumed to be indefinitely accessible, cleanup is still necessary. Internal Subscribers adding items to the `readReady` queue will enter `drain()`, observe `cancelPending`, and call `readReady.clear()` again, thus updating `head` and discarding the references.

[0118] putNotSafe()

[0119] According to the implementation, this function is guaranteed to be safe in the absence of concurrent `put()` and other `putNotSafe()` calls. The queue nodes are initialized using deserialized storage (non-volatile writes), and the `tail` pointer is updated.

[0120] clearTail()

[0121] According to the implementation, it is ensured that references to the last item in the queue are discarded. This preserves references to the queue nodes, but keeps the occupied space constant (with a constant upper limit).

[0122] Figure 14 The illustration depicts a process or method, according to an embodiment, for providing a multiplane mapping publisher for use with microservices or other computing environments.

[0123] like Figure 14 As shown, according to various embodiments, the method may include, at step 290, providing a microservice environment (microservice library) at a computer including one or more processors and memory, and a reactive environment associated with the microservice environment that can be used with reactive streams to enable client and server applications to communicate within the microservice environment.

[0124] At step 291, the multiplane mapping publisher serializes its interactions with downstream subscribers by protecting the drain() call with a ticket lock.

[0125] At step 292, whenever an upstream publisher produces an item, a publisher is constructed from it; each publisher is given an internal subscriber, which ensures that the prefetched item has been requested.

[0126] At step 293, each internal subscriber stores the items they receive in their private internal queue and stores a reference to themselves in a read-ready queue shared by all internal subscribers.

[0127] At step 294, the read-ready queue is polled in response to requests from downstream subscribers; a read-ready internal subscriber is retrieved, and an item is removed from the head of the internal subscriber's internal queue.

[0128] At step 295, each internal subscriber keeps track of how many items have been removed from its internal queue, and when that number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

[0129] According to various embodiments, the teachings herein can be conveniently implemented using one or more conventional general-purpose or special-purpose computers, computing devices, machines, or microprocessors (including one or more processors, memory, and / or computer-readable storage media programmed according to the teachings of this disclosure). As will be apparent to those skilled in the art of software, a skilled programmer can readily prepare appropriate software code based on the teachings of this disclosure.

[0130] In some embodiments, the teachings herein may include a computer program product, which is one or more non-transitory computer-readable storage media on which / therein stores instructions that can be used to program a computer to perform any of the processing described herein. Examples of such storage media may include, but are not limited to, hard disk drives, hard drives, fixed disks or other electromechanical data storage devices, floppy disks, optical disks, DVDs, CD-ROMs, microdrives and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems or other types of storage media or devices suitable for the non-transitory storage of instructions and / or data.

[0131] The foregoing description is provided for illustrative purposes. It is not intended to be exhaustive or to limit the scope of protection to the precise forms disclosed. Many modifications and variations will be apparent to those skilled in the art.

[0132] For example, while various embodiments of the systems and methods described herein illustrate use in the Helidon microservices environment, these embodiments can be used with other types of microservices environments or other computing environments.

[0133] The embodiments were chosen and described in order to best explain the principles of this teaching and its practical application, thereby enabling others skilled in the art to understand the various embodiments and modifications suitable for the particular intended use. The scope is intended to be defined by the following claims and their equivalents.

Claims

1. A system for providing reactive flattening mapping, comprising: A computer, including one or more processors, is configured to provide access to a computing environment for use with software applications; The system described above supports the processing of streams involving one or more publishers and subscribers, wherein publishers publish streams of data and subscribers consume data; and A multiplane mapping publisher component, configured as follows: Consume upstream publishers to generate project streams from internal publishers, which are constructed from each project generated by the upstream publishers; The project stream is flattened out for use by downstream subscribers; as well as Interactions with downstream subscribers are serialized by using ticket locks to protect consumption calls.

2. The system as claimed in claim 1, wherein: Whenever an upstream publisher generates a project, a publisher is constructed from that project. Each publisher is assigned an internal subscriber, which ensures that the project has been requested.

3. The system as claimed in claim 1, wherein: Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue.

4. The system as claimed in claim 1, wherein: Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

5. The system as claimed in claim 1, wherein: Whenever an upstream publisher generates a project, a publisher is constructed from that project. Each publisher is assigned an internal subscriber, which ensures that the project has been prefetched. Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue; and Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

6. The system of claim 1, wherein the computing environment is provided within a cloud computing environment.

7. A method for providing a reactive flattening map, comprising: A computing environment is provided at a computer that includes one or more processors for use with software applications; Processing streams involving one or more publishers and subscribers, where publishers publish data to the stream and subscribers consume the data; and Provide a multiplane mapping publisher component, which is configured as follows: Consume upstream publishers to generate project streams from internal publishers, which are constructed from each project generated by the upstream publishers; The project stream is flattened out for use by downstream subscribers; as well as Interactions with downstream subscribers are serialized by using ticket locks to protect consumption calls.

8. The method of claim 7, wherein: Whenever an upstream publisher generates a project, a publisher is constructed from that project. Each publisher is assigned an internal subscriber, which ensures that the project has been requested.

9. The method of claim 7, wherein: Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue.

10. The method of claim 7, wherein: Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

11. The method of claim 7, wherein: Whenever an upstream publisher generates a project, a publisher is constructed from that project. Each publisher is assigned an internal subscriber, which ensures that the project has been prefetched. Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue; and Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

12. The method of claim 7, wherein the computing environment is provided within a cloud computing environment.

13. A non-transitory computer-readable storage medium comprising instructions stored thereon, the instructions, when read and executed by one or more computers, causing the one or more computers to perform the following steps: Provides a computing environment for use with software applications; Processing streams involving one or more publishers and subscribers, where publishers publish data to the stream and subscribers consume the data; and Provide a multiplane mapping publisher component, which is configured as follows: Consume upstream publishers to generate project streams from internal publishers, which are constructed from each project generated by the upstream publishers; The project stream is flattened for use by downstream subscribers; and Interactions with downstream subscribers are serialized by using ticket locks to protect consumption calls.

14. The non-transitory computer-readable storage medium of claim 13, wherein: Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue.

15. The non-transitory computer-readable storage medium of claim 13, wherein: Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

16. The non-transitory computer-readable storage medium of claim 13, wherein: Whenever an upstream publisher generates a project, a publisher is constructed from that project. Each publisher is assigned an internal subscriber, which ensures that the project has been prefetched. Each internal subscriber stores the items they receive in their private internal queue and stores a reference to itself in a read-ready queue shared by all internal subscribers; The read-ready queue is polled in response to requests from downstream subscribers; When a read-ready internal subscriber is retrieved, the item is removed from the head of the internal subscriber's internal queue; and Each internal subscriber keeps track of how many items have been removed from its internal queue, and when the number exceeds a threshold, requests more items from the internal publishers they have subscribed to.

17. The non-transitory computer-readable storage medium of claim 13, wherein the computing environment is provided within a cloud computing environment.

18. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 7-12.

Images