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/
