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

Feature Request: Implement long polling using web workers #113

Open
washu opened this issue Jun 2, 2016 · 8 comments
Open

Feature Request: Implement long polling using web workers #113

washu opened this issue Jun 2, 2016 · 8 comments

Comments

@washu
Copy link
Contributor

washu commented Jun 2, 2016

It would be nice to run the polling via a web worker a further improvement its supported all modern browsers. would also open up the queuing processing to sub workers.

@SamSaffron
Copy link
Member

Yes I have spend a fair amount of time thinking about this, I am not
against but the code can get super duper hairy quickly, @riking did a proof
of concept in this area.

On Fri, Jun 3, 2016 at 2:04 AM, Sal Scotto [email protected] wrote:

It would be nice to run the polling via a web worker a further improvement
its supported all modern browsers. would also open up the queuing
processing to sub workers.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#113, or mute the thread
https://github.com/notifications/unsubscribe/AAAUXbpio0GaOrQDAHZPQXHehrNIs0coks5qHv8JgaJpZM4Ist5F
.

@washu
Copy link
Contributor Author

washu commented Jun 9, 2016

i did a version of the code locally but im not sure its a 100% solid yet

@SamSaffron
Copy link
Member

cool let me know if you have a version you want reviewed

On Thu, Jun 9, 2016 at 11:19 PM, Sal Scotto [email protected]
wrote:

i did a version of the code locally but im not sure its a 100% solid yet


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#113 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAUXdR-mFXgPiCpz05NcPud7Xe16aPZks5qKBLQgaJpZM4Ist5F
.

@washu
Copy link
Contributor Author

washu commented Apr 4, 2017

https://gist.github.com/washu/5a5c7e7eea829149ad37c5e3a80b747b

Here is a implmentation of the message bus worker. the core bus itself, (i made lots of local chanegs for my specifc app callback needs) just needs hook

@washu
Copy link
Contributor Author

washu commented Apr 4, 2017

and the message bus itself, it may not be 100% in sync with latest but its from my production system

https://gist.github.com/washu/f12d943c0d17244e4e7f54cbcf2303e5

@washu
Copy link
Contributor Author

washu commented Apr 4, 2017

i did make a callback hook but i dont like it yet. it just adds an option that is default $.noop to let them assign the activityCallback which is just called in the worker message processor and the progresshandler callback

@washu
Copy link
Contributor Author

washu commented Jun 28, 2017

I also did a backend using mongodb and tailable cursors but performance is terrible just for anyone thinking about using a tailable cursor.. its works, just all the db overhead for insert a doc and tail out is slow.

@washu
Copy link
Contributor Author

washu commented Jul 31, 2017

@SamSaffron web workers, with a little around the edges cleanup can ensure -> outbound queuing I added a route on my end as a patch the middleware to accept a publish call form the client for round trip messaging and made it reliable with basic queuing on the client side when coordinated with local storage. i did find, however zbyterange by score performance with > 100 clients became slow. so my end recieves client requests in a blpoprpush/lpush with processing queuing and improved response time processing signifignatly in the middle ware. backlog requests were taking way too long under high speed as well as oddly enough massive network traffic (100 clients were generating 1GB traffic to redis + 2s calls to zbyterangebyscore, and since i dont care about backlog in my use case (i use the bus to synchronize data to the client and send alerts for active users only)

so you may want to revisit the zrangebyscore for backlog processing when you have 24 clients with 25 subscriptions each and 100+ web subscribers for a single channel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants