Subversion Repositories SmartDukaan

package com.smartdukaan.cron.scheduled;

import com.spice.profitmandi.dao.model.ImeiActivationTimestampModel;

import com.spice.profitmandi.dao.repository.fofo.ActivatedImeiRepository;

import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger;

import org.springframework.beans.factory.annotation.Autowired;

import com.smartdukaan.cron.monitored.ImeiActivationGauges;

import org.springframework.stereotype.Component;

import java.util.ArrayList;

import java.util.List;

import java.util.stream.Collectors;

@Component

public class StandAlone {

	@Autowired

	private OppoImeiActivationService oppoImeiActivationService;

	@Autowired

	private RealmeImeiActivationService realmeImeiActivationService;

	@Autowired

	private MotorolaImeiActivationService motorolaImeiActivationService;

	@Autowired

	private ActivatedImeiRepository activatedImeiRepository;

	@Autowired

	private ImeiActivationGauges gauges;

	private static final Logger LOGGER = LogManager.getLogger(StandAlone.class);

	/**

	 * ZERO, deliberately, and it is not an off-by-one.

	 *

	 * The pool query keeps rows with createTimestamp < now().atStartOfDay().minusDays(DAYS).

	 * At DAYS=1 an imei answered today is measured against YESTERDAY midnight, so it is

	 * not due tomorrow either -- it comes back the day after, a two-day cadence. DAYS=0

	 * measures against this morning's midnight, which is what "a full run each day"

	 * actually means. Oppo and realme ran at 1 before this change.

	 *

	 * Within a pass the snapshot already guarantees one ask per imei, so this constant

	 * only governs the gap BETWEEN passes.

	 */

	private static final int DAYS = 0;

	/** Imeis per browser session. Recycles the driver; does NOT re-query the pool. */

	private static final int CHUNK = 25;

	/** Safety stop so a mis-set DAYS cannot pull an unbounded list into memory. */

	private static final int POOL_CAP = 10000;

	/**

	 * Oppo and Realme share ONE thread and one work queue.

	 *

	 * Replaces the separate oppo() and realme() jobs. Nothing else in this class runs a

	 * browser, so with a single caller there is exactly one ChromeDriver alive at any

	 * moment -- down from four. Peak concurrent drivers is what triggers the OOM killer

	 * on this box, not average driver-seconds.

	 *

	 * ONE FULL PASS PER DAY, and no imei is asked twice inside a pass. Both pools are

	 * snapshotted before any browser starts and the pass walks those lists to the end;

	 * it never re-queries. That is the whole fix for the re-ask loop:

	 *

	 *   A failed lookup writes no row (dateMap.put is only reached on the success path),

	 *   so createTimestamp is not bumped, so the imei was still eligible on the next tick

	 *   five minutes later. Measured 29-Aug: realme issued 4,524 requests against just

	 *   1,004 distinct imeis -- 4.5 asks each, 78% of the day's budget spent re-asking --

	 *   while oppo, which rarely fails, sat at 1.03. More requests hardened the block,

	 *   which caused more failures, which caused more requests.

	 *

	 * A snapshotted pass bounds that structurally: a failure costs one retry TOMORROW,

	 * never one in five minutes, no matter how the far end misbehaves.

	 *

	 * Sizing, measured on prod 2026-08-31 for a pass starting at midnight: oppo 4,133 and

	 * realme 2,118 imeis, which at 10.2s and 14.2s each is 11.7h + 8.4h = 20.1 hours of a

	 * single thread -- an 84% duty cycle. It fits, but there is NO slack. If per-imei

	 * seconds regress the pass will not finish and the tail rolls into the next day.

	 * Watch the "Daily pass finished" line: counts short of the "starting" line are the

	 * signal, and the lever is DAYS=1 (halves the work) rather than a second thread.

	 *

	 * Excluding stock billed today or yesterday is correctness, not capacity -- measured,

	 * it trims 30 imeis from oppo and 9 from realme. A handset billed in the last 48

	 * hours has essentially never been activated yet, and the cohort data agrees: the

	 * sold-within-180-days cohort returns a date on 2.4% (vivo) to 8.4% (oppo) of

	 * lookups, against 43-97% for stock sold over a year ago.

	 *

	 * ⚠ Realme's ceiling is a REQUEST-VOLUME ceiling, not a CPU one. realme.com stops

	 * serving the captcha widget as the day's request count climbs: measured 920/day ->

	 * 0.3% canvas timeouts, 3,467/day -> 28%, 4,524/day -> 75%, resetting at midnight --

	 * while oppo on the same box, same driver count, same widget vendor, at 4,350/day had

	 * ZERO timeouts across all 24 hours, on a box loaded at 0.9 of 6 cores. Realme's own

	 * canvas wait is 15s against oppo's 8s, so the longer wait is the one expiring. A

	 * daily pass puts realme near 2,127 requests/day, between the 920/day point where it

	 * was healthy and the 3,467/day point where it was 28% blocked -- so expect SOME

	 * blocking and judge the change on dates written, not on timeout count. What the

	 * pass guarantees is that blocking can no longer feed itself.

	 *

	 * Oppo and realme alternate chunk by chunk, so whichever pool still has work keeps

	 * the thread busy once the other is exhausted.

	 */

