-
Notifications
You must be signed in to change notification settings - Fork 804
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
Add IPC transport for JSON-RPC APIs #3695
Conversation
a2b6e2b
to
229ba99
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
fb4927b
to
e042cc9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of it, but it's been so long since I've been in that code I'm not sure what is an improvement and what isn't. The acceptance tests still pass.
A set of acceptance tests that use IPC to do some testing wold be nice, but doesn't have to be in this PR and can be in a follow on. It's also tricky because it may have OS specific setup.
Generally speaking a quarterly release is the right time to put these changes in, as we've signaled that's when breaking features come in. While re-writing core parts of JSON aren't breaking, they are higher risk.
Unless @macfarla, @usmansaleem , @mark-terry, or someone else whose had their hands deep in the RPC code chime in I'm cool with @diega pressing the merge button before RC2 gets spun out.
@mark-terry can you review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really excited to see this implemented. Great stuff.
...m/api/src/test/java/org/hyperledger/besu/ethereum/api/jsonrpc/ipc/JsonRpcIpcServiceTest.java
Outdated
Show resolved
Hide resolved
@diega this needs a changelog entry :) |
The `o.h.b.e.a.j.JsonRpcHttpServiceTest#exceptionallyHandleJsonSingleRequest` and `o.h.b.e.a.j.JsonRpcHttpServiceTest#exceptionallyHandleJsonBatchRequest` tests were throwing ClassCastException in `o.h.b.e.a.j.JsonRpcHttpService#validateMethodAvailability` which wasn't ever catched, returning status 500 by default, but that wasn't the use case aimed to test. Another test running an exceptional method is `o.h.b.t.a.p.EnclaveErrorAcceptanceTest#whenEnclaveIsDisconnectedGetReceiptReturnsInternalError` which validates an "Internal Error" proper json-rpc response. I changed the first two tests to be consistent with the later one. Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
…line [hyperledger#535] Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
…rledger#535] Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
This pull request fixes 2 alerts when merging 70a0196 into bf349a4 - view on LGTM.com fixed alerts:
|
Sure @matt-nelson-csi, thank you for the heads up |
* Fix json-rpc HTTP tests [hyperledger#535] The `o.h.b.e.a.j.JsonRpcHttpServiceTest#exceptionallyHandleJsonSingleRequest` and `o.h.b.e.a.j.JsonRpcHttpServiceTest#exceptionallyHandleJsonBatchRequest` tests were throwing ClassCastException in `o.h.b.e.a.j.JsonRpcHttpService#validateMethodAvailability` which wasn't ever catched, returning status 500 by default, but that wasn't the use case aimed to test. Another test running an exceptional method is `o.h.b.t.a.p.EnclaveErrorAcceptanceTest#whenEnclaveIsDisconnectedGetReceiptReturnsInternalError` which validates an "Internal Error" proper json-rpc response. I changed the first two tests to be consistent with the later one. * Extract json-rpc HTTP authentication to a handler [hyperledger#535] * Replace TimeoutHandler in GraphQLHttpService with Vert.x's impl [hyperledger#535] * Extract json-rpc HTTP parser to a handler [hyperledger#535] * Refactor json-rpc WS handler [hyperledger#535] * Add json-rpc IPC support [hyperledger#535] Signed-off-by: Diego López León <[email protected]> Signed-off-by: Diego López León <[email protected]>
PR description
Adds socket interface for JSON-RPC, only supported on BSD (OSX) and Linux. This feature has been developed with the intention to reuse and unify, as much as possible, the behaviour among the other transport layers (i.e. HTTP and WS)
Given this is a big PR to review, I have split it in the following commits (I recommend checking them individually):
(*): these commits can be omitted without affecting the implementation of the IPC transport
Note
This implementation has been tested against
geth attach
and it works fine.Fixed Issue(s)
fixes #535
Documentation
doc-change-required
label to this PR ifupdates are required.
Changelog