freezerburn / jbacon Goto Github PK

This is a highly subtle and tricky bug that took me a bit to track down. Basically what happens is that fromArray will distribute a lazy event to everything that wants a value from it. For things that want a value or the event, it will asynchronously send the value. For any child EventStreams, it will send events synchronously. The lazy event that fromArray distributes doesn't actually contain a value, instead it will pull its value from a blocking queue that expects another thread to push a value onto the queue, so that the event will unblock with the value. This specific map function will (remember, this is done synchronously) attempt to get the value from the event, in order to pass it to the function and have it be evaluated/converted to an event that is acceptable for the EventStream returned by map. This will then block, and fromArray will never have the chance to push a value onto the queue, thus the entire program stops.

Not sure how to fix yet, still thinking about it.

Currently due to the way JBacon is designed, where it runs as many things as it possibly can in a concurrent manner, it can submit the array of values given to fromArray in order but the threads might run in a different order. There needs to be a way to synchronize the order of the threads so that the array of values will be reliably emitted in order, while still letting everything else run concurrently and not take (too much of) a performance hit.

Having a comprehensive test suite will be a must. It'll help you even in the short term, as you'll always know id youve broken anything i your latest change. Check out baconjs specs for reference. You can then ditch Main.java ;)

If, for any reason whatsoever, an event does not get delivered to an end recipient where the getValue method is called, using JBacon.fromArray will completely stop execution of the program. This might be caused by using JBacon.fromArray(...).filter(false), for example.

This is a side-effect of how the code works for ensuring correct ordering of the values to be passed to the first subscriber. It uses a SynchronousQueue with the methods that block until a thread is offering a value and another thread is taking a value. The getValue method for these specific events is overridden to take values from the queue, and if it never gets used due to events not being delivered, then the main thread will be permanently stuck waiting for something to take from the queue.

This could also be an issue where if an event is passed to multiple subscribers/child streams, the getValue method will block permanently because the value is only ever offered once.