Re: [I] Routed target `XXXX` does not exist, available targets are `[ds0, ds1]`. [shardingsphere]

["interest2 (via GitHub)" <gi...@apache.org>]

interest2 commented on issue #31661:
URL: https://github.com/apache/shardingsphere/issues/31661#issuecomment-3017600081

   Hi all, the problem is about thread safety, and has actually been fixed by @FlyingZC in 2024.02，
   In other words, the problem was fixed since 5.5.0, while it does exist below that version like 5.4.x.
   ![Image](https://github.com/user-attachments/assets/0d7d35d2-0e60-424d-81ba-a892e4c8d903)
   
   The crucial change of that commit was removing @SingletonSPI from InlineExpressionParser.java
   ![Image](https://github.com/user-attachments/assets/1353f6e8-b02e-4b86-a0c7-77b7b6056fe1)
   
   Why was it removed? It is related to the code below:
   ![Image](https://github.com/user-attachments/assets/ce82b935-2cbf-49a6-a3ea-a45119e85c0d)
   
   When InlineExpressionParser is annotated with @SingletonSPI, the parser is shared across all threads, creating the possibility of data pollution between different threads.
   
   Specifically, a valid SQL requires routing boths the database index and the table index, and both go through the code below in InlineShardingAlgorithm.java:
   ![Image](https://github.com/user-attachments/assets/ad9f8f22-e937-4b53-810c-bea147b56dae)
   
   **newInstance** method obtains an instance of GroovyInlineExpressionParser, and set the algorithmExpression of database or table;
   **evaluateClosure** method retrieves groovy script from local cached map, using the expression above as the key.
   
   In 5.4.x, that parser is shared (due to @SingletonSPI), so the algorithmExpression could be overwritten by another thread in high concurrency scenario. For example, this is what might happen in sequence:
   1.   Thread A has just finished routing database index;
   2.   Thread B sets the algorithmExpression of database for the parser; 
   3.   Thread A overwrites it to the algorithmExpression of table;
   4.   Thread B executes evaluateClosure(), will get the wrong groovy script because using the wrong algorithmExpression.
   
   That’s why it hints: Routed target XXXX does not exist, because routed target is derived from the wrong routing script.
   
   In summary, version since 5.5.0 fixed such thread safety issue by removing @SingletonSPI from InlineExpressionParser,  ensuring that each thread uses its own parser instance.


-- 
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: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org