Add Mock Server classes for seata-all

[linghengqian]

• I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

• I noticed a unit test related issue in Make ShardingSphere Proxy in GraalVM Native Image form available shardingsphere#21347 while trying to collect GraalVM reachability metadata for seata-all. Can't mock Seata Server normally under Seata 1.6.1.

• Minimal reproducible unit tests and reproduction steps are at https://github.com/linghengqian/mock-seata-sever-test . At the same time, mock-seata-v142 is the unit test of seata-all:1.4.2, and mock-seata-v161 is the unit test of seata-all:1.6.1.

• 

Ⅱ. Describe what happened

If there is an exception, please attach the exception trace:

[ERROR] 2023-02-15 12:44:06.866 [main] i.s.c.r.netty.AbstractNettyRemoting - wait response error:null ,cost: 30001 ms,ip:/127.0.0.1:8891,request:timeout=30000,transactionName=default

io.seata.core.exception.TmTransactionException: RPC timeout

	at io.seata.tm.DefaultTransactionManager.syncCall(DefaultTransactionManager.java:97)
	at io.seata.tm.DefaultTransactionManager.begin(DefaultTransactionManager.java:53)
	at io.seata.tm.api.DefaultGlobalTransaction.begin(DefaultGlobalTransaction.java:114)
	at io.seata.tm.api.DefaultGlobalTransaction.begin(DefaultGlobalTransaction.java:95)
	at com.lingh.SeataATShardingSphereTransactionManager.begin(SeataATShardingSphereTransactionManager.java:85)
	at com.lingh.SeataATShardingSphereTransactionManagerTest.assertBeginTimeout(SeataATShardingSphereTransactionManagerTest.java:96)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
	at com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
Caused by: java.util.concurrent.TimeoutException: null ,cost: 30001 ms
	at io.seata.core.protocol.MessageFuture.get(MessageFuture.java:65)
	at io.seata.core.rpc.netty.AbstractNettyRemoting.sendSync(AbstractNettyRemoting.java:199)
	at io.seata.core.rpc.netty.AbstractNettyRemotingClient.sendSyncRequest(AbstractNettyRemotingClient.java:187)
	at io.seata.tm.DefaultTransactionManager.syncCall(DefaultTransactionManager.java:95)
	... 36 more

Ⅲ. Describe what you expected to happen

• All unit tests should be fine.

Ⅳ. How to reproduce it (as minimally and precisely as possible)

1. Execute the following commands for comparison in Ubuntu 22.04.

sudo apt install unzip zip curl sed -y
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk install java 22.3.1.r17-grl
sdk use java 22.3.1.r17-grl
sdk install maven

git clone git@github.com:linghengqian/mock-seata-sever-test.git
cd ./mock-seata-sever-test/

cd ./mock-seata-v142/
mvn clean test

cd ..
cd ./mock-seata-v161/
mvn clean test

Ⅴ. Anything else we need to know?

• I'm not sure if there's anything that needs to be changed as I don't see a particularly prominent PR for the Seata 1.5.1 milestone. In fact, this part of the unit test of ShardingSphere has failed since Seata 1.5.1. The unit tests for Seata 1.4.2 are fine, but the unit tests for Seata 1.6.1 are failing.

Ⅵ. Environment:

• JDK version : 17
• Seata version: 1.6.1
• OS : Ubuntu
• Others: null

[funky-eyes]

The above information can not see the problem, because 1.4.2 to 1.6 did not make major adjustments to the rpc module, and your error is rpc timeout, you should check whether your network can connect to tc

[linghengqian]

@a364176773 I would like to know what information I can refer to? I didn't see any special configuration for RPC in the https://github.com/linghengqian/mock-seata-sever-test I provided. I just mocked a Seata Server using netty classes, did any big changes happen between Seata 1.4.2 and Seata 1.5.1?

[funky-eyes]

No, this can be proven by running a sample from 1.4.2 to 1.5.1 without mock

[linghengqian]

No, this can be proven by running a sample from 1.4.2 to 1.5.1 without mock

