2020-03-07 09:52:41 UTC - Vladimir Shchur: It's client option <https://github.com/apache/pulsar/blob/master/pulsar-client-api/src/main/java/org/apache/pulsar/client/api/ConsumerBuilder.java#L183> ---- 2020-03-07 10:07:35 UTC - Jan-Pieter George: Right, but that’s for the cases the client still is in control. For the cases where it isn’t (network disruptions, crashes etc) the client won’t be able to communicate back. ---- 2020-03-07 10:46:41 UTC - Vladimir Shchur: @Chris Bartholomew thank you, I was able to make it work with your images! ---- 2020-03-07 10:49:02 UTC - dbartz: Does that means that at the broker level you can only choose the rentention period of the messages and it is the full responiblility of the client to manage redelivery of un-acked messages ? ---- 2020-03-07 10:56:00 UTC - Vladimir Shchur: <https://github.com/apache/pulsar/blob/master/conf/broker.conf#L754> - this is the setting for keep alive frequency. If keep alive request fails then broker abandons the connection. Once consumer is reconnected all unacked messages will be redelivered +1 : Jan-Pieter George ---- 2020-03-07 11:53:01 UTC - Jan-Pieter George: Interesting, that could be the behavior we saw. What if a client never acks a specific message but keeps the alive interval up? Will it redeliver only whenever it naturally reconnects (on a new startup of app/consumer/whatever)? ---- 2020-03-07 12:39:10 UTC - Vladimir Shchur: If connection is always on, the AckTimeout comes into play on client side ---- 2020-03-07 14:42:54 UTC - Jan-Pieter George: But what if the client doesn’t timeout the ack and reconnects? A client that never gets a timeout back to the broker? ---- 2020-03-07 15:34:03 UTC - Vladimir Shchur: On reconnect messages will be redelivered ---- 2020-03-07 16:21:58 UTC - Gilles Barbier: Is there a timeframe associated (even non-binding) ? ---- 2020-03-07 19:16:22 UTC - Sijie Guo: Currently we are running a time-based release plan - <https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan> ---- 2020-03-07 20:03:31 UTC - Ed: @Ed has joined the channel ----
