Dashboard persistent subscriber enhancements

[p10tyr]

Could you please look at adding some more fine grain information to the persistent subscriber page.

It would be nice to see the a row for each connection with data like

• client name/ip / ID?
• number of parked messages
• reset queue button (replay messages from 0)
• move replay parked messages button to this new row

My main reason is really just being able to see how many messages have been parked for a connection

I also realised once I start adding more persistent subscribers I would not really know which one has parked messages.

Also while doing some dev work I would like to reset a subscriber to 0 so I could have and easy "replay" function for that specific subscriber. Although I realise that may be stretching it a bit far it would save me time spinning up a replay client each time I am doing some changes. It would be a nice to have.

Thanks

[StevenBlair123]

I was going to create a new feature request for something related, but this issue appeared so thought I would add it here.
Would it be possib le to include a "View Parked Queue" button on the persistent subscriotion page for each group?

I can never remeber the url route into the various parked queues, so this would help us out a lot!

[gregoryyoung]

For setting to zero ... you can just bring up a new subscription no? This might be a better alternative depending on the precise use case. Resetting to zero without a destroy/recreate could actually get a bit ... odd. Think about as example coordination of you are currently processing event 2849 but then a reset occurs. Does that mean you have processed or reprocessed 2849? Its not that this is impossible, it is that it likely wants a bit more thought as there are some odd edge conditions. Re: parked messages, they are not associated to the "client" per se though we could keep this information, and it might even be useful, they are associated to the subscription as a whole. It would be easy enough (as in < an hour) to add a counter here to associate to the stats. Can you detail a use case of how you want to use this?

…

On Fri, Feb 4, 2022 at 4:27 AM Piotr Kula ***@***.***> wrote: Could you please look at adding some more fine grain information to the persistent subscriber page. It would be nice to see the a row for each connection with data like - client name/ip / ID? - *number of parked messages* - reset queue button (replay messages from 0) - move replay parked messages button to this new row My main reason is really just being able to see *how many messages have been parked* for a connection I also realised once I start adding more persistent subscribers I would not really know which one has parked messages. Also while doing some dev work I would like to reset a subscriber to 0 so I could have and easy "replay" function for that specific subscriber. Although I realise that may be stretching it a bit far it would save me time spinning up a replay client each time I am doing some changes. It would be a nice to have. Thanks — Reply to this email directly, view it on GitHub <#308>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC5CWXMV63TPN2KD6EVWCLUZOLXHANCNFSM5NRIDI4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Studying for the Turing test

[p10tyr]

If you keep track of what is processed and not then it’s a non issue. Also I think in my case it was for rehydration or maybe rebuilding databases. So I just wanted to restart.

…

On 4 Feb 2022, at 09:50, Greg Young ***@***.***> wrote:  For setting to zero ... you can just bring up a new subscription no? This might be a better alternative depending on the precise use case. Resetting to zero without a destroy/recreate could actually get a bit ... odd. Think about as example coordination of you are currently processing event 2849 but then a reset occurs. Does that mean you have processed or reprocessed 2849? Its not that this is impossible, it is that it likely wants a bit more thought as there are some odd edge conditions. Re: parked messages, they are not associated to the "client" per se though we could keep this information, and it might even be useful, they are associated to the subscription as a whole. It would be easy enough (as in < an hour) to add a counter here to associate to the stats. Can you detail a use case of how you want to use this? On Fri, Feb 4, 2022 at 4:27 AM Piotr Kula ***@***.***> wrote: > Could you please look at adding some more fine grain information to the > persistent subscriber page. > > It would be nice to see the a row for each connection with data like > > - client name/ip / ID? > - *number of parked messages* > - reset queue button (replay messages from 0) > - move replay parked messages button to this new row > > My main reason is really just being able to see *how many messages have > been parked* for a connection > > I also realised once I start adding more persistent subscribers I would > not really know which one has parked messages. > > Also while doing some dev work I would like to reset a subscriber to 0 so > I could have and easy "replay" function for that specific subscriber. > Although I realise that may be stretching it a bit far it would save me > time spinning up a replay client each time I am doing some changes. It > would be a nice to have. > > Thanks > > — > Reply to this email directly, view it on GitHub > <#308>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAC5CWXMV63TPN2KD6EVWCLUZOLXHANCNFSM5NRIDI4Q> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> > -- Studying for the Turing test — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.

[gregoryyoung]

So the whole point of a persistent subscription is to keep track of what's been done and support things such as retry etc strategies as well as the ability to "fan out" work to multiple subscribers in varying ways. When dealing with say a read model and rebuilds you would generally prefer to be using a catchup subscription, there is assured ordering on this type of subscription which persistent subscriptions doesn't really offer (you can get kind of close but the catchupsubscription will do a better job). You can use a catchupsubscription with the subscribeToAllFrom/subscribeToStreamFrom/etc methods on the connection.

…

