I am by now also in favor of the locking variant.
It pains me to say that, because I was the one pushing so heavily for the
other variant ( reachedEnd() / next() ) in the first place. The concept and
design of that is nice, but the reality seems to speak against it.
Writing code that is properly
+1 to the locking interface for the release. I agree with what Marton that it
seems that interruptability is to much of a burden on the sources.
The code docs should be very clear (and concise (!)) about why the locking is
needed etc.
– Ufuk
On 31 May 2015, at 14:52, Gyula Fóra wrote:
> Alri
Alright, let's do the locking then :)
Let's keep only one interface for the release.
On Sun, May 31, 2015 at 12:58 PM, Márton Balassi
wrote:
> I am also for having only one source interface. It seems that
> interruptability is to much of a burden on the sources, locking version
> should be stil
I am also for having only one source interface. It seems that
interruptability is to much of a burden on the sources, locking version
should be still acceptable from the user point of view. We are dealing with
inherently concurrent tasks, I suppose our users are familiar with locking
- especially t
I would also prefer having only one source. The PR still has both
variants so that people can check them out.
In my opinion the assumptions about interruptibility are easier to
break than the requirement of locking. Even if we get the kafka source
to work with the interruptions (which I doubt, bec
Hey,
It seems like both interfaces are pretty much capable of doing the same
thing but work on slightly different assumptions.
Isn't there a way that the kafka source can work with the interruptions? I
think the reachedEnd/next interface is slightly easier to grasp than the
run() with the locks.
