Pulsar SQL is (still/again?) not able to read the latest message

[AntiBit82]

Describe the bug
Referring to bug
#3828
#4976
which was fixed in
#5822

I'm still having this exact problem.

Steps to reproduce
Running Pulsar standalone 2.9.1 on EC2.
In /home/ec2-user/apache-pulsar-2.9.1/conf/broker.conf
I set the value according to the fix:
bookkeeperExplicitLacIntervalInMills=10

Restart Pulsar.
Spawn ./pulsar sql-worker run

Event sending:
I parse a CSV file and send the records to Pulsar like this:
1.) Create Pulsar client + producer
2.) Read Csv line by line, map to PoJo, send via producer (async) + save returned CompletableFuture
3.) Make sure all CompletableFutures complete by calling completableFutures.forEach(CompletableFuture::join);
4.) Close pulsar producer & pulsar client

Afterwards when I query my topic via Pulsar SQL I'm missing the last record (sometimes I'm missing even more records than only the last record).
This is true until I parse the CSV again and send it, then the previous missing records are there in Pulsar SQL query, but ofc the new last record is missing...

Now, since parsing lines and sending them are fast operations, I also tried to add some delay between the sending of each record (Thread.sleep(20), even Thread.sleep(1000)). Even then the issue remains.

Question
Is there anything I can check to see if the
bookkeeperExplicitLacIntervalInMills=10
setting is actually in effect?

Do you need more explanation?

[zymap]

By default, pulsar sql won't get the last message in the topic. If you want to
get the last message, you need to configure the following configurations.
For the broker config, you need to set bookkeeperExplicitLacIntervalInMills.
For the Presto config, you need to set pulsar.bookkeeper-use-v2-protocol=false and pulsar.bookkeeper-explicit-interval.
Then you should get the last message from sql.

[AntiBit82]

pulsar.bookkeeper-use-v2-protocol=false and pulsar.bookkeeper-explicit-interval

Unfortunately the issue still persists.

My settings now:

apache-pulsar-2.9.1/conf/broker.conf
bookkeeperExplicitLacIntervalInMills=10

apache-pulsar-2.9.1/conf/presto/catalog/pulsar.properties
pulsar.bookkeeper-use-v2-protocol=false
pulsar.bookkeeper-explicit-interval=10

Still I am not receiving all of the records in the topic.
I'm also making sure the topic really contains my records using a Reader, which shows all of them.

[zymap]

I tried it locally with 2.9.1, everything works fine.

Can you try to produce by pulsar client cmd, bin/pulsar-client produce test1 -m "hello" and then query the test1 topic in the pulsar SQL?

[AntiBit82]

Yes I did that now, and the results are the same: The sql lags 1 record behind, doesn't show the latest...
./pulsar-client produce sqltest -m "hello" -k "test_1"

presto> select * from pulsar."public/default".sqltest; __value__ | __partition__ | __event_time__ | __publish_time__ | __message_id__ | __sequence_id__ | __producer_name__ | __key__ | __properties__ -----------+---------------+----------------+------------------+----------------+-----------------+-------------------+---------+---------------- (0 rows)

./pulsar-client produce sqltest -m "hello" -k "test_2"

presto> select * from pulsar."public/default".sqltest; __value__ | __partition__ | __event_time__ | __publish_time__ | __message_id__ | __sequence_id__ | __producer_name__ | __key__ | __properties__ ----------------+---------------+-------------------------+-------------------------+----------------+-----------------+-------------------+---------+---------------- 68 65 6c 6c 6f | -1 | 1970-01-01 00:00:00.000 | 2022-02-23 14:08:41.905 | (2409,0,0) | 0 | standalone-6-7 | test_1 | {} (1 row)

So I guess it has to be some configuration problem then?
Can I somehow check if the settings I've mentioned a post above are even in effect?

[zymap]

There have some logs when starting the component, you may check that configurations are applied in the logs

[emacsist]

if you run standalone mode, you should update conf/standalone.conf not conf/broker.conf
after that , I got the latest message.

[github-actions]

The issue had no activity for 30 days, mark with Stale label.

[github-actions]

The issue had no activity for 30 days, mark with Stale label.

[tisonkun]

Closed as stale. Feel free to open a new issue if it's still relevant for maintained versions.