Aris Tzoumas
Aris Tzoumas
I have the same problem, seems like the observable suffers from premature death using `rxgo.Serialize`. @teivah any idea why this happens?
> Because this way we'd only be picking up `discarded` number of jobs in further iterations. This behaviour is intentional. The iterator only compensates for discarded jobs to avoid ending...
> One other thought is that since we query by `job_id` as well now, we could use > > ``` > type dataSetRangeT struct { > minJobID int64 > maxJobID...
> till they get garbage collected.. Since discarded jobs will be eligible for garbage collection, we can rely on that, if memory resources become scarce, they will get garbage collected.
Thank you @Sidddddarth. Is it possible to add a test scenario for it as well?
> I am not sure if the solution is to have lazy transactions or refactor the code in such a way that only transaction-related stuff is inside a transaction block....
@lvrach @fracasula @chandumlg you can find an alternative approach in #2209 Let me know if you prefer it in order to proceed with adding unit/integration tests.
IMO suppressing events from router turns out to not being as straightforward as it is in processor. Processor is an event producer at heart, whereas router is an event consumer,...
We are moving forward with a different approach, as in #2211