[IGNITE-11661] Jdbc Thin: Implement tests for best effort affinity

• Type: Task
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Fix Version/s: 2.8
• Component/s: jdbc
• Labels: iep-24
• Assignee: Alexander Lapin
• Reporter: Alexander Lapin
• Created: 01/Apr/19 08:26
• Updated: 17/Apr/19 16:08
• Resolved: 17/Apr/19 15:56

Description

Test plan draft.

1. Сheck that requests go to the expected number of nodes for different combinations of conditions
   • Transactional
     • Without params
       • Select
         • Different partition tree options(All/NONE/Group/CONST) produced by different query types.
       • Dml
         • - // -
     • With params
       • - // -
   • Non-Transactional
     • - // -
2. Check that request/response functionality works fine if server response lacks partition result.
3. Check that partition result is supplied only in case of rendezvous affinity function without custom filters.
4. Check that best effort functionality works fine for different partitions count.
5. Сheck that a change in topology leads to jdbc thin affinity cache invalidation.
   1. Topology changed during partition result retrieval.
   2. Topology changed during cache distribution retrieval.
   3. Topology changed during best-effort-affinity-unrelated query.
6. Check that jdbc thin best effort affinity works fine if cache is full and new data still coming. For given case we probably should decrease cache boundaries.
7. Check that proper connection is used if set of nodes we are connected to and set of nodes derived from partitions
   1. Fully intersect;
   2. Partially intersect;
   3. Doesn't intersect, i.e.

      User Specified	Derived from partitons
      host:port1 - > UUID1 host:port2 -> UUID2	partition1 -> UUID3

No intersection, so random connection should be used.

1. Check client reconnection after failure.
2. Check that jdbc thin best effort affinity skipped if it is switched off.

Issue Links

• is a child of: IGNITE-11287 JDBC Thin: best effort affinity