Skip to content
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

[service-bus] Adjust receiveMessages() to match .NET's algorithm (with potential adjustments) #9718

Closed
5 tasks
richardpark-msft opened this issue Jun 25, 2020 · 1 comment
Assignees
Labels
blocking-release Blocks release Client This issue points to a problem in the data-plane of the library. Service Bus
Milestone

Comments

@richardpark-msft
Copy link
Member

richardpark-msft commented Jun 25, 2020

Currently the receiveMessages() call in JavaScript works differently than the .NET algorithm. As part of making our libraries more consistent we'd like to change that.

The existing behavior:

  1. User calls receiveMessages(numMessages, maxTime)
  2. Timer is set for maxTime
  3. as messages are received we continually debounce a timer for 1 second

We return if:

  • The debounced timer expires
  • numMessages has been reached
  • The maxTime has expired

In .NET the behavior is similar with slight differences that we would like to closely match:

  1. User calls receiveMessages(numMessages, maxTime)
  2. Timer is set for maxTime
  3. On receipt of first message set an absolute timer (no debounce) for 20 milliseconds

We return if:

  • The absolute timer expires
  • numMessages has been reached
  • The maxTime has expired

The work shouldn't be too bad since some of the same behaviors were already present. To do this work we will need:

  • Algorithm adjustment for batch receiver
    • Non-sessions
    • Sessions
  • Coordinated doc string update to describe the behavior, at least in regards to how maxWaitTime works.
  • Adjustment of the above timeout (possible). .NET's 20 milliseconds works well but they also have some other mitigating factors (background fetch into a buffer, etc..). It might still work for JS but we might want to stick with 1 second.

CC: @JoshLove-msft (to make sure my .NET description is accurate)

@ghost ghost added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Jun 25, 2020
@richardpark-msft richardpark-msft added Client This issue points to a problem in the data-plane of the library. Service Bus labels Jun 25, 2020
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Jun 25, 2020
@richardpark-msft richardpark-msft self-assigned this Jun 25, 2020
@ramya-rao-a ramya-rao-a added this to the [2020] July milestone Jun 26, 2020
@ramya-rao-a ramya-rao-a added the blocking-release Blocks release label Jul 14, 2020
richardpark-msft added a commit that referenced this issue Jul 16, 2020
…9968)

Changing our receiveMessages() algorithm to match .NET's.

The new version works like this:
receive(maxMessages, maxWaitTime)

Internally we then wait for:
1. maxMessages to arrive
2. maxWaitTime to expire
or
3. An internal 1 second timeout that will fire _after_ the first message
   has been received _or_ the remaining time left from `maxWaitTime` (whichever one
   is smaller)

1/2 of the code for #9718
richardpark-msft added a commit that referenced this issue Jul 17, 2020
…sages algorithm (#10107)

[sessions] Changing our receiveMessages() algorithm to match .NET's.

The new version works like this:

receive(maxMessages, maxWaitTime)

Internally we then wait for:

  maxMessages to arrive
  maxWaitTime to expire
  or
  An internal 1 second timeout that will fire after the first message has been received or 
  the remaining time left from maxWaitTime (whichever one is smaller)

(also eliminated some dead code as a result of making SessionManager a sample rather
 than being part of the core library)

Complements #9968 and is the final change for #9718
@richardpark-msft
Copy link
Member Author

With the merge of #9968 and #10107 this is now complete.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocking-release Blocks release Client This issue points to a problem in the data-plane of the library. Service Bus
Projects
None yet
Development

No branches or pull requests

2 participants