-
Notifications
You must be signed in to change notification settings - Fork 534
Clarification on multiple subscribers needed .. #284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @RuedigerMoeller, thanks a lot for catching this - you're absolutely correct. |
Thanks for the quick response :). Kudos for the test suite, it discovered an awful lot of issues in my initial implementation .. |
…" Processor in TCK
…" Processor in TCK
…" Processor in TCK
…" Processor in TCK
…" Processor in TCK
Addressed one part of the issue in this PR: #287 Thanks again for reporting! Such reports are super useful in making the tests generally useful for all future implementers :-) |
Hi, afair |
…" Processor in TCK
…" Processor in TCK
…" Processor in TCK
@ktoso Was this fixed and merged? |
@ktoso Sorry, I see the PR… |
Yeap, it's that one which I need to get back to: #287 |
@RuedigerMoeller Please see #414. Will be released in 1.0.2 which is due before end-of-year! |
I implemented multiple subscribers using a "wait-for-slowest-subscriber" policy. This means if of 2 subscribers only one sends "credits" via request(N), no message will be sent. So credits = Min(credits of subscribers)
this makes
required_mustRequestFromUpstreamForElementsThatHaveBeenRequestedLongAgo()
and
required_spec104_mustCallOnErrorOnAllItsSubscribersIfItEncountersANonRecoverableError()
fail.But "wait-for-slowest-subscriber" (with optional timout/forced cancel policy) actually does not violate the spec, isn't it ?
The text was updated successfully, but these errors were encountered: