Closed mty2015 closed 2 years ago
what is the whole error logs in proxy console?
thanks for feedback, I can do some investigate for that.
what is the whole error logs in proxy console?
[ERROR] 17:02:22.479 [ShardingSphere-Command-3] o.a.s.s.b.c.j.c.BackendConnection - Cannot do switch, exceed maximum retry count:[5]. [ERROR] 17:02:22.479 [ShardingSphere-Command-3] o.a.s.s.f.c.CommandExecutorTask - Exception occur: org.apache.shardingsphere.underlying.common.exception.ShardingSphereException: Failed to switch schema, please terminate current transaction. at org.apache.shardingsphere.shardingproxy.backend.communication.jdbc.connection.BackendConnection.setCurrentSchema(BackendConnection.java:112) at org.apache.shardingsphere.shardingproxy.backend.text.admin.BroadcastBackendHandler.execute(BroadcastBackendHandler.java:50) at org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.execute(MySQLComQueryPacketExecutor.java:73) at org.apache.shardingsphere.shardingproxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:93) at org.apache.shardingsphere.shardingproxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:71) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
I think sharding-proxy doesn't support the sql syntax SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
which ORM framework send.
According to my guess, i think that sharding-proxy
did not handle the mysql protocol correctly.
The seq 11: SET AUTOCOMMIT = 0
but the response of server status is incorrect(the seq 13).
If the correct server status is returned here, the client will call SET AUTOCOMMIT = 1
next, and eventually all become normal.
i verified my guess by directly connecting to the database instead of sharding-proxy, the network packages are as follows:
SET AUTOCOMMIT = 0
SELECT @@SQL_AUTO_IS_NULL
SET AUTOCOMMIT = 1
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
what's the JDBC-driver are you using? from my understand it's very strange sending a SET AUTOCOMMIT =1
command after SET AUTOCOMMIT=0
similar with #3546, I have some ideas to enhance it recently.
what's the JDBC-driver are you using? from my understand it's very strange sending a
SET AUTOCOMMIT =1
command afterSET AUTOCOMMIT=0
the JDBC-driver is mysql-connector-java-5.1.47.jar
,
but i think this problem has nothing to do with it, it's related to django
initinalization.
The root reason of this problem is that proxy cannot return the correct server satus for set autocommit = 1 | 0
. If the client ignores this return, there is no problem. Once the client cares about this state, it will cause client problems
agree with it, I will do something to be compatible with it.
i updated my previous comment
The root reason of this problem is that proxy cannot return the correct server satus for
set autocommit = 1 | 0
. If the client ignores this return, there is no problem. Once the client cares about this state, it will cause client problems
yes, there are two problems exist in your issue.
Will the issue be resolved in the 5 milestone or 4.1.x version? I hope to solve it as soon as possible because I need it urgently :)
it should be enhanced in 5.x, we have not 4.1.x release plan recently.
@hongfuli can you push your Django project to github, I want to verify the test result
@cherrylzhao https://github.com/hongfuli/sharding-proxy-django/
@hongfuli this example could not run on my pc, please try to test using my branch code: git clone -b issue#5531-test https://github.com/cherrylzhao/incubator-shardingsphere.git
git clone -b issue#5531-test https://github.com/cherrylzhao/incubator-shardingsphere.git
build failed :(
[INFO] Running org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest
[ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.005 s <<< FAILURE! - in org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest
[ERROR] assertIsErrorResponse(org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest) Time elapsed: 0.001 s <<< ERROR!
java.lang.NullPointerException
at org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest.<init>(MySQLComQueryPacketExecutorTest.java:50)
[ERROR] assertIsQuery(org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest) Time elapsed: 0 s <<< ERROR!
java.lang.NullPointerException
at org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest.<init>(MySQLComQueryPacketExecutorTest.java:50)
[ERROR] assertIsUpdateResponse(org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest) Time elapsed: 0 s <<< ERROR!
java.lang.NullPointerException
at org.apache.shardingsphere.shardingproxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutorTest.<init>(MySQLComQueryPacketExecutorTest.java:50)
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR] MySQLCommandExecutorFactoryTest.assertNewInstance:59 » NullPointer
[ERROR] MySQLComStmtExecuteExecutorTest.assertIsErrorResponse:59 » NullPointer
[ERROR] MySQLComStmtExecuteExecutorTest.assertIsQuery:88 » NullPointer
[ERROR] MySQLComStmtExecuteExecutorTest.assertIsUpdateResponse:74 » NullPointer
[ERROR] MySQLComQueryPacketExecutorTest.<init>:50 » NullPointer
[ERROR] MySQLComQueryPacketExecutorTest.<init>:50 » NullPointer
[ERROR] MySQLComQueryPacketExecutorTest.<init>:50 » NullPointer
[INFO]
[ERROR] Tests run: 33, Failures: 0, Errors: 7, Skipped: 0
I have fixed the unit test error, you can pull it again or just -DskipTests
I still have the same problem.
Actually you don't need Django to verify, just need to check the status flag
after sending the requestSET AUTOCOMMIT = 0
.
yes I know, but it's very difficult to implement SERVER_SESSION_STATE_CHANGED
protocol in current architecture, so I want to test a alternate way
@cherrylzhao Can I use a fixed version for this problem?
did this problem resoled? I catch same problem in qrtz frame.
Has the problem been solved ? I have the same problem in my django project.
The same error info in sqoop import with sqoop-1.4.6+sharding-proxy-5.0.0-RC1
When I use dataX to connect shardingproxy, I encountered the same error. I tried version 3.1.0/4.1.1/5.0.0-alpha, all have this problem.
use dbcp2 and connection.setAutoCommit(false), get the same error, mysqlProxy version 5.0-alpha
当我使用dataX连接分片代理时,我遇到了同样的错误。我试过3.1.0/4.1.1/5.0.0-alpha版本,都存在这个问题。
有解决么
+1 都到2021年尾了,bug还在?
+1 this issue has been open for more than one year😂
It maybe fixed by #14983 .
Bug Report
Which version of ShardingSphere did you use?
4.1.0
Which project did you use? Sharding-JDBC or Sharding-Proxy?
Sharding-Proxy
Steps to reproduce the behavior
My project developed by
Django
wants to connect mysql proxy, errors are always reported when initializing the connection, but after the initialization is complete, it can continue to work fine.I used wireshark to grab the data package that initialized the connection process(the login process is omitted):
the content of
config-sharding.yaml
:Example codes for reproduce this issue (such as a github link).