A channel pool

[steveluscher]

Summary

This is a special RpcSubscriptionsChannelCreator that creates a pool of underlying channels up to minChannels, reuses them evenly up to maxSubscriptionsPerChannel, and tears the channels down when all of its subscribers abort.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8e4edda

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[steveluscher]

• A subscriptions transport coalescer #3316
• Convert the websocket transport to a channel #3314
• Fix lint in version header #3315
• A channel augmenter that autopings the channel #3313
• A subscription plan that implements the Solana JSON WebSocket subscription API #3312
• A channel message demultiplexer #3311
• A channel pool #3310 👈
• A channel augmenter that encodes and decodes messages as JSON #3309
• Revert ‘no argument’ conditional type from #3301 #3326
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @steveluscher and the rest of your teammates on Graphite

[lorisleiva]

Correct me if I'm wrong but I think this is only true if the channel immediately to the current one's right is part of the tie.

Consider the following channel scenarios:

• A(1), B(1), C(1), D(1) where A is the current one. Then here B is the next one because they are all tied.
• A(5), B(5), C(1), D(1) where A is the current one. Then here D is the next one whereas we were probably expecting C as per the rotation principle.

Wouldn't it be better to just do ii + 1 but then have a strict greater than in the condition below (i.e. mostFreeChannel.subscriptionCount > nextPoolEntry.subscriptionCount)? That way, we only override if the next one is better (i.e. less subscribed to).

[steveluscher]

It's pretty insane, but in this case:

A(5), B(5), C(1), D(1) where A is the current one. Then here D is the next one whereas we were probably expecting C as per the rotation principle.

A can't be the current one, because the next-free-channel is chosen ahead of time. The next free channel would always be C or D depending on where we were in the rotation.

Next free channels are chosen:

• as a last step, after one is added.
• as a last step, after one is removed.

The next time that a channel is added, it goes right where the freeChannelIndex points, no questions asked.

I think covered all the weird cases in the tests, but let me know if you can think of one that breaks things!

[lorisleiva]

If I understand correctly, the second scenario cannot happen due to how this function is being used within the decorator.

I think that's fine since we've got good test coverage but wouldn't it be better for maintainability if this function alone was responsible for keeping all the invariants of finding the next channel regardless of how it is being called?

[lorisleiva]

Since this is essentially a channel creator decorator, how would you feel about making the createChannel attribute a proper argument so it can be piped more easily?

Something like:

const channelCreator = pipe(
  getMyOriginalChannelCreator(),
  cc => getChannelPoolingChannelCreator(cc, { ... }),
)

[steveluscher]

Merge activity

• Oct 4, 2:06 PM PDT: @steveluscher started a stack merge that includes this pull request via Graphite.
• Oct 4, 2:09 PM PDT: @steveluscher merged this pull request with Graphite.