-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kafka Consumer subscribe method eats exceptions producing no output #86
Comments
can you give a try with Vert.x 3.5.0 ? |
Finally got back to this. The issue is bigger than just the implementation of this code and is an issue with how the java.util.concurrent code FutureTask is implemented and used. However, in this case, the cause is with the KafkaReadStream start method creating a single thread executor with the Executors.newSingleThreadExecutor() method. The resulting ThreadExecutor and FutureTask implementations catch exceptions in the FutureTask run() method and save them but do not pass them along to the ThreadExecutor. I have raised a vert.x wide issue on this because this will occur for many situations involving the ThreadExecutor and FutureTask. The related common issue is: vert-x3/issues#392 |
I tried to reproduce the issue here: https://github.com/aesteve/vertx-kafka-subscribe-reproducer |
@vietj did you see this? |
yes we should do something |
Is there any progress done? |
Is this still valid in 4.x where the ThreadPoolExecutor was changed? |
I am using 3.4.2 of vertx and the kafka client for consuming events from a queue.
I have found that when some exceptions happen when attempting to subscribe to a topic via the following method in the KafkaReadStream class:
public KafkaReadStream<K, V> subscribe(Set<String> topics, Handler<AsyncResult<Void>> completionHandler)
the resulting exception gets caught by the catch (Throwable ex) block of the FutureTask run() method and stored with the setException(Throwable t) method and can ultimately be passed to the ThreadPoolExecutor implementation of the afterExecute method:
protected void afterExecute(Runnable r, Throwable t) { }
where nothing is done. Subsequently no result is returned and the callback is never called making debugging of the issue more difficult.
The text was updated successfully, but these errors were encountered: