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

Issue #9944 - remove integer from demand in websocket core #9945

Merged
merged 3 commits into from
Jun 28, 2023

Conversation

lachlan-roberts
Copy link
Contributor

Remove the long argument from demand() in websocket core.

This had already been done for the new core Jetty WebSocket API.

@lachlan-roberts lachlan-roberts requested review from gregw and sbordet June 22, 2023 01:42
@lachlan-roberts lachlan-roberts self-assigned this Jun 22, 2023
@@ -152,14 +152,13 @@ public interface CoreSession extends OutgoingFrames, IncomingFrames, Configurati
void abort();

/**
* <p>Manages flow control by indicating demand for WebSocket frames.</p>
* <p>Manages flow control by indicating demand for a WebSocket frame.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behaviour for calling demand when there is already pending demand needs to be documented. You are currently internally tracking a long count, so you have effectively kept the long and could reproduce with:

   public void demand(long n)
   {
       for (long i = 0; i < n; i++)
           demand();
   }

I'm not sure this is optimal. Could we throw ISE if there is already pending demand?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think you need to javadoc in this PR what is the expected behaviour is of a demand call with pending demand... even if the actual behaviour is implemented in a different PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be ReadPendingException or IllegalStateException?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ReadPendingException extends IllegalStateException so either works.

@lachlan-roberts lachlan-roberts requested a review from gregw June 26, 2023 02:21
gregw
gregw previously requested changes Jun 26, 2023
@@ -152,14 +152,13 @@ public interface CoreSession extends OutgoingFrames, IncomingFrames, Configurati
void abort();

/**
* <p>Manages flow control by indicating demand for WebSocket frames.</p>
* <p>Manages flow control by indicating demand for a WebSocket frame.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think you need to javadoc in this PR what is the expected behaviour is of a demand call with pending demand... even if the actual behaviour is implemented in a different PR.

@@ -152,14 +152,13 @@ public interface CoreSession extends OutgoingFrames, IncomingFrames, Configurati
void abort();

/**
* <p>Manages flow control by indicating demand for WebSocket frames.</p>
* <p>Manages flow control by indicating demand for a WebSocket frame.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ReadPendingException extends IllegalStateException so either works.

@@ -110,7 +110,8 @@ protected void demand()
Frame frame = serverHandler.receivedFrames.poll(250, TimeUnit.MILLISECONDS);
assertNull(frame);

serverHandler.getCoreSession().demand(2);
serverHandler.getCoreSession().demand();
serverHandler.getCoreSession().demand();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong, as the second call should throw.
If it's not causing flakyness, needs a comment explaining why.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments from #9945 (comment)

I have opened #9965 to change the implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the next PR these should fail and I will need to change them.

Hopefully that will make beta3 as well, but if not at least we have the API changed with this.

coreSession.demand(3);
coreSession.demand();
coreSession.demand();
coreSession.demand();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@@ -307,7 +310,8 @@ public void onOpen(CoreSession coreSession, Callback callback)
{
super.onOpen(coreSession);
callback.succeeded();
coreSession.demand(2);
coreSession.demand();
coreSession.demand();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@@ -375,7 +379,8 @@ public void onOpen(CoreSession coreSession, Callback callback)
{
super.onOpen(coreSession);
callback.succeeded();
coreSession.demand(2);
coreSession.demand();
coreSession.demand();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@sbordet sbordet self-requested a review June 28, 2023 15:48
@lachlan-roberts lachlan-roberts merged commit 0941969 into jetty-12.0.x Jun 28, 2023
@lachlan-roberts lachlan-roberts deleted the jetty-12.0.x-WebSocketDemand branch June 28, 2023 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants