Anon2Tokyo commented on issue #16414:
URL: https://github.com/apache/dubbo/issues/16414#issuecomment-5226185529

   STEP:
   
   The runtime reproduction is timing-sensitive because it depends on how 
HTTP/2 DATA frames are coalesced, but the scenario I used is:
   
   - Dubbo `3.3.6`
   - Triple provider without generated stub inheritance
   - client-streaming RPC
   - the client sends many small messages quickly, for example `2000` messages 
with `8` bytes each
   
   The important part is that the provider should expose a plain Java service 
interface instead of extending the generated Triple stub, so the request goes 
through the no-stub method-discovery path.
   
   Example run shape:
   
   ```powershell
   # build the repro app
   mvn.cmd -q -DskipTests package
   mvn.cmd -q dependency:build-classpath 
"-Dmdep.outputFile=target\classpath.txt"
   
   # start provider
   .\run-provider.ps1 -ConfigName application-provider -LogName provider-tri 
-ClasspathFile target\classpath.txt
   
   # run consumers repeatedly
   .\run-consumers.ps1 -ConfigName application-consumer -RunName native-tri 
-Iterations 30 -Chunks 2000 -ChunkBytes 8 -ClasspathFile target\classpath.txt
   ```
   
   A more aggressive run is:
   
   ```powershell
   .\run-consumers.ps1 -ConfigName application-consumer -RunName 
native-tri-stress -Iterations 60 -Chunks 10000 -ChunkBytes 1 -ClasspathFile 
target\classpath.txt
   ```
   
   Expected failure signatures are usually one of:
   
   ```text
   reserved bits not zero
   IllegalReferenceCountException
   LengthFieldStreamingDecoder
   Upload failed
   ```
   
   The underlying frame layout that triggers the bug is:
   
   ```text
   DATA frame 1: [complete message 1][prefix of message 2]
   DATA frame 2: [remaining bytes of message 2]
   ```
   
   With the old implementation, the prefix of message 2 can be buffered in the 
temporary `GrpcStreamingDecoder` used during method discovery, then lost when 
the stream switches to the actual decoder. This PR avoids that by reusing the 
stream's existing decoder during method discovery.
   
   One note: I do not think this is 100% deterministic as a black-box runtime 
repro, since it depends on local scheduling and HTTP/2 frame packing. The 
regression test in this PR directly covers the problematic decoder state 
transition.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to