Hey guys, we were running pulsar 2.11 and after up...
# general
m
Hey guys, we were running pulsar 2.11 and after upgrade to 3.0.0, all tests fail, we get errors like "topic not found" or "namespace not found". Did something change? Are topics/namespaces setup differently now?
l
One possible reason could be a known problem that metadata changes are eventually consistent to some level in Pulsar. If a test creates a namespace or topic and immediately attempts to access it, it might result in the problem that you are describing. Unfortunately, the work around is to add a short delay or add polling to ensure that the creation has completed before proceeding in the test. This known issue has been well described in this issue comment: https://github.com/apache/pulsar/issues/12555#issuecomment-955748744 It would be helpful if you could isolate a reproducer. It could be files in a GitHub gist or a separate repo that reproduces the problem in isolation.
m
The test runs in a single node, so it should always be consistent, right?
l
The test runs in a single node, so it should always be consistent, right?
That's a fair assumption, but it might apply also to the single node case.
There might be something else that is wrong if all tests fail.
What type of test setup do you have? Java client? Are you using Testcontainers? etc.
Which Pulsar client and broker version?
m
No, it's the default pulsar image, and I've seen failure from Java client when creating consumer, and Python client, when creating producer.
3.0.3
The Java client fails with:
Copy code
2024-03-28T11:27:35,495+0000 [pulsar-io-19-1] WARN  org.apache.pulsar.broker.web.PulsarWebResource - Namespace public/default not found

2024-03-28T11:27:35,564+0000 [pulsar-io-19-1] WARN  org.apache.pulsar.broker.service.ServerCnx - Failed to get Partitioned Metadata [/172.17.0.1:44748] <persistent://public/default/connection-test>: Namespace not found
l
ok, this happens when Pulsar isn't yet fully started.
How do you start the container and ensure that it's fully started? Do you use Testcontainers at all?
m
No, not using test containers
checking for 200 for /admin/v2/clusters endpoint is the main solution there.
m
Yes, I had a loop trying to create a test topic and this exception is now not being caught by that loop. So it seems before we would return some other exception in this case, and now we are return TopicNotFound (which I was not handling). Let me add that to the catch statement and see if that works
l
If you don't use functions and/or statestore, it's worth disabling those in the container to reduce resource consumption and ensure faster startup. Memory parameters aren't very good either. Those might be causing issues with 3.x since ZGC is the default.
m
thanks
is it safe to disable these in production as well?
what is statestore?
l
The memory issue can be handled by passing PULSAR_MEM=-Xmx512M and PULSAR_GC=-XX:+UseG1GC environment to the container.
🙏 1
is it safe to disable these in production as well?
yes and you should disable Pulsar Functions for production since it is hard to secure it properly. The default was recently changed for Apache Pulsar Helm chart in https://github.com/apache/pulsar-helm-chart/pull/483. btw. Pulsar standalone isn't recommended for production usage.
m
yep, catching the TopicNotFound in my ready loop solved it... thanks! :)
oh we don't use that in production
but I assume it's also enabled by default in production?
l
m
ah yep, I remember this
l
but I assume it's also enabled by default in production?
which deployment option do you use? Function worker is disabled by default in broker.conf , but enabled by default for Pulsar standalone.
m
ok, then it's already off by default
thanks
been a while since I look at pulsar setup... it's been problem free for over 2 years now 🙂
pulsarlogo 1
l
Another tip for standalone is to select to use Zookeeper instead of the Rocksdb based metadata store. https://github.com/apache/pulsar/discussions/20985#discussioncomment-8951010
🙏 1