I wasn't able to reproduce this problem but I did find a bug that could possibly explain why it wouldn't work.

Wasn't fixed by 2.3.3.

Possibly caused by the added caching of query parsing results.

Update: Testing of this hypothesis seems to point towards the query classifier but not to the query classifier cache. The following valgrind output seems to reveal at least one source of memory use:

==16903== 54,100,528 bytes in 397,798 blocks are possibly lost in loss record 1,647 of 1,647

==16903==    at 0x4C2EE3B: malloc (vg_replace_malloc.c:309)

==16903==    by 0xAEA9434: sqlite3MemMalloc (sqlite3.c:18629)

==16903==    by 0xAEA99FC: sqlite3Malloc (sqlite3.c:22332)

==16903==    by 0xAEAA0C0: dbMallocRawFinish (sqlite3.c:22655)

==16903==    by 0xAEAA23B: sqlite3DbMallocRawNN (sqlite3.c:22723)

==16903==    by 0xAF0F77A: sqlite3SelectNew (sqlite3.c:110695)

==16903==    by 0xAF3158D: yy_reduce (sqlite3.c:132187)

==16903==    by 0xAF364EA: sqlite3Parser (sqlite3.c:134244)

==16903==    by 0xAF37809: sqlite3RunParser (sqlite3.c:135497)

==16903==    by 0xAF0EE3C: sqlite3Prepare (sqlite3.c:110302)

==16903==    by 0xAF0F1C0: sqlite3LockAndPrepare (sqlite3.c:110401)

==16903==    by 0xAF0F31D: sqlite3_prepare (sqlite3.c:110465)

==16903== 

==16903== LEAK SUMMARY:

==16903==    definitely lost: 0 bytes in 0 blocks

==16903==    indirectly lost: 0 bytes in 0 blocks

==16903==      possibly lost: 176,050,576 bytes in 1,992,001 blocks

Further testing with readconnroute seems to point towards the query classifier as the culprit. To verify this, the dump should be done via readconnroute and the memory use should be measured.

During the investigation into how MaxScale behaves when a large amount of data is sent through it, it was discovered that the client protocol module would perform unbounded reads from the client socket resulting in excessive use of memory. The network throttling was working correctly but by the time it was engaged, the damage was already done: everything the client read on the first go was already stored in memory. To prevent this, the client protocol module should read at most one packet (roughly 16MB worth of data) at a time and then proceed with the routing. With this change, the throttling limitation is respected more accurately and the maximum overshoot in memory usage will be limited to about 16MB.