Hi, My first thought is deploying a service [1] (remotely dynamically Ignite.services().deploy() or statically IgniteConfiguration.setServiceConfiguration()) clearing problematic map periodically.
[1] https://apacheignite.readme.io/docs/service-grid пн, 11 нояб. 2019 г. в 13:20, mvkarp <liquid_ninj...@hotmail.com>: > > Hi, > > Would you have any suggestion on how to implement a last chance workaround > for this issue for the server JVM? > > > Ivan Pavlukhin wrote > > Hi, > > > > I suspect a following here. Some node treats itself as a MVCC > > coordinator and creates a new RecoveryBallotBox when each client node > > leaves. Some (may be all) other nodes think that MVCC is disabled and > > do not send a vote (assumed for aforementioned ballot box) to MVCC > > coordinator. Consequently a memory leak. > > > > A following could be done: > > 1. Figure out why some node treats itself MVCC coordinator and others > > think that MVCC is disabled. > > 2. Try to introduce some defensive matters in Ignite code to protect > > from the leak in a long running cluster. > > > > As a last chance workaround I can suggest writing custom code, which > > cleans recoveryBallotBoxes map from time to time (most likely using > > reflection). > > > > пн, 11 нояб. 2019 г. в 08:53, mvkarp < > > > liquid_ninja2k@ > > > >: > >> > >> We have frequently stopping and starting clients in short lived client > >> JVM > >> processes as required for our purposes, this seems to lead to a huge > >> bunch > >> of PME (but no rebalancing) and topology changes (topVer=300,000+) > >> > >> Still can not figure out why this map won't clear (there are no > >> exceptions > >> or err at all in the entire log) > >> > >> > >> > >> -- > >> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ -- Best regards, Ivan Pavlukhin
