SELECT query hangs and doesn’t stop?
Queries in ksqlDB, including non-persistent queries such as SELECT * FROM myTable EMIT CHANGES
, are continuous streaming queries.
Streaming queries will not stop unless explicitly terminated. To terminate a non-persistent query in the ksqlDB CLI you
must type Ctrl + C
.
ksqlDB CLI doesn’t connect to ksqlDB server?
The following warning may occur when you start the ksqlDB CLI.
**************** WARNING ******************
Remote server address may not be valid:
Error issuing GET to KSQL server
Caused by: java.net.SocketException: Connection reset
Caused by: Connection reset
*******************************************
Also, you may see a similar error when you create a ksqlDB query by using the
CLI.
Error issuing POST to KSQL server
Caused by: java.net.SocketException: Connection reset
Caused by: Connection reset
In both cases, the CLI can’t connect to the ksqlDB server, which may be caused by
one of the following conditions:
- ksqlDB CLI isn’t connected to the correct ksqlDB server port.
- ksqlDB server isn’t running.
- ksqlDB server is running but listening on a different port.
Check the port that ksqlDB CLI is using
Ensure that the ksqlDB CLI is configured with the correct ksqlDB server port.
By default, the server listens on port 8088
. For more info, see
Starting the ksqlDB CLI.
Check the ksqlDB server configuration
In the ksqlDB server configuration file, check that the list of listeners
has the host address and port configured correctly. Look for the listeners
setting:
listeners=http://0.0.0.0:8088
Or if you are running over IPv6:
listeners=http://[::]:8088
For more info, see Starting ksqlDB Server.
Check for a port conflict
There may be another process running on the port that the ksqlDB server listens
on. Use the following command to check the process that’s running on the port
assigned to the ksqlDB server. The following example checks the default port,
which is 8088
.
netstat -anv | egrep -w .*8088.*LISTEN
Your output should resemble:
tcp4 0 0 *.8088 *.* LISTEN 131072 131072 46314 0
In this example, 46314
is the PID of the process that’s listening on port
8088
. Run the following command to get info on the process:
Your output should resemble:
io.confluent.ksql.rest.server.KsqlServerMain ./config/ksql-server.properties
If the KsqlServerMain
process isn’t shown, a different process has taken the
port that KsqlServerMain
would normally use. Check the assigned listeners in
the ksqlDB server configuration, and restart the ksqlDB CLI with the correct port.
Replicated topic with Avro schema causes errors?
Confluent Replicator renames topics during replication, and if there are
associated Avro schemas, they aren’t automatically matched with the renamed
topics.
In the ksqlDB CLI, the PRINT
statement for a replicated topic works, which shows
that the Avro schema ID exists in Schema Registry, and ksqlDB can deserialize
the Avro message. But CREATE STREAM
fails with a deserialization error:
CREATE STREAM pageviews_original (viewtime bigint, userid varchar, pageid varchar) WITH (kafka_topic='pageviews.replica', value_format='AVRO');
[2018-06-21 19:12:08,135] WARN task [1_6] Skipping record due to deserialization error. topic=[pageviews.replica] partition=[6] offset=[1663] (org.apache.kafka.streams.processor.internals.RecordDeserializer:86)
org.apache.kafka.connect.errors.DataException: pageviews.replica
at io.confluent.connect.avro.AvroConverter.toConnectData(AvroConverter.java:97)
at io.confluent.ksql.serde.connect.KsqlConnectDeserializer.deserialize(KsqlConnectDeserializer.java:48)
at io.confluent.ksql.serde.connect.KsqlConnectDeserializer.deserialize(KsqlConnectDeserializer.java:27)
The solution is to register schemas manually against the replicated subject name for the topic:
# Original topic name = pageviews
# Replicated topic name = pageviews.replica
curl -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" --data "{\"schema\": $(curl -s http://localhost:8081/subjects/pageviews-value/versions/latest | jq '.schema')}" http://localhost:8081/subjects/pageviews.replica-value/versions
Check ksqlDB server logs
If you’re still having trouble, check the ksqlDB server logs for errors:
confluent log ksql-server
Look for logs in the default directory at /usr/local/logs
or in the
LOG_DIR
that you assign when you start the ksqlDB CLI. For more info, see
Starting the ksqlDB CLI.