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

[msg] Do not Close singleton MessageProcessors when closing connections #3934

Merged
merged 5 commits into from
Nov 20, 2021

Conversation

ryanhall07
Copy link
Collaborator

This fixes a regression that was introduced in #3918

The shared singleton MessageProcessor was being closed when a Connection
was being closed.

Now a Pool interface is introduced. A MessageProcessor is fetched when a
Connection is created and returned when a Connection is closed. It is up
to the pool impl to decide if it should Close the MessageProcessor on
each return or only when the pool is closed.

What this PR does / why we need it:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing and/or backwards incompatible change?:


Does this PR require updating code package or user-facing documentation?:


This fixes a regression that was introduced in #3918

The shared singleton MessageProcessor was being closed when a Connection
was being closed.

Now a Pool interface is introduced. A MessageProcessor is fetched when a
Connection is created and returned when a Connection is closed. It is up
to the pool impl to decide if it should Close the MessageProcessor on
each return or only when the pool is closed.
@@ -63,27 +63,35 @@ func TestServerWithMessageFn(t *testing.T) {
s := server.NewServer("a", NewMessageHandler(SingletonMessageProcessor(p), opts), server.NewOptions())
s.Serve(l)

conn, err := net.Dial("tcp", l.Addr().String())
conn1, err := net.Dial("tcp", l.Addr().String())
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this test fails without the fix (too many calls to MessageProcessor.Close)

// in a connection.
type NewMessageProcessorFn func() MessageProcessor
// MessageProcessorPool returns MessageProcessors.
type MessageProcessorPool interface {
Copy link
Collaborator

@rallen090 rallen090 Nov 19, 2021

Choose a reason for hiding this comment

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

IMO a bit confusing using the name "pool" here since it isn't actually pooling anything, just controlling if the provided processor itself should get closed or not.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

well the singleton is definitely pooling. do you have another naming suggestion?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe change to Provider - also maybe remove Put and just have the provider differences be: singleton wraps a processor such that it's Close is no-op; otherwise provider gives a new processor that has a real Close.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yea i originally had a wrapper that did nothing on Close. To me that seemed weird since it was so coupled the Handler impl. But it seems like this pool thingy is confusing, so i'll just go back to that previous impl.


// SingletonMessageProcessor returns a MessageProcessorPool that shares the same MessageProcessor for all users. The
// MessageProcessor is closed when the pool is closed.
func SingletonMessageProcessor(mp MessageProcessor) MessageProcessorPool {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't see this referenced anywhere? Am I missing something?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah I see - thanks

@codecov
Copy link

codecov bot commented Nov 19, 2021

Codecov Report

Merging #3934 (be9a3b1) into master (be9a3b1) will not change coverage.
The diff coverage is n/a.

❗ Current head be9a3b1 differs from pull request most recent head 70159ec. Consider uploading reports for the commit 70159ec to get more accurate results

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #3934   +/-   ##
======================================
  Coverage    56.7%   56.7%           
======================================
  Files         557     557           
  Lines       63545   63545           
======================================
  Hits        36069   36069           
  Misses      24287   24287           
  Partials     3189    3189           
Flag Coverage Δ
aggregator 61.3% <0.0%> (ø)
cluster ∅ <0.0%> (∅)
collector 58.4% <0.0%> (ø)
dbnode 60.6% <0.0%> (ø)
m3em 46.4% <0.0%> (ø)
metrics 19.7% <0.0%> (ø)
msg 74.0% <0.0%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update be9a3b1...70159ec. Read the comment docs.

@ryanhall07 ryanhall07 enabled auto-merge (squash) November 20, 2021 15:09
@ryanhall07 ryanhall07 merged commit 95b3d60 into master Nov 20, 2021
@ryanhall07 ryanhall07 deleted the rhall-mp-close-race branch November 20, 2021 15:24
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.

2 participants