@patelrit Could you point us to the appropriate code please?

@almonteb Not sure about this but for the user it would be even simpler if the API itself starts an internal thread that drives the registered callbacks.

What about to use the EventsCmdImpl command itself for both the callback registration (via fluent style withEventCallback(EventCallback eventCallback method) as well as the thread handling. Then there is no need to return an EventStreamobject and exec() may return void and starts the thread.

The current command like API style allows to start a command via exec() but not to stop it. So we could add a stop() method to the EventsCmdinterface that stops the internal thread again

Don't know if this would be hard to implement . Its just a quick idea...