	public void checkBrowserImeiActivation() {

		List<String> oppo = pendingFor("Oppo");

		List<String> realme = pendingFor("Realme");

		gauges.beginPass("Oppo", oppo.size());

		gauges.beginPass("Realme", realme.size());

		try {

			if (oppo.isEmpty() && realme.isEmpty()) {

				LOGGER.info("Oppo and Realme: nothing due today, not starting a browser");

				return;

			}

			int oppoDone = 0;

			int realmeDone = 0;

			while (oppoDone < oppo.size() || realmeDone < realme.size()) {

				oppoDone += runChunk("Oppo", oppo, oppoDone, oppoImeiActivationService::updateActivationDate);

				realmeDone += runChunk("Realme", realme, realmeDone, realmeImeiActivationService::updateActivationDate);

			}

		} finally {

			// In a finally so a pass killed part-way still publishes what it managed.

			// A truncated pass is exactly the case worth alerting on, so it must not be

			// the case that silently reports nothing.

			gauges.endPass("Oppo");

			gauges.endPass("Realme");

		}

	}

	/**

	 * One driver session's worth of one brand, taken from a list that was snapshotted

	 * before the pass began. Returns how many were consumed so the caller can advance.

	 *

	 * Chunking exists only to recycle the browser -- a driver held open for the whole

	 * pass would leak memory on a box that has been OOM-killed twice, and a crash would

	 * cost the entire pool rather than CHUNK imeis. It deliberately does NOT re-query:

	 * re-querying between chunks is what produced the 4.5 lookups per imei per day that

	 * this rewrite removes.

	 */

	private int runChunk(String brand, List<String> pool, int from, ImeiBatch batch) {

		if (from >= pool.size()) {

			return 0;

		}

		List<String> chunk = pool.subList(from, Math.min(from + CHUNK, pool.size()));

		runBrand(brand, chunk, batch);

		gauges.churned(brand, chunk.size());

		return chunk.size();

	}

	/**

	 * One brand's turn. Wrapped so a failure in the first brand still lets the second

	 * one run -- these are separate sites and separate driver sessions, and a realme

	 * outage must not cost oppo its whole tick.

	 */

	private void runBrand(String brand, List<String> imeis, ImeiBatch batch) {

		if (imeis.isEmpty()) {

			return;

		}

		LOGGER.info("{} imeis {}", brand, imeis);

		try {

			batch.run(imeis);

		} catch (Exception e) {

			gauges.error(brand);

			LOGGER.error("{} activation batch failed, continuing with the next brand", brand, e);

		}

	}

	@FunctionalInterface

	private interface ImeiBatch {

		void run(List<String> imeis) throws Exception;

	}

	/**

	 * Everything due for one brand today, as a single list.

	 *

	 * The secondary/tertiary split is an artefact of there being two join paths to a

	 * serial (transaction.lineitem vs fofo.fofo_line_item), not two kinds of work: both

	 * funnel into the same updateActivationDate -> checkWarranty -> saveActivation path.

	 * They were separate jobs with separate batch sizes, which is what made the split

	 * visible at all. A pass walks the whole list to the end, so nothing can be starved

	 * by ordering and a plain concatenation is enough.

	 *

	 * The pools are disjoint by construction -- the secondary query excludes anything

	 * with a FofoLineItem -- so distinct() is cheap insurance, not a fix for a known

	 * overlap. The brand-generic call is used for every brand; the realme-named copy of

	 * it has been deleted, it was a verbatim duplicate down to the named query.

	 */

	private List<String> pendingFor(String brand) {

		List<String> pool = new ArrayList<>();

		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrand(brand, DAYS, POOL_CAP)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));

		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrandTertiary(brand, DAYS, POOL_CAP)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));

		if (pool.size() >= POOL_CAP) {

			LOGGER.warn("{} pool hit the {} cap -- the pass will not cover everything due today", brand, POOL_CAP);

		}

		return pool.stream().distinct().collect(Collectors.toList());

	}

	/**

	 * Motorola: secondary + tertiary in ONE browser session, same shape as the

	 * oppo/realme combined jobs.

	 *

	 * Cadence: the pool query defers an imei for `days` after each attempt

	 * (saveActivation bumps createTimestamp even when no date came back), so

	 * days=2 gives the requested "retry everything every two days".

	 *

	 * Sizing: the pending pool measured 1,534 (1,182 secondary + 352 tertiary).

	 * At the ~10-14s/imei the oppo and realme jobs measure, 60 per invocation is

	 * roughly 12 minutes of driver time, and clearing 1,534 inside 48h needs

	 * about 26 invocations -- i.e. an OS cron entry every 90 minutes, with

	 * headroom. Do NOT schedule it inside the oppo/realme window: each driver

	 * tree costs ~850MB and this box has been OOM-killed twice with tomcat the

	 * victim, so peak concurrent drivers is the number that matters.

	 */

	public void checkMotorolaImeiStatusCombined() throws Exception {

		List<String> secondary = activatedImeiRepository.selectImeiActivationPendingByBrand("Motorola", 2, 30)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList());

		List<String> tertiary = activatedImeiRepository.selectImeiActivationPendingByBrandTertiary("Motorola", 2, 30)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList());

		LOGGER.info("Motorola secondary imeis {}", secondary);

		LOGGER.info("Motorola tertiary imeis {}", tertiary);

		List<String> all = new ArrayList<>(secondary);

		all.addAll(tertiary);

		all = all.stream().distinct().collect(Collectors.toList());

		if (all.isEmpty()) {

			LOGGER.info("Motorola: nothing pending, not starting a browser");

			return;

		}

		motorolaImeiActivationService.updateActivationDate(all);

	}

}