Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.21.0
    • Component/s: ipc
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      To more easily permit Hadoop to evolve to use Avro RPC, I propose to change RPC to use different implementations for clients and servers based on the configuration. This is not intended as an end-user configuration: only a single RPC implementation will be supported in a given release, but rather a tool to permit us to more easily develop and test new RPC implementations. As such, the configuration parameters used would not be documented.

      1. HADOOP-6422.patch
        41 kB
        Doug Cutting
      2. HADOOP-6422.patch
        45 kB
        Doug Cutting
      3. HADOOP-6422.patch
        45 kB
        Doug Cutting
      4. HADOOP-6422.patch
        48 kB
        Doug Cutting
      5. HADOOP-6422.patch
        56 kB
        Doug Cutting

        Activity

        Hide
        Doug Cutting added a comment -

        For the record, I mis-identified the primary commit for this issue. The revision was 889889.

        http://svn.apache.org/viewvc?view=revision&revision=889889

        Show
        Doug Cutting added a comment - For the record, I mis-identified the primary commit for this issue. The revision was 889889. http://svn.apache.org/viewvc?view=revision&revision=889889
        Hide
        steve_l added a comment -

        >> RPC.waitForProxy with a timeout needs to be public [ ... ]
        >> RPC.waitForProxy also needs to be interruptible [ ... ]

        >This patch does not change this one way or the other. These are pre-existing problems not addressed by this patch, no?

        yes, pre-existing -and because the version with timeouts was private, you can be sure of where that method is being called; no API consequences there.

        Show
        steve_l added a comment - >> RPC.waitForProxy with a timeout needs to be public [ ... ] >> RPC.waitForProxy also needs to be interruptible [ ... ] >This patch does not change this one way or the other. These are pre-existing problems not addressed by this patch, no? yes, pre-existing -and because the version with timeouts was private, you can be sure of where that method is being called; no API consequences there.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Common-trunk #188 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/188/)
        . Remove log line.

        Show
        Hudson added a comment - Integrated in Hadoop-Common-trunk #188 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/188/ ) . Remove log line.
        Hide
        Hudson added a comment -

        Integrated in Hadoop-Common-trunk-Commit #108 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/108/)
        . Remove log line.

        Show
        Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #108 (See http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk-Commit/108/ ) . Remove log line.
        Hide
        Doug Cutting added a comment -

        > (minor) should we be really having .* imports.

        These were pre-existing. The patch renames two files that included these, so the diff makes it look like new code. I attempted to change existing code as little as possible.

        > -1 to logging the engine choice at info

        Oops. That was for debugging and not meant to remain. I just removed it.

        > This changes the signature of some public methods; so needs to be marked up as a change that is incompatible at the source level.

        Yes, it does require recompilation. However the signature it changed (getProxy) is one whose result is always cast before it can be used, so no calling source code in fact needs to change, it only needs to be recompiled. We expect that folks will recompile for new releases anyway, don't we? I run 'ant clean' whenever I pull from subversion, and I don't think we generally intend for things to work for folks who don't.

        > RPC.waitForProxy with a timeout needs to be public [ ... ]
        > RPC.waitForProxy also needs to be interruptible [ ... ]

        This patch does not change this one way or the other. These are pre-existing problems not addressed by this patch, no?

        Show
        Doug Cutting added a comment - > (minor) should we be really having .* imports. These were pre-existing. The patch renames two files that included these, so the diff makes it look like new code. I attempted to change existing code as little as possible. > -1 to logging the engine choice at info Oops. That was for debugging and not meant to remain. I just removed it. > This changes the signature of some public methods; so needs to be marked up as a change that is incompatible at the source level. Yes, it does require recompilation. However the signature it changed (getProxy) is one whose result is always cast before it can be used, so no calling source code in fact needs to change, it only needs to be recompiled. We expect that folks will recompile for new releases anyway, don't we? I run 'ant clean' whenever I pull from subversion, and I don't think we generally intend for things to work for folks who don't. > RPC.waitForProxy with a timeout needs to be public [ ... ] > RPC.waitForProxy also needs to be interruptible [ ... ] This patch does not change this one way or the other. These are pre-existing problems not addressed by this patch, no?
        Hide
        steve_l added a comment -
        1. (minor) should we be really having .* imports.
        2. -1 to logging the engine choice at info; makes client code extra noisy where it isn't of interest to most people
        3. This changes the signature of some public methods; so needs to be marked up as a change that is incompatible at the source level.
        4. RPC.waitForProxy with a timeout needs to be public, so callers can give up when the far end isn't there. That's HADOOP-6435.
        5. RPC.waitForProxy also needs to be interruptible, HADOOP-6221. Without that, you can't kill a thread that is blocked

        I will rebuild my patches for trunk to handle the latter two

        Show
        steve_l added a comment - (minor) should we be really having .* imports. -1 to logging the engine choice at info; makes client code extra noisy where it isn't of interest to most people This changes the signature of some public methods; so needs to be marked up as a change that is incompatible at the source level. RPC.waitForProxy with a timeout needs to be public, so callers can give up when the far end isn't there. That's HADOOP-6435 . RPC.waitForProxy also needs to be interruptible, HADOOP-6221 . Without that, you can't kill a thread that is blocked I will rebuild my patches for trunk to handle the latter two
        Hide
        Doug Cutting added a comment -

        I just committed this.

        Show
        Doug Cutting added a comment - I just committed this.
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12427801/HADOOP-6422.patch
        against trunk revision 889877.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 6 new or modified tests.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427801/HADOOP-6422.patch against trunk revision 889877. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/201/console This message is automatically generated.
        Hide
        Doug Cutting added a comment -

        Here's a new version that:

        • renames AvroRpc to AvroRpcEngine
        • changes a Class to Class<?> to avoid requiring an @Suppress("unchecked").

        When I actually commit this, I'll use 'svn cp' so that WritableRpcEngine and AvroRpcEngine have history from RPC.java and AvroRpc respectively.

        Show
        Doug Cutting added a comment - Here's a new version that: renames AvroRpc to AvroRpcEngine changes a Class to Class<?> to avoid requiring an @Suppress("unchecked"). When I actually commit this, I'll use 'svn cp' so that WritableRpcEngine and AvroRpcEngine have history from RPC.java and AvroRpc respectively.
        Hide
        Tom White added a comment -

        +1 Looks good to me. A couple of minor things:

        • AvroRpc should really be called AvroRpcEngine or, perhaps, TunnelingAvroRpcEngine.
        • Change Class to Class<?> in RpcEngine and implementations.
        Show
        Tom White added a comment - +1 Looks good to me. A couple of minor things: AvroRpc should really be called AvroRpcEngine or, perhaps, TunnelingAvroRpcEngine. Change Class to Class<?> in RpcEngine and implementations.
        Hide
        Arun C Murthy added a comment -

        Duh, never mind - wrong jira (too many open tabs).

        Show
        Arun C Murthy added a comment - Duh, never mind - wrong jira (too many open tabs).
        Hide
        Arun C Murthy added a comment -

        Aaron, can you please explain the use case a little more? Why do we really need maps? Why isn't metadata serializable?

        Show
        Arun C Murthy added a comment - Aaron, can you please explain the use case a little more? Why do we really need maps? Why isn't metadata serializable?
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12427646/HADOOP-6422.patch
        against trunk revision 889378.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 6 new or modified tests.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427646/HADOOP-6422.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/192/console This message is automatically generated.
        Hide
        Doug Cutting added a comment -

        It was deprecation warnings, since I deprecated some existing RPC methods. I updated the tests to use the non-deprecated APIs.

        Show
        Doug Cutting added a comment - It was deprecation warnings, since I deprecated some existing RPC methods. I updated the tests to use the non-deprecated APIs.
        Hide
        Doug Cutting added a comment -

        Sigh. Is there a reason why the default lint settings are different than those used by Hudson?

        Show
        Doug Cutting added a comment - Sigh. Is there a reason why the default lint settings are different than those used by Hudson?
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12427638/HADOOP-6422.patch
        against trunk revision 889378.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 3 new or modified tests.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        -1 javac. The applied patch generated 174 javac compiler warnings (more than the trunk's current 169 warnings).

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427638/HADOOP-6422.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The applied patch generated 174 javac compiler warnings (more than the trunk's current 169 warnings). +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/190/console This message is automatically generated.
        Hide
        Doug Cutting added a comment -

        Fix javadoc warning. Mistakenly capitalized '@deprecated'. Annotations on my mind.

        Show
        Doug Cutting added a comment - Fix javadoc warning. Mistakenly capitalized '@deprecated'. Annotations on my mind.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12427635/HADOOP-6422.patch
        against trunk revision 889378.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 3 new or modified tests.

        -1 javadoc. The javadoc tool appears to have generated 1 warning messages.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 findbugs. The patch does not introduce any new Findbugs warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed core unit tests.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/testReport/
        Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
        Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/artifact/trunk/build/test/checkstyle-errors.html
        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427635/HADOOP-6422.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 javadoc. The javadoc tool appears to have generated 1 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/artifact/trunk/build/test/checkstyle-errors.html Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/189/console This message is automatically generated.
        Hide
        Owen O'Malley added a comment -

        I'd vote for making a patch to trunk and 0.21 that mark the interface as @Audience.Private and @Stability.Evolving.

        Show
        Owen O'Malley added a comment - I'd vote for making a patch to trunk and 0.21 that mark the interface as @Audience.Private and @Stability.Evolving.
        Hide
        Doug Cutting added a comment -

        Here's a new version with a complete version of WriteableRpcEngine.java.

        Show
        Doug Cutting added a comment - Here's a new version with a complete version of WriteableRpcEngine.java.
        Hide
        Doug Cutting added a comment -

        Argh. I used 'svn cp' to create WritableRpcEngine from RPC.java, since most of the code's unchanged, but the patch file is then unusable by Hudson. I'll resubmit without that.

        Show
        Doug Cutting added a comment - Argh. I used 'svn cp' to create WritableRpcEngine from RPC.java, since most of the code's unchanged, but the patch file is then unusable by Hudson. I'll resubmit without that.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12427627/HADOOP-6422.patch
        against trunk revision 889378.

        +1 @author. The patch does not contain any @author tags.

        +1 tests included. The patch appears to include 3 new or modified tests.

        -1 patch. The patch command could not apply the patch.

        Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/187/console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12427627/HADOOP-6422.patch against trunk revision 889378. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/187/console This message is automatically generated.
        Hide
        Doug Cutting added a comment -

        Here's a patch that makes the RPC backend pluggable protocol-by-protocol. The public API of RPC.java is unchanged, but it now delegates to an RpcEngine implementation. The existing implementation is moved to WritableRpcEngine. AvroRpc is modified to implement RpcEngine. No new public APIs are introduced.

        AvroRpc is no longer public, which may be an incompatible change. It was introduced in 0.21, which has not yet been released, so we could either:

        • backport this change to 0.21
        • declare that AvroRpc was experimental, little used, and permit this incompatible change from 0.21 to 0.22.
        • keep AvroRpc public in 0.22, with its prior static methods, for compatibility with 0.21.

        I prefer one of the first two options, since I think, going forward, we want to encourage the use of a single RPC API, and not have to maintain multiple APIs long-term.

        I have run HDFS and MapReduce tests against this, and they pass.

        Show
        Doug Cutting added a comment - Here's a patch that makes the RPC backend pluggable protocol-by-protocol. The public API of RPC.java is unchanged, but it now delegates to an RpcEngine implementation. The existing implementation is moved to WritableRpcEngine. AvroRpc is modified to implement RpcEngine. No new public APIs are introduced. AvroRpc is no longer public, which may be an incompatible change. It was introduced in 0.21, which has not yet been released, so we could either: backport this change to 0.21 declare that AvroRpc was experimental, little used, and permit this incompatible change from 0.21 to 0.22. keep AvroRpc public in 0.22, with its prior static methods, for compatibility with 0.21. I prefer one of the first two options, since I think, going forward, we want to encourage the use of a single RPC API, and not have to maintain multiple APIs long-term. I have run HDFS and MapReduce tests against this, and they pass.
        Hide
        Doug Cutting added a comment -

        > Do you expect to have a runtime performance penalty if it is left configured to use hadoop rpc?

        No. The only call paths that are lengthened are those that create proxy and server instances. The invocation call path is unchanged. I'll submit a patch soon.

        Show
        Doug Cutting added a comment - > Do you expect to have a runtime performance penalty if it is left configured to use hadoop rpc? No. The only call paths that are lengthened are those that create proxy and server instances. The invocation call path is unchanged. I'll submit a patch soon.
        Hide
        Owen O'Malley added a comment -

        Do you expect to have a runtime performance penalty if it is left configured to use hadoop rpc?

        Show
        Owen O'Malley added a comment - Do you expect to have a runtime performance penalty if it is left configured to use hadoop rpc?
        Hide
        Doug Cutting added a comment -

        My idea is to use a convention similar to that of HDFS file-system implementations. The property name would be rpc.impl.<protocolName>, and its values would name an implementation of an RPC system. We'd modify RPC.java to be a factory for different RPC implementations. The central methods of an RPC implemetation are getProxy() and getServer(). This interface would be package-private, so we would not encourage others to create new RPC implementations.

        Show
        Doug Cutting added a comment - My idea is to use a convention similar to that of HDFS file-system implementations. The property name would be rpc.impl.<protocolName>, and its values would name an implementation of an RPC system. We'd modify RPC.java to be a factory for different RPC implementations. The central methods of an RPC implemetation are getProxy() and getServer(). This interface would be package-private, so we would not encourage others to create new RPC implementations.

          People

          • Assignee:
            Doug Cutting
            Reporter:
            Doug Cutting
          • Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development