Skip to content
This repository has been archived by the owner on Nov 2, 2020. It is now read-only.

Limited to 1 wss.on('connection') handler per Worker #89

Open
1 of 4 tasks
Danielv123 opened this issue Jun 17, 2018 · 6 comments
Open
1 of 4 tasks

Limited to 1 wss.on('connection') handler per Worker #89

Danielv123 opened this issue Jun 17, 2018 · 6 comments

Comments

@Danielv123
Copy link

Submitting

  • Bug
  • Question
  • Suggestion
  • Other

What I want to do:
For my application I have multiple classes that each get created with access to the wss object. I want them to handle different sockets, but to avoid having to modify my main files, I have a connection handler in each of the classes to filter out the sockets they want.

Expected behaviour:
When I have multiple event handlers listening to the same event I would expect them all to get executed with the same data.

Observed behaviour:
Only 1 wss.on('connection') handler gets executed. The rest are ignored.

Workaround:
Have 1 connection handler in the main thread and loop over all my socket handlers.

@goriunov
Copy link
Member

goriunov commented Jun 17, 2018

Unfortunate it is a part of design to have only one listener on single event as having more then one is inefficient. The same principal as in uWS library check this at the end of the page.

We are trying to make the framework as fast and minimalistic as possible with less performance overhead.

@goriunov
Copy link
Member

goriunov commented Jun 17, 2018

I believe the best solution in you case will be to listen on connection event and call another event emitter with many listeners to propagate this event to your events for example.

wss.on('connection', (socket) => ownEventEmitter.emit('connection', socket))

@Danielv123
Copy link
Author

But do you really save that much on performance by not allowing multiple event listeners? Wouldn't it be just as fast if you allowed multiple but printed a warning about not being good for performance? I feel that my current workaround of just running more code and loops in the one event handler is probably going to be worse.

And yeah, that is pretty much what I implemented.

@goriunov
Copy link
Member

goriunov commented Jun 17, 2018

I will look in to that and do some benches, if everything works out well and i don't need to change core too much i may add this functionality to listen many instead of one when is needed.

@goriunov goriunov self-assigned this Jun 17, 2018
@Danielv123
Copy link
Author

Thanks for explaining and having a look 👍

@goriunov
Copy link
Member

I am reopening the issue to track this functionality.

@goriunov goriunov reopened this Jun 17, 2018
@goriunov goriunov added this to To do in ClusterWS 3.x.x Jun 17, 2018
@goriunov goriunov moved this from To do to In progress in ClusterWS 3.x.x Jun 19, 2018
@goriunov goriunov moved this from In progress to Wont be added in this release in ClusterWS 3.x.x Jun 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
ClusterWS 3.X.X + Roadmap
  
Awaiting triage
ClusterWS 3.x.x
  
Wont be added in this release
Development

No branches or pull requests

2 participants