-
Notifications
You must be signed in to change notification settings - Fork 28
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
WIP: add async client #62
base: main
Are you sure you want to change the base?
Conversation
Hi @withinboredom , looks interesting! |
Good idea, thanks!
I'll have to figure out how to enable that! |
@withinboredom ping should be sent when there were no activity on a socket, sync client implementation is sending ping when there are no updates and time interval is passed |
Ah. Thanks for noticing that! I was trying to work out what the logic was doing there! That makes it make so much sense now, perfect! |
There are still some issues, particularly around streams/consumers. I'm trying to figure out the best way to handle that. |
@withinboredom looks like you miss async flag pass in process method for onMessage call |
@withinboredom some comments:
|
i found an issue with consumer expires exceed client timeout, this way ping msg reset processing flags. rebase you changes, maybe it should solve some issues. also client message processing was split like your implementation |
Nice! I'm on a holiday this week, but I'll be back at it this weekend. Looking forward to seeing the new stuff! Last week, I was comparing the consumers here to the Go consumers and noticed idle heartbeats were missing, as well as naks, which I was planning to use for delayed messages -- basically, respond with a nak + delay header and it will be (re)delivered at a later time. The python library does this, so it would be great to support that as well, or at least make it easy for devs to implement themselves if they want to. I have a bunch of notes for how the consumers could be improved but was going to implement them in my application code vs. here (as it would be a big breaking change of the consumer API). I can put them in a gist (or a PR here to a docs folder or something) to discuss them, if you'd be interested. Alternatively, I could put the code into a separate library that people could choose to use via a setter in this library (something like |
In addition, we can't use current consumer api for batch processing approach. I mean pass multiple set of params request to a handler. If i can help with design or implementation, let me know. I think we can merge this request when all tests would be passed, release it in current major release and then analyze other language implementations and redesign php client. Never mind on api breaking changes, semver supports breaking changes, so we can rethink anything and upgrade major release. I think that's okay. |
This PR adds an async client (using amphp). First, take a look at the performance:
Async takes a HUGE performance hit, but it allows you to do other things while things are processing. So, this is a trade-off: less throughput for more flexibility.
Using it:
This is still a work in progress, but I'd love to know if you are interested in merging this.