Request -> RPC Support
nathan-hega opened this issue · 3 comments
Context
We spoke via Slack about the desire to have RPC support in this extension and some of the things I've tried to do to add it in there. Here is some of that context copied:
Our main use-case is RPC tests.. "how many RPCs can I fire off until I start to see perf issues from the receivers of the RPCs?" is the main question for now. I think ideally we'd be able to provision an AMQP connection and set up reply handlers all outside of the tests. Inside the test we'd just want to ramp up / down the actual RPCs being made. The integration between the RPCs we fire and how to make the test pause for responses as well as make sure the metrics actually reflect what is going on is still very unclear.
WIP
The work in progress so far has been me trying to do some very basic things:
- Add correlation ID and reply to support in the golang extension level
- I.e. have the publish() method proxy those options through and then have listener expose them via some hacky string concatenation
- Use the values above at the testing client level to basically transform the received payload and try to publish back to the reply to value with the same correlation ID
I mentioned in Slack the litany of issues I've ran into so far and how all of it is so confusing because the interaction between NodeJS and golang in the k6 system isn't clearly defined for me. As I try to make changes to do this work, the test will hang or fail fast or panic depending on what I'm trying to do.
I did publish a branch of this code to my fork and you can view that here: https://github.com/nathan-hega/xk6-amqp/tree/RPC-prototype (I hope it's viewable at least, been a long time actually using Github for me!)
In this example, you can see I try to edit the publish-listen.js test to fit my purposes / model what I'm trying to do. I hope the code aligns nicely with what I've been saying above. Please excuse the "WIP" / prototype nature (sloppy nature) of the code 😄 .
RPC Notes
I do have experience creating an RPC wrapper / implementation around the streadway/amqp library. If there is anything I can do to expose some of that to you for help here, please LMK. I can go over the high level RPC mechanics or paste snippets of the code I actually used. The library itself is proprietary under my company so I can't publish the entire thing unfortunately, though I have wondered if that package would be a better starting point for RPC support in this AMQP extension than going vanilla against streadway/amqp.
LMK!
Next Steps
For me, I have to take a break from this for a couple days. When I return, I have to basically decide for my company if we will move forward with this project one way or another. Moving forward could mean I either help you do RPCs in this extension or I make my own extension privately and do the same work there or I fork from this and just keep working independent of whatever you are focusing on.
I know you care little for my own personal timelines, etc.. but I figured I'd share this context so we are on the same page. Ideally, we can work together to make this extension great, but if that doesn't fit into my company's timelines, I'll have to adjust.
Thank you !! Even though the extension is in a very very early stage, it's been nice to have something to tinker around with and another human to talk to directly about these topics.
FYI: I have this supported on my own now so I'm closing this down.
Hi @nathan-hega, can you summarize somethings that you needed to do to fix the problems above and anything that you would've liked k6 provided you with or things that didn't help. As well as things that worked okay for you.
I am also interested in how you prevented the panics as I would expect we are talking about panics concerning Listen using the goja.Runtime without locking it for itself and consequently goja panicking with index out of bounds or similar?
I have played with this in this branch based on an even more WIP of PoC one in k6 that apparently now needs to be rebased on master as all but the 2 commits are now merged in master.
can you summarize somethings that you needed to do to fix the problems above
I have a handy RPC abstraction in my back pocket. So, instead of integrating directly with streadway/amqp, I just used my RPC module. This simplified the golang code quite a lot and allowed me to just follow along with the Redis example blog post. If I hadn't had an RPC abstraction ready and had to build one for this project, my company would have killed the project due to the time constraints we have.
Also, this is why you see no code from me being uploaded to this repo: I went a totally different route with a different underlying repo which is private for my company and thus can't be shared. I did talk with my boss and we are going to open source the RPC module and the k6 extension so that everyone can use, it'll just take me time to get that moving.
This is also why I just totally dodged the panics via
I am also interested in how you prevented the panics as I would expect we are talking about panics concerning Listen using the goja.Runtime without locking it for itself and consequently goja panicking with index out of bounds or similar?
As well as things that worked okay for you.
- The blog post was very helpful; albeit a little terse.
- The documentation was helpful but.. not enough; more on this in a minute
anything that you would've liked k6 provided you with or things that didn't help.
My biggest issue when working on this project and the main reason why I advocated to just not do this work to my boss many times was that it's clear the k6 extension project is in its infancy and not that supported. As an engineer trying to build on top of something, I need not just rote documentation for various artifacts outlined, I also need a) clean abstractions to work with and b) a more comprehensive vision for how to do common operations with extensions.
I was able to piece my way through to get a functioning MVP, but it'd be a lie to say I understand everything that is going on with the system. How could I possibly understand when I have the barest of documentation available and a very simple Redis example and nothing else. Well, there are community extensions and I browsed, e.g., MQTT extension source code and they do very different things in terms of what they register as a module and how they deal with errors and other things.
Anyway, this is all touching on the developer experience. The more polish you can provide in terms of guides and documentation, the better resultant extensions will be created and the happier devs will be. For me, in a business context with very limited time to work on this project, it was very close to being "too risky to try" because we simply can't afford to spend days messing around with an obtuse system. I would imagine other engineers coming from similar business perspectives would have similar concerns - limited times means that you want to work very efficiently opposed to mucking around with trial and error being your main driving force of progress.
The goja stack traces that get dumped are basically undebuggable. Consider putting a stronger boundary between those panics and what trickles up through the K6 extension logic. This is what I mean above when I say "clean abstractions"; no leaky boundaries where underlying errors pummel you like goja.
I still can't figure out how to properly deal with errors and I still don't understand the seemingly confusing naming conventions for the method names of the modules. I'm working on these last two issues with you in slack right now!
Having a develop to engage with directly, which I asked for and unfortunately couldn't get, would have helped as I could have directly asked pointed questions to instead of just trial / error. Slack is nice but not super active.
Phew, I think that's it! LMK if you'd like to chat more via Slack about some of this.