Ksql: NullPointerException when starting ksqlDB server in headless mode

Created on 11 Dec 2019  路  5Comments  路  Source: confluentinc/ksql

Describe the bug

ksqlDB server (docker image tag 0.6.0) fails to start in headless mode with the following:

[2019-12-11 19:02:57,913] ERROR Failed to start KSQL (io.confluent.ksql.rest.server.KsqlServerMain:63)
java.lang.NullPointerException
    at io.confluent.ksql.rest.server.StandaloneExecutor.lambda$startAsync$0(StandaloneExecutor.java:121)
    at java.util.HashMap.forEach(HashMap.java:1289)
    at io.confluent.ksql.rest.server.StandaloneExecutor.startAsync(StandaloneExecutor.java:121)
    at io.confluent.ksql.rest.server.KsqlServerMain.tryStartApp(KsqlServerMain.java:75)
    at io.confluent.ksql.rest.server.KsqlServerMain.main(KsqlServerMain.java:61)

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:

  1. Create a queries.sql file. The contents are unimportant as long as they're valid.
  2. Start Kafka locally.
  3. Attempt to start ksqlDB server in headless mode:
$ docker run \
    -v /Users/victoria.xia/tmp/docker-test:/home \
    -e KSQL_BOOTSTRAP_SERVERS=host.docker.internal:9092 \
    -e KSQL_KSQL_SERVICE_ID=ksql_standalone_1_ \
    -e KSQL_KSQL_QUERIES_FILE=/home/queries.sql \
    confluentinc/ksqldb-server:0.6.0

Expected behavior

The ksqlDB server should start successfully.

Actual behaviour

The ksqlDB server fails to start with

[2019-12-11 19:02:57,913] ERROR Failed to start KSQL (io.confluent.ksql.rest.server.KsqlServerMain:63)
java.lang.NullPointerException
    at io.confluent.ksql.rest.server.StandaloneExecutor.lambda$startAsync$0(StandaloneExecutor.java:121)
    at java.util.HashMap.forEach(HashMap.java:1289)
    at io.confluent.ksql.rest.server.StandaloneExecutor.startAsync(StandaloneExecutor.java:121)
    at io.confluent.ksql.rest.server.KsqlServerMain.tryStartApp(KsqlServerMain.java:75)
    at io.confluent.ksql.rest.server.KsqlServerMain.main(KsqlServerMain.java:61)

Additional context

Thanks to @mikebin for bringing this up!

bug

Most helpful comment

https://github.com/confluentinc/ksql/commit/289324117070123a8b4ab686774b6a409b8a5e09#diff-7848c43dbebc7bc8c45c12b2c1e2689cR247

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.

All 5 comments

https://github.com/confluentinc/ksql/commit/289324117070123a8b4ab686774b6a409b8a5e09#diff-7848c43dbebc7bc8c45c12b2c1e2689cR247

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bhargav516 picture bhargav516  路  3Comments

utkarshsaraf19 picture utkarshsaraf19  路  4Comments

selvakumarEsra picture selvakumarEsra  路  4Comments

hjafarpour picture hjafarpour  路  5Comments

yodo-t picture yodo-t  路  3Comments