wilcowijbrandi
commented
7 years ago I think this is a great addition which totally makes sense, but I'm not a big fan of spawning a thread (or 8 in this case) for every ObservationProvider. Ideally we would make use of the FlexiblePowerContext to schedule tasks here, but unfortunately there is no easy way to access it from here. The solution that makes most sense to me is to make the EF-Pi runtime responsible for delivering observations. That would however mean quite an API change...
De publish methode van AbstractObservationProvider roept alle consumers aan in een for loopje, binnen dezelfde thread. Als één van deze consumers zich niet lekker gedraagt, bijv. een Exception treedt op in de consume methode, dan stopt de tread en worden andere consumers niet aangeroepen.
De wijziging zorgt ervoor dat alle consumers asynchroon dmv een Executor worden aangeroepen, zodat degene die publish aanroept zich niet druk hoeft te maken over wat er in die methode en in de ObservationConsumers gebeurt.