• If you are referring to https://github.com/seata/seata-samples/tree/4e4a579aa7d7866b1a786f5d347c2b333e1bb0ec , then I am even more confused, the latest commit is using Seata 1.4.2 for the example, not seata 1.6.1. I previously manually update seata-example to seata-all 1.6.1 and see errors similar to RPC Timeout.

[slievrly]

@linghengqian I have repeated this question, and I will give you the conclusion later.

[slievrly]

@linghengqian Take a look at the changes first, or just download the repository code to run. I'll explain why later.
https://github.com/slievrly/mock-server-test/blob/master/src/test/java/com/lingh/fixture/MockMessageHandler.java#L36
https://github.com/slievrly/mock-server-test/blob/master/src/test/java/com/lingh/SeataATShardingSphereTransactionManagerTest.java#L104

[slievrly]

@linghengqian In the past TM and RM messages were sent to TC by default using merged MergedWarpMessage messages.In version 1.6.x, TM messages are no longer merged by default for performance reasons, including: GlobalBeginRequest, GlobalCommitRequest, and GlobalRollbackRequest.
Of course, there is another way to solve the problem without changing the code at all, by adding a single line of configuration.
seata.transport.enable-tm-client-batch-send-request=true

[linghengqian]

• @slievrly Thank you very much for your reply! Can I close the current issue now?

[slievrly]

@linghengqian Through this question, I realized that we needed to maintain our own mock-server to ensure version compatibility. I've had a quick look at the mock-server code you've written, and I think you can contribute an original version of mock-server if you want. Are you interested ？

[slievrly]

@linghengqian I noticed that you are doing something related to GraalVM, and Seata is also doing it. We can communicate with each other about the progress. #5234

[linghengqian]

@linghengqian Through this question, I realized that we needed to maintain our own mock-server to ensure version compatibility. I've had a quick look at the mock-server code you've written, and I think you can contribute an original version of mock-server if you want. Are you interested ？

• This MockServer class comes entirely from Apache ShardingSphere's unit tests, so I don't really feel like I have experience perfecting this class. If possible, I would like it to be done by other friends.

[linghengqian]

@linghengqian I noticed that you are doing something related to GraalVM, and Seata is also doing it. We can communicate with each other about the progress. #5234

• I browsed feature: First support native-image for seata-client #5234 and realized I might not be able to help.

• feature: First support native-image for seata-client #5234 involves Spring Framework classes, which I tried my best to avoid when submitting GraalVM reachability metadata at https://github.com/oracle/graalvm-reachability-metadata , because Spring's Maven Plugin/Gradle Plugin added Task prevents users from collecting the GraalVM reachability metadata subset of the Conditional form.

• I've never directly observed Spring's handling of AOT. feature: First support native-image for seata-client #5234 doesn't seem to have fully passed CI, nor is nativeTest executed during the CI phase. If it is necessary for the library maintainer to actively maintain GraalVM's nativeTest, the example of this piece can refer to the processing contributed by OracleLabs to the main branch of netty/netty, refer to https://github.com/netty/netty/pulls?q=is%3Apr+is%3Aclosed+author%3A%22gradinac%22+ .

• As a subtask of Make ShardingSphere Proxy in GraalVM Native Image form available shardingsphere#21347, submitting GraalVM reachability metadata for io.seata:seata-all:1.6.1 at https://github.com/oracle/graalvm-reachability-metadata is indeed in my plan. But OracleLabs review and merge PR is too slow, I still have 7 PRs waiting for their review.

• In any case, the content related to GraalVM is not suitable for discussion in this issue.

[slievrly]

@linghengqian Through this question, I realized that we needed to maintain our own mock-server to ensure version compatibility. I've had a quick look at the mock-server code you've written, and I think you can contribute an original version of mock-server if you want. Are you interested ？

• This MockServer class comes entirely from Apache ShardingSphere's unit tests, so I don't really feel like I have experience perfecting this class. If possible, I would like it to be done by other friends.

OK, anyone willing to contribute is welcome.