2020-03-12 16:20:05 UTC - Konstantinos Papalias: Do we have any Pulsar Docker images build against jdk 11? ---- 2020-03-12 17:06:35 UTC - Sijie Guo: Currerntly we don’t. Because the project currently is still built under java8. heavy_check_mark : Konstantinos Papalias ---- 2020-03-12 17:57:07 UTC - Ryan: I agree with Luke Lu, we need to have Backlog settings independent of Retention, because we have massive ingest volumes and use Backlog to ensure storage of messages during a system outage which is independent of Retention. ---- 2020-03-13 08:08:02 UTC - Vladimir Shchur: Hi, it seems I've found a suspicious logic of cumulative acks <https://github.com/apache/pulsar/blob/v2.5.0/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConsumerImpl.java#L447-L453>. There are three issues with this code: 1. It only acks one previous batch, two or more previous batches will remain unacked 2. There will be always an extra ack call even if all previous batches are acked, which is performance hit. 3. onAcknowledge is called instead of onAcknowledgeCumulative even if ack type is Cumulative, also it should be moved out of else block to be called without any conditions Should I create github issue or all of that is by design? ---- 2020-03-13 08:14:53 UTC - Atif: @Eugen @Ali Ahmed
So some ways that we managed to convince our clients and ourselves was-: 1.Multi tenancy is a very useful thing to have in the context of limiting boundaries between teams and lessening impact of deploying and developing things in parallel.A spike in usage of a few topics in Kafka can bring down the system if one isnt careful - pulsar has resource quotas. For Kafka we recommend different teams in an enterprise environments to have their own separate clusters. With Pulsar you can have these teams piggy back on another cluster till their use cases get meaningful enough to start separating. 2.Day to day chores like rebalancing etc are much more simpler.Also it gives you faster ramp up time and low development effort compared to Kafka owing to its rich featureset Another issue we ran into here is that Pulsar uses a lot of moving parts underneath and while day to day maintenance is slightly easier. Debugging issues spanning across all of its components is very hard. 3.Tiered infinite storage gives you a lot of flexibility around evolving your topic schemas and having consumers connect at a future point in time but still being able to receive all their data. With Kafka you can do this but is not an easy concern if you have large datasets 4.One thing devs didnt like about Pulsar is the code maturity. Initially starting out we wanted to analyze the code base and we had a lot of trouble getting things up and running and getting the code to build. We found the codebase well organized but not well maintained.Flaky tests and race condition issues, lot of PRs open from a long time however the community here is active but is limited to a few set of contributors we see. Hopefully this will improve over time.Some deployment guides, best practices particularly around security will also help. ----
