Closed vcrfxia closed 4 years ago
The legacy default value was changed from an actual value to null. This is problematic because in StandaloneExecutor, we put the configs into a Java Properties object which is a HashTable implementation. HashTables don't allow null keys/values so even removing the toString()
part won't fix it. We need to do null checks before putting configs into the Properties object.
As of 10th Feb the latest docker image is still 0.6.0, so still unable to run headless.
Is there a workaround for this?
Edit: found a work-around
Setting the ksql.sink.replicas
and ksql.sink.partitions
config values to an integer gets me over this hurdle (these are the properties that are also defaulted to null
, causing this error)
Added these lines to my docker-compose.yml:
KSQL_KSQL_SINK_REPLICAS: 1
KSQL_KSQL_SINK_PARTITIONS: 1
Still having this same issue with 0.6.0 The env variable KSQL_KSQL_SINK_PARTITIONS does not seem to take and is always null
Hi @dannyrscott , ksqlDB 0.7.0 was just release and has a native fix for this bug, so no workaround is required: https://www.confluent.io/blog/ksqldb-0-7-0-feature-updates/ If you don't yet have long-running KSQL applications you'd like to keep, I'd recommend upgrading. (Do note, however, that in-place upgrades from 0.6.0 to 0.7.0 are not supported, so you'd have to start fresh on 0.7.0.)
Alternatively, if you're set on 0.6.0, sharing your docker-compose.yml and queries file will aid in debugging.
Upgrading to 0.7.0 worked perfectly. Thank you!
Describe the bug
ksqlDB server (docker image tag 0.6.0) fails to start in headless mode with the following:
To Reproduce
Follow the instructions at https://docs.ksqldb.io/en/latest/operate-and-deploy/installation/install-ksqldb-with-docker/#ksqldb-headless-server-settings-production to start the ksqlDB server (docker image tag 0.6.0) in headless mode. Specifically:
queries.sql
file. The contents are unimportant as long as they're valid.Expected behavior
The ksqlDB server should start successfully.
Actual behaviour
The ksqlDB server fails to start with
Additional context
Thanks to @mikebin for bringing this up!