blankensteiner commented on PR #207: URL: https://github.com/apache/pulsar-dotpulsar/pull/207#issuecomment-2014610084
> It currently is not possible to check current state, which was the purpose of [this change](https://github.com/apache/pulsar-dotpulsar/pull/207/files#diff-dd82a6892bf52f24ca2167d247198fbd63b6126383a09abb28280636ab8303bbR66). Also, this allows a consistent method for checking that covers both readers and consumers, which seems to line up with the purpose of the IReceive interface. Should I move the changes to IStateChanged to a separate PR? Should I remove this method in favor of just allowing checking the current state? Exposing a CurrentState property is doable, but I am a bit worried that people will use it instead of monitoring the state, which is what they really should be doing. When monitoring the state, changes are pushed to the user, instead of the user having to poll them by calling CurrentState. I have seen people wait for the state to change to "Connected" before using the producer (calling Send) or consumer/reader (calling Receive), but that makes no sense. As mentioned above, checking the state or asking if there are messages doesn't ensure that the following usage will succeed, because much can chance in the milliseconds before you get around to using the producer/consumer/reader. So the user should just call Send/Receive and if blocking is an issue, just set a timer on the cancellation token. > The Java Client actually makes a call to GetLastMessageId to determine if the server has any additional messages that could be downloaded. Regarding "asking the broker if there are new messages", I have no idea why the other clients would do that (if that is the case) since messages are pushed from the broker to DotPulsar as soon as the broker gets them. So if there are any messages, DotPulsar already have them buffered. Creating TryReceive as an extension method is also doable and could make sense, would that float your boat? :-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
