You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pulsar.apache.org by Apache Pulsar Slack <ap...@gmail.com> on 2019/11/15 09:11:04 UTC
Slack digest for #general - 2019-11-15
2019-11-14 12:36:37 UTC - John Latties: @John Latties has joined the channel
----
2019-11-14 16:18:17 UTC - Ryan Samo: Hey guys, I’m looking at tiered storage and I see that it talks about offloading only the backlog of a namespace in the docs. Does this also include the TTL and retention settings for the namespace as well?
----
2019-11-14 17:49:54 UTC - Oleg Golberg: @Oleg Golberg has joined the channel
----
2019-11-14 18:20:45 UTC - Naveen Kumar: How can I set the producer compressionType in debezium postgres connector? What's the default compressionType when using that connector and how to change it when need to?
----
2019-11-14 19:00:49 UTC - Debasish Mallick: @Debasish Mallick has joined the channel
----
2019-11-14 19:21:17 UTC - Johnny Graettinger: @Johnny Graettinger has joined the channel
----
2019-11-14 20:28:20 UTC - Lari Hotari: Hi, I have a question about delayed / scheduled message delivery.
What are the plans for "A persistent hash-wheel based implementation" and how scalable is the current in-memory solution? Can it be used as a generic task scheduler for hundreds of events per second (per topic/partition)?
This is mentioned in the blog post (<https://medium.com/streamnative/whats-new-in-apache-pulsar-2-4-0-d646f6727642>):
>>> The current DelayedDeliveryTracker holds the delayed messages in an in-memory priority queue. So you have to plan for the memory usage when enabling the delayed delivery feature. A persistent hash-wheel based implementation was discussed in the community and is planned to add in the future to support a wider range of delay durations.
----
2019-11-14 22:51:59 UTC - Nicolas Ha: I didn’t know the “cluster” part of the topic naming was deprecated in pulsar 2.x
However now when I try to remove it I get a `Policies not found for app/mytopic namespace` Exception. What could be the reason?
----
2019-11-14 22:59:02 UTC - Matteo Merli: The implementation is reasonably efficient. The tracking of delayed messages is done off-heap to avoid impact from JVM GC and the per-message overhead is minimal
----
2019-11-14 22:59:14 UTC - Matteo Merli: eg: 16 bytes per message
----
2019-11-15 05:41:12 UTC - Lari Hotari: Ok, thanks for the reply. Are there some performance tests for delayed message delivery that would be help in understanding the performance characteristics?
----