Everything is nested under a single Server class. This may not seem best, but splitting things up basically requires a lot of "Server" prefixes all over the place, even if we use a separate package. I'm expecting to defer the decision, but once we decide the organization we need to update the Channel API to match.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=71838718
MoreExecutors.directExecutor() or MoreExecutors.newDirectExecutorService()
based on whether the code requires an Executor or an ExecutorService instance.
This is being done to resolve some performance issues with the current
sameThreadExecutor() implementation, by allowing users who don’t need
ExecutorService#shutdown semantics to not pay for them, and to make the costs
more obvious for users who do need them.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=71585920
OkHttpSession is temporally kept for server side using.
Test:
java/com/google/net/stubby/testing/integration/grpc_java_server --port=10009 --transport=http2_okhttp
java/com/google/net/stubby/testing/integration/grpc_java_client --serverHost=localhost --serverPort=10009 --transport=http2_okhttp
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=71436060
transports that can deliver them.
This unblocks sending OAuth2 headers natively
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=71118741
The real solution is to not assume gRPC frame/DATA frame alignment, but
that is a much larger piece of work.
The bug was exposed via talking HTTP/2 to GFE which used a separate DATA frame
for closing the stream.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=70982223
Overview:
- NettyClientTransport - this is the entry point into the client transport. This creates streams as well as the NettyClientHandler
- NettyClientStream - client stream implementation. This sends commands to the NettyClientHandler via commands. Callbacks on the stream are made directly from the NettyClientHandler in the channel thread context.
- NettyClientHandler - A Netty HTTP/2 handler that acts as a bridge between the NettyClientStreams and Netty's HTTP/2 processing.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=70970028
Resurrect integration tests that pass through GFE for HTTP2+Netty
Misc improvements to hexa environment
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=70683236
And when write the Code in the MessageFramer, write the field number instead of the index.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69868712
More bugs were lurking in this section of code. In some unknown way,
code I'm working on triggered frequent (9/10) failures of
test_TestServiceBenchmarks. These were all possible to be triggered on
HEAD, but for some unknown reason are not.
I am pretty certain we have at least one transport that handles
exceptions poorly, such as by throwing away the exception and not
informing the Operation of the error, which causes this test to time out.
Timeouts in this test are thus likely an indicator of a real bug, even
when it doesn't show any exception, because there was likely an exception
and it was eaten without logging.
Bugs fixed (in order of discovery):
1) In Deframer, currentLength and inFrame were not reset after
consuming a context or status message.
2) In consolidate(), if suffix was greater than the buffer and the
buffer contained data, the data would be lost.
3) In Deframer, some (unknown) Operation's addPayload() did not consume
all of the provided InputStream immediately (maybe it does so on
another thread), leaving those bytes in frame.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69402916
This is intended to reduce the flakiness of test_TestServiceBenchmarks.
TAP showed some flaky runs where HttpStreamDeframer threw the exception
"GRPC stream not correctly aligned".
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69166650
Session is now (properly) implementing transport API, so ChannelImpl has some
testing.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69074094
The fluent-style wasn't being used, yet made it impossible to
simultaneously implement both ClientStream and ServerStream. Having a
single class that switches between client and server behavior based on a
boolean is helpful to some transports.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69028356
c.g.n.stubby.Transport.Status isn't intended to be used (at least at
this point).
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69027874
Call does not accept InputStream length because Marshaller makes it too hard
for the Stub to determine the length.
SessionCall is updated to implement changes to Call, but it is replaced in the
next CL.
You can see what glue is necessary to join the Transport and Stub APIs. The
ugliest pain is dealing with flow control callback. Some of that code is
unrelated and necessary because the Channel uses a separate thread to run
Call.Listener. Other parts will be necessary because Channel must intervene
during Transport callbacks to handle retry logic.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=69020275
Will re-create the E2E tests through GFE when we can properly initiate HTTP2 with GFE.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=68488736
It was an oversight that newstub was not in third_party when committed.
Renaming of package was preformed via a script.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=68416211
- Introduce 'Channel' & 'Call' interfaces
- Unify the surfaces for the prototype generated stubs
- Lighten dependency on MessageLite outside of generated code (see Marshaller)
- Bridge Channel to Session pending Transport interface rewrite
- Update all tests to new interfaces
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=68407406
Half our tests still need to be moved, but that will be for a later
time.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=67023748
zhangkun