You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by GitBox <gi...@apache.org> on 2019/09/19 20:34:28 UTC

[GitHub] [incubator-shardingsphere] contextshuffling opened a new issue #3071: Test can fail if HashMap iterates in a different order

contextshuffling opened a new issue #3071: Test can fail if HashMap iterates in a different order
URL: https://github.com/apache/incubator-shardingsphere/issues/3071
 
 
   ## Bug Report
   
   **For English only**, other languages will not accept.
   
   Before report a bug, make sure you have:
   
   - Searched open and closed [GitHub issues](https://github.com/apache/incubator-shardingsphere/issues).
   - Read documentation: [ShardingSphere Doc](https://shardingsphere.apache.org/document/current/en/overview).
   
   Please pay attention on issues you submitted, because we maybe need more details. 
   If no response **more than 7 days** and we cannot reproduce it on current information, we will **close it**.
   
   Please answer these questions before submitting your issue. Thanks!
   
   ### Which version of ShardingSphere did you use?
   `dev` branch: 4.0.0-RC3-SNAPSHOT
   ### Which project did you use? Sharding-JDBC or Sharding-Proxy?
   Sharding-JDBC
   ### Expected behavior
   The test `org.apache.shardingsphere.shardingjdbc.jdbc.core.datasource.MasterSlaveDataSourceTest#assertGetDatabaseProductName` always passes regardless of iteration orders of the map iterator.
   ### Actual behavior
   Test can fail if the order changes
   ### Reason analyze (If you can)
   
   Currently, the test uses a HashMap to store data source connections. However HashMap does not guarantee any specific order of entries. In particular, `createCachedDatabaseMetaData` in `MasterSlaveRuntimeContext.java` will eventually receive the map and access the first connection, which may not always be the master connection due to differences in orderings, and close that connection. If the first connection happens to be a slave connection, the test will fail due to being closed too many times.
   
   ### Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
   To simulate a different ordering, changing the `"masterDatasource"` to `"zmasterDatasource"` in https://github.com/apache/incubator-shardingsphere/blob/818a722b15dd66385be644c592016bcba53a7675/sharding-jdbc/sharding-jdbc-core/src/test/java/org/apache/shardingsphere/shardingjdbc/jdbc/core/datasource/MasterSlaveDataSourceTest.java#L110 will lead to a different iteration order and the test fails
   
   ### Example codes for reproduce this issue (such as a github link).
   ```
           dataSourceMap.put("zmasterDataSource", masterDataSource);
           dataSourceMap.put("slaveDataSource1", slaveDataSource1);
           dataSourceMap.put("slaveDataSource2", slaveDataSource2);
   ```
   in `assertGetDatabaseProductName()`

----------------------------------------------------------------
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.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services