-
Notifications
You must be signed in to change notification settings - Fork 463
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
stopping tomcat container does not kill kinesis consumer connection #167
Comments
The KCL isn't really designed to be managed by a container. I suspect the problem might be related to KinesisEventStreamConsumer.java:203, since the method returns a future that you're not waiting on. |
@pfifer you are right. I will definitely see waiting on might look like while(!nativeConsumer.requestShutdown().isDone()) {}
consumerThread.stop(); Thanks for your input. |
This is a bug as you shouldn't have to request the value of a future to trigger the completion of it. Thanks for reporting it. For the time being you can do something like:
or if you don't want to wait forever do
with whatever timeout you want to use. You will need to handle the exceptions these methods can throw though. |
public Future<Void> requestShutdown() {}
public void shutdown() {} I believe But even if I wait on {
"commonElementCount": 0,
"name": "java.lang.ThreadDeath",
"extendedStackTrace": [
{
"class": "java.lang.Thread",
"method": "stop",
"file": "Thread.java",
"line": 850,
"exact": true,
"location": "?",
"version": "1.8.0_111"
},
{
"class": "com.eventstream.consumer.kinesis.KinesisEventStreamConsumer",
"method": "shutdown",
"file": "KinesisEventStreamConsumer.java",
"line": 210,
"exact": false,
"location": "classes/",
"version": "?"
},
{
"class": "com.eventstream.consumer.kinesis.KinesisEventStreamConsumerComponentSpecs$$anonfun$1$$anonfun$apply$mcV$sp$2",
"method": "apply",
"file": "KinesisEventStreamConsumerComponentSpecs.scala",
"line": 176,
"exact": false,
"location": "test-classes/",
"version": "?"
},
{
"class": "com.eventstream.consumer.kinesis.KinesisEventStreamConsumerComponentSpecs$$anonfun$1$$anonfun$apply$mcV$sp$2",
"method": "apply",
"file": "KinesisEventStreamConsumerComponentSpecs.scala",
"line": 129,
"exact": false,
"location": "test-classes/",
"version": "?"
}
]
} I get same val processor = new Thread()
processor.setUncaughtExceptionHandler(new UncaughtExceptionHandler {
override def uncaughtException(t: Thread, e: Throwable): Unit = e.printStackTrace()
})
println(processor.isAlive)
processor.start()
processor.stop()
println(processor.isAlive) |
Nevermind, I should not be trying to stop nativeConsumer.requestShutdown().get(5, TimeUnit.SECONDS) That way my container would be fine as well. |
* Initial start of fix for requested shutdown * Execute the requested shutdown in a separate thread. Fix for Issue #167 * Reworked some of the shutdown logic to make the relationships clearer. * Added/Updated Copyright Statements * Add Missing License Statements
* Execute graceful shutdown on its own thread * PR awslabs#191 * Issue awslabs#167 * Added support for controlling the size of the lease renewer thread pool * PR awslabs#177 * Issue awslabs#171 * Require Java 8 and later Java 8 is now required for versions 1.8.0 of the amazon-kinesis-client and later. * PR awslabs#176
I have stream consumer app running inside tomcat container.
When I stop the tomcat container, it is supposed to stop the kinesis-stream consumer-app resources as well, but it does not,
Even after
/usr/local/apache-tomcat-8.0.42/bin/shutdown.sh
, I see tomcat not properly stopped.Which lets the consumer keep running as I can see the consumerLeaseCounter keep increasing,
I see the the error stopping the consumer resources,
On
nativeWorker.requestShutdown();
. I'm wrappingnativeWorker
around my thread calledconsumerThread = new Thread(nativeWorker);
I'm wrapping the
nativeWorker
in myStreamConsumer#consumeOnce
- https://github.com/nihil-os/stream-driver/blob/kinesis-stream/src/main/java/com/eventstream/consumer/kinesis/KinesisEventStreamConsumer.java#L102The way I'm making it work for now is using unix
kill
to stop the tomcat process.The text was updated successfully, but these errors were encountered: