This will most likely be a problem in 2.5 as well as it seems to be a "limitation" of the JSON library we use. Internally, the library uses a signed 64-bit object to represent integer values in JSON objects. As we use unsigned 64-bit integers in MaxScale for statistics, the values should overflow into negative values even if the original value is not negative.

Upon further analysis, this isn't that important to fix any time soon. Since we don't measure anything that grows by very large amounts per client request, this is not that relevant right now. Unlike values like Bytes_sent or Rows_sent in MariaDB, the fastest growing counter in MaxScale would be the epoll event counters and the packet number counter, the latter of which only counts client side packets.

The original problem described in this issue is most likely due to the fact that readconnroute uses the following struct to track statistics:

struct Stats

{

    int n_sessions = 0;     /**< Number sessions created     */

    int n_queries = 0;      /**< Number of queries forwarded */

};

A signed 32-bit integer will roll over soon enough for this to become a problem. Converting these into unsigned 64-bit integers should be an adequate solution. If counters that truly do overflow the 64-bit signed integer are added, a separate function for those that truncates the value to 63-bits is needed. For now this doesn't seem necessary.