On Fri, Feb 4, 2022 at 2:21 PM Piotr Kula ***@***.***> wrote: If you keep track of what is processed and not then it’s a non issue. Also I think in my case it was for rehydration or maybe rebuilding databases. So I just wanted to restart. > On 4 Feb 2022, at 09:50, Greg Young ***@***.***> wrote: > >  > For setting to zero ... you can just bring up a new subscription no? This > might be a better alternative depending on the precise use case. Resetting > to zero without a destroy/recreate could actually get a bit ... odd. Think > about as example coordination of you are currently processing event 2849 > but then a reset occurs. Does that mean you have processed or reprocessed > 2849? Its not that this is impossible, it is that it likely wants a bit > more thought as there are some odd edge conditions. > > Re: parked messages, they are not associated to the "client" per se though > we could keep this information, and it might even be useful, they are > associated to the subscription as a whole. It would be easy enough (as in < > an hour) to add a counter here to associate to the stats. Can you detail a > use case of how you want to use this? > > On Fri, Feb 4, 2022 at 4:27 AM Piotr Kula ***@***.***> wrote: > > > Could you please look at adding some more fine grain information to the > > persistent subscriber page. > > > > It would be nice to see the a row for each connection with data like > > > > - client name/ip / ID? > > - *number of parked messages* > > - reset queue button (replay messages from 0) > > - move replay parked messages button to this new row > > > > My main reason is really just being able to see *how many messages have > > been parked* for a connection > > > > I also realised once I start adding more persistent subscribers I would > > not really know which one has parked messages. > > > > Also while doing some dev work I would like to reset a subscriber to 0 so > > I could have and easy "replay" function for that specific subscriber. > > Although I realise that may be stretching it a bit far it would save me > > time spinning up a replay client each time I am doing some changes. It > > would be a nice to have. > > > > Thanks > > > > — > > Reply to this email directly, view it on GitHub > > <#308>, or unsubscribe > > < https://github.com/notifications/unsubscribe-auth/AAC5CWXMV63TPN2KD6EVWCLUZOLXHANCNFSM5NRIDI4Q> > > . > > Triage notifications on the go with GitHub Mobile for iOS > > < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > > or Android > > < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > > > You are receiving this because you are subscribed to this thread.Message > > ID: ***@***.***> > > > > > -- > Studying for the Turing test > — > Reply to this email directly, view it on GitHub, or unsubscribe. > Triage notifications on the go with GitHub Mobile for iOS or Android. > You are receiving this because you authored the thread. — Reply to this email directly, view it on GitHub <#308 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC5CWS472OEIHXDYOYRA2DUZQRLHANCNFSM5NRIDI4Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

-- Studying for the Turing test

[p10tyr]

That does make sense. I think I raised this a few years ago so can’t quite remember exactly the issue. Maybe I was being pedantic about the approach.

…

On 4 Feb 2022, at 20:05, Greg Young ***@***.***> wrote:  So the whole point of a persistent subscription is to keep track of what's been done and support things such as retry etc strategies as well as the ability to "fan out" work to multiple subscribers in varying ways. When dealing with say a read model and rebuilds you would generally prefer to be using a catchup subscription, there is assured ordering on this type of subscription which persistent subscriptions doesn't really offer (you can get kind of close but the catchupsubscription will do a better job). You can use a catchupsubscription with the subscribeToAllFrom/subscribeToStreamFrom/etc methods on the connection. On Fri, Feb 4, 2022 at 2:21 PM Piotr Kula ***@***.***> wrote: > If you keep track of what is processed and not then it’s a non issue. > Also I think in my case it was for rehydration or maybe rebuilding > databases. So I just wanted to restart. > > > On 4 Feb 2022, at 09:50, Greg Young ***@***.***> wrote: > > > >  > > For setting to zero ... you can just bring up a new subscription no? > This > > might be a better alternative depending on the precise use case. > Resetting > > to zero without a destroy/recreate could actually get a bit ... odd. > Think > > about as example coordination of you are currently processing event 2849 > > but then a reset occurs. Does that mean you have processed or > reprocessed > > 2849? Its not that this is impossible, it is that it likely wants a bit > > more thought as there are some odd edge conditions. > > > > Re: parked messages, they are not associated to the "client" per se > though > > we could keep this information, and it might even be useful, they are > > associated to the subscription as a whole. It would be easy enough (as > in < > > an hour) to add a counter here to associate to the stats. Can you detail > a > > use case of how you want to use this? > > > > On Fri, Feb 4, 2022 at 4:27 AM Piotr Kula ***@***.***> wrote: > > > > > Could you please look at adding some more fine grain information to > the > > > persistent subscriber page. > > > > > > It would be nice to see the a row for each connection with data like > > > > > > - client name/ip / ID? > > > - *number of parked messages* > > > - reset queue button (replay messages from 0) > > > - move replay parked messages button to this new row > > > > > > My main reason is really just being able to see *how many messages > have > > > been parked* for a connection > > > > > > I also realised once I start adding more persistent subscribers I > would > > > not really know which one has parked messages. > > > > > > Also while doing some dev work I would like to reset a subscriber to 0 > so > > > I could have and easy "replay" function for that specific subscriber. > > > Although I realise that may be stretching it a bit far it would save > me > > > time spinning up a replay client each time I am doing some changes. It > > > would be a nice to have. > > > > > > Thanks > > > > > > — > > > Reply to this email directly, view it on GitHub > > > <#308>, or > unsubscribe > > > < > https://github.com/notifications/unsubscribe-auth/AAC5CWXMV63TPN2KD6EVWCLUZOLXHANCNFSM5NRIDI4Q> > > > > . > > > Triage notifications on the go with GitHub Mobile for iOS > > > < > https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > > > > or Android > > > < > https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > > > > > > You are receiving this because you are subscribed to this > thread.Message > > > ID: ***@***.***> > > > > > > > > > -- > > Studying for the Turing test > > — > > Reply to this email directly, view it on GitHub, or unsubscribe. > > Triage notifications on the go with GitHub Mobile for iOS or Android. > > You are receiving this because you authored the thread. > > — > Reply to this email directly, view it on GitHub > <#308 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAC5CWS472OEIHXDYOYRA2DUZQRLHANCNFSM5NRIDI4Q> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you commented.Message ID: > ***@***.***> > -- Studying for the Turing test — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.