> I think we are talking about the durable subscription of the non-persistent > topic, right?
Yes, non-durable subscriptions created by Reader, if the reader disconnected, the subscription will be deleted automatically. For `NonPersistentDispatcher`, it has the following implementations: 1. NonPersistentDispatcherMultipleConsumers 2. NonPersistentDispatcherSingleActiveConsumer 3. NonPersistentStickyKeyDispatcherMultipleConsumers For `NonPersistentDispatcherSingleActiveConsumer`, auto delete the subscription when there isn’t consumer connected affect nothing. But for `NonPersistentDispatcherMultipleConsumers`, `NonPersistentStickyKeyDispatcherMultipleConsumers`, I’m not sure that if it matters when we auto delete the subscriptions which has no consumers connected. If it doesn’t matter, I agree with you. Auto delete the durable subscriptions when there aren’t consumers connected to the non-persistent topic. Thanks, Tao Jiuming > 2023年2月7日 19:58，PengHui Li <peng...@apache.org> 写道： > > I think we are talking about the durable subscription of the non-persistent > topic, right? For the Reader API (non-durable subscription), the > subscription will be > removed after the reader disconnects. If not, it should be BUG. > > IMO, we should remove the subscription automatically if all the consumers > are disconnected for the non-persistent topic. The consumers can only get > the new incoming messages after they connect to the non-persistent topic. > It looks like even if we leave the subscription there; it will > help nothing. > The behavior should be the same as creating a new subscription with the > same subscription name. > > For subscription management, users are not able to disable the subscription > auto-creation of the non-persistent topic? We don't have any metadata > persist > in the metadata store. After the broker restarts, we will lose everything. > > So I think we don't need to introduce a new configuration. Instead, we > should > figure out if there is a strong reason to leave the durable subscription > after > all the consumers are disconnected. If there is no strong reason, I tend to > fix > incorrect behavior directly. > > Best, > Penghui > > > > > On Tue, Feb 7, 2023 at 4:14 PM Jiuming Tao <jm...@streamnative.io.invalid > <mailto:jm...@streamnative.io.invalid>> > wrote: > >> Hi, >> >> I’ve opened a new PIP to discuss: >> >> Currently, in Pulsar, we have a configuration named >> `subscriptionExpirationTimeMinutes` to manage the subscription expiration >> of `PersistentTopic` and `NonPersistentTopic`. >> >> When we set a value which is greater than 0 to >> `subscriptionExpirationTimeMinutes`, it will affect both `PersistentTopic` >> and `NonPersistentTopic`. Their inactive subscriptions will get expired and >> will clean automatically. >> >> For `NonPersistentTopic`, its subscriptions can be clean because we don't >> guarantee its data integrity. But for `PersistentTopic`, if we clean its >> subscriptions automatically may lead to data loss. >> >> However, their subscription expiration is managed by the same >> configuration(`subscriptionExpirationTimeMinutes`), we can't manage their >> subscription expiration independently. >> >> So I want to introduce a new configuration named >> `nonPersistentSubscriptionExpirationTimeMinutes` to manage >> `NonPersistentTopic`'s subscription expiration. >> >> >> Please feel free to leave your comments, the PIP link: >> https://github.com/apache/pulsar/issues/19448 < >> https://github.com/apache/pulsar/issues/19448 >> <https://github.com/apache/pulsar/issues/19448>> >> >> >> Thanks, >> Tao Jiuming
