confluentinc / ksql

The database purpose-built for stream processing applications.
https://ksqldb.io
Other
102 stars 1.04k forks source link

NullPointerException when starting ksqlDB server in headless mode #4114

Closed vcrfxia closed 4 years ago

vcrfxia commented 4 years ago

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!

stevenpyzhang commented 4 years ago

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.

Squiggle commented 4 years ago

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
dannyrscott commented 4 years ago

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

vcrfxia commented 4 years ago

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.

dannyrscott commented 4 years ago

Upgrading to 0.7.0 worked perfectly. Thank you!