Github user koeninger commented on the issue:
    In general, 2 things about this make me uncomfortable:
    - It's basically a cut-and-paste of the SQL equivalent PR,, but it is different from both that 
PR and the existing DStream code.
    - I don't see an upper bound on the number of consumers per key, nor a way 
of reaping idle consumers.  If the SQL equivalent code is likely to be modified 
to use pooling of some kind, seems better to make a consistent decision.


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to