Given a scenario where I have a BroadcastBlock and 5 linked targets. When I send an element to BroadcastBlock, each of the linked targets will get the element automatically. This works great.
The problem: If I have this configuration (1 BroadcastBlock & 5 linked targets) and then decide to add a 6th linked target, runtime, the newly linked target instantly receives the last element sent to the BroadcastBlock. This must mean that after successfully broadcasting the newly received element to the listeners, this element stays in the BroadcastBlock until it has been replaced with a new element? And if I add a new listener, it will get the element when the linking happens.
What I expected: If an element is sent to BroadcastBlock and the block successfully broadcasts the element to its 5 listeners, the element is automatically removed from the BroadcastBlock. So when I add a new listener, it doesn't receive anything until I send a new element to BroadcastBlock.
Question: Is it possible to clear the BroadcastBlock after it has successfully broadcasted the newly added element to its current listeners?
Related
In Reactivex.IO documentation it was stated that
You can ignore the final n items emitted by an Observable and attend only to those items that come before them, by modifying the Observable with the SkipLast operator.
and the diagram from http://reactivex.io/documentation/operators/skiplast.html
My Expectations: SkipLast will read the entire Observable till it meets the OnCompleted and then generates a new Observable with the timings as the Original one but skipping the Last ones.
My Doubt: How does SkipLast Operator know that "3" is that Last 2nd Item from the Observable? Without seeing the OnCompleted how can it tell the Last nth Item?
Thanks #PanagiotisKanavos, #akarnokd for Valuable comments.
It is internally implemented with a Queue of Fixed Size. Take the items from the Sequence and Enqueue them, when the Queue is full and Starts to Overflow Dequeue the item & Enqueue the latest value and Send to OnNext(dequeued_value), so when OnCompleted Reached you will not Send the Cached items and just call OnCompleted. By this last N cached items are Skipped.
From a source code if skipLast(N) is used, then N messages is kept in the this._ring array. As soon N+1 arrived first message is emitted, N+2 arrived => second messages is emitted etc.
I have used C# to add elements to my layout that has a name of detailsLayout. I add about 20 grids elements and inside each of those are more elements:
Now I want to delete those elements. Is there a difference between these two ways:
detailsLayout.Children.Remove();
andÂ
detailsLayout.Children.Clear();
I didn't verify this but I could imagine the following. Remove is intended for removing 1 entry. By doing so, the remove will also call all kinds of events associated with the removal of one entry. Such as maybe updating the UI or triggering an event.
With Clear, all children are first removed and then all associated actions, like, again updating the UI or triggering an event, are done. Because it is apparent that you want to remove all the children since you are calling Clear the system can wait to trigger resulting actions until the operation is done.
In this case, it will mostly be a matter of performance. In the end, both will have the same result.
Erlang uses message passing to communicate between processes. How does it handle concurrent incoming messages? What data structure is used?
The process inbox is made of 2 lists.
The main one is a fifo where all the incoming messages are stored, waiting for the process to examine them in the exact order they were received. The second one is a stack to store the messages that won't match any clause in a given receive statement.
When the process executes a receive statement, it will try to "pattern match" the first message against each clause of the receive in the order they are declared until the first match occurs.
if no match is found, the message is removed from the fifo and stacked on the second list, then the process iterates with the next message (note that the process execution may be suspended in the mean time either because the fifo is empty, or because it has reached his "reduction quota")
if a match is found, the message is removed from the fifo, and the stacked messages are restored in the fifo in their original order
note that the pattern matching process includes the copy of any interesting stuff into the process variables for example if {request,write,Value,_} -> ... succeeds, that means that the examined message is a 4 elements tuple, whose first and second elements are respectively the atoms request and write, whose third element is successfully pattern matched against the variable Value: that means that Value is bound to this element if it was previously unbound, or that Value matches the element, and finally the fourth element is discarded. After this operation is completed, there is no mean to retrieve the original message
You may get some info out of checking out the erl_message primitive, erl_message.c, and its declaration file, erl_message.h.
You may also find these threads helpful (one, two), although I think your question is more about the data structures in play.
ERTS Structures
The erlang runtime system (erts) allocates a fragmented (linked) heap for the scheduling of message passing (see source). The ErlHeapFragment structure can be found here.
However, each process also has a pretty simple fifo queue structure to which they copy messages from the heap in order to consume them. Underlying the queue is a linked list, and there are mechanisms to bypass the heap and use the process queue directly. See here for more info on that guy.
Finally each process also has a stack (also implemented as a list) where messages that don't have a matching pattern in receive are placed. This acts as a way to store messages that might be important, but that the process has no way of handling (matching) until another, different message is received. This is part of how erlang has such powerful "hot-swapping" mechanisms.
Concurrent Message Passing Semantics
At a high level, the erts receives a message and places it in the heap (unless explicitly told not to), and each process is responsible for selecting messages to copy into its own process queue. From what I have read, the messages currently in the queue will be processed before copying from the heap again, but there is likely more nuance.
i am trying to implement an infinite scroll from many items that i get from the server, but i cannot find any proper way to keep the flux architecture design rules.
the idea is: on the first load, i get a full item list from server (only id's), then using ajax i fetch each time 20 more items.
the list is kept in the Store, and also the loaded items. the view listens on loaded items and render them, when it reaches scroll bottom it calls an action which should then fetch 20 more items, and so on.
the problem is: the Action should know what items to fetch, the unloaded items list is in the store, so it has to get it from the store directly, which is a "don't do it' in flux. other alternatives are to handle all the logic in the stores, which seems also a bad idea..
can anyone think of a nice solution?
UPDATE: it is OK within unidirectional flow for a component to read directly from store (see below)
Make your action explicitly say which items to fetch: "Give me items 21-40 please".
This fires a) (async) ajax call to get items 21-40 and b) dispatch to the store.
The component knows a) which items it has already rendered, and b) which items the user wants to see next, so it can pass along the above action message without talking to the store again.
The store receives the request. The store knows it does not have the items yet. The component does not know yet.
Store emits change, and your component (assuming it is listening to store changes) gets current state from store. If the items weren't there, the store provides a loading state ("loading items 21-40" or similar). The component displays the loading state. (or, if the loaded items are already fully in store, it simply renders items 21-40).
As soon as items 21-40 are delivered by ajax return, your store updates with the full items 21-40. (if they happened to be in store already, no problem, no update). Store emits another change. Component hears this, and re-renders.
ASIDE:
Unidirectional flow is for updates:
Component -> lower components -> actions (-> webAPI -> action) -> dispatcher -> stores -> components
In unidirectional flow rules are:
Components are allowed to push data updates only to lower components (by passing new props, which trigger re-render), not to higher components
Components are allowed to maintain an internal state, which they can pass on as props to children (see 1)
Components are allowed to push data updates or update requests also to the dispatcher (in "actions"). The dispatcher then forwards the updates to the stores and/or to some server via eg webAPI.
Components are allowed to listen to store changes and pull/ read data directly from the store.
Stores listen to the dispatcher, and update if they receive news from the dispatcher.
Stores may also listen to other stores, and read data from other stores to update themselves
Stores emit change as soon as they have updated, so that any components listening can do something (typically read new data) (see 4.)
WebAPI results from the server are "actions". They go through dispatcher which informs the relevant stores to update. (See 5)
Unidirectional flow breaks if:
Component actively fetches/ pulls data from a higher component - such data should be pushed by higher component as props (see 1)
Component actively fetches data from child - as parent, component should already have this data. If it is in child's state, then state is designed at too low level.
Component directly updates store - should be with an action through dispatcher
And also breaks if (although some disagree):
Store directly updates another store - should be pull instead of push (see 6)
Store pushes update through an action - only webAPI (see 8) and components (see 3) are allowed to issue actions
Component directly does webAPI request and handles result in state - should go through dispatcher
I have a NetIQ (Novell) IDM 4.0.1 driver. In a policy I have a <do-status> rule with level retry.
Does this retry block any other event from being processed?
From the logic of the application the event for (A) can not be processed until the object (B) is associated by the very same driver. Therefore I have added the retry rule on (A). However, it seems that the event for (B) is blocked when the event for (A) is waiting for being retried. If I use veto instead of retry for (A) then the event for (B) is processed regulary.
Is the behaviour specified somewhere?
This takes the top event in the queue, and retries it every 'interval' (which is defined in an Engine Control Value, defaults to 30 seconds).
So yes, it blocks all following events until it completes and stops being a retry.
What you could do is much simpler. In the Input Transform policy set, look for the operation add-association since that is when the object is successfully added to the connected system.
Then do your rule B stuff.
Unless you mean two different objects A and B, that are otherwise unrelated. If so, would let object A logic go through, and when you see object B come through then do the work on object A that is needed.