WebSVN – SmartDukaan – Diff – //trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java

 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.Arrays;
 import java.util.List;
 import java.util.stream.Collectors;
 @Component
 public class StandAlone {
 	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;
+	/** The browser lane's rotation, in turn order. */
+	private static final List<String> BROWSER_BRANDS = Arrays.asList("Oppo", "Realme");
 	/**
-	 * Oppo and Realme share ONE thread and one work queue.
+	 * Round-robin cursor across BROWSER_BRANDS.
+	 *
+	 * Not an AtomicInteger: this lane is a single @Scheduled(fixedDelay) job, so Spring
-	 * Replaces the separate oppo() and realme() jobs. Nothing else in this class runs a
+	 * never runs two of its ticks at once and the increment has nothing to race with.
-	 * browser, so with a single caller there is exactly one ChromeDriver alive at any
+	 * volatile only for visibility -- consecutive ticks are serialised but land on
+	 * whichever scheduled-task-pool thread is free, and a stale read here would break the
-	 * moment -- down from four. Peak concurrent drivers is what triggers the OOM killer
+	 * alternation. floorMod keeps it correct when it eventually overflows.
+	 */
-	 * on this box, not average driver-seconds.
+	private volatile int turn = 0;
+	/**
+	 * Oppo and Realme share ONE thread and one work queue, ONE CHUNK PER TICK.
 	 *
-	 * ONE FULL PASS PER DAY, and no imei is asked twice inside a pass. Both pools are
+	 * Called every 20 seconds. Each call takes the next brand in the rotation, asks the
+	 * pool query for its next CHUNK, runs exactly that chunk, and returns. When a brand's
-	 * snapshotted before any browser starts and the pass walks those lists to the end;
+	 * pool comes back empty its turn is skipped and the other brand keeps the lane; when
-	 * it never re-queries. That is the whole fix for the re-ask loop:
+	 * both are empty the tick does nothing at all and stays silent until midnight.
 	 *
+	 * Nothing else in this class runs a browser, so with a single caller there is exactly
-	 *   A failed lookup writes no row (dateMap.put is only reached on the success path),
+	 * one ChromeDriver alive at any moment. Peak concurrent drivers is what triggers the
-	 *   so createTimestamp is not bumped, so the imei was still eligible on the next tick
+	 * OOM killer on this box, not average driver-seconds, and a tick model does not change
-	 *   five minutes later. Measured 29-Aug: realme issued 4,524 requests against just
+	 * that number -- it only changes how the same driver-seconds are laid out in the day.
+	 *
+	 * ⚠ THE POOL QUERY IS THE CURSOR. There is no snapshot and no in-memory position. An
-	 *   1,004 distinct imeis -- 4.5 asks each, 78% of the day's budget spent re-asking --
+	 * imei leaves the pool because a row was stamped for it, which is why every asked imei
-	 *   while oppo, which rarely fails, sat at 1.03. More requests hardened the block,
+	 * must be stamped whatever the outcome -- see restUnanswered on the two services. An
+	 * imei that is asked and not stamped is handed straight back on the next tick, twenty
-	 *   which caused more failures, which caused more requests.
+	 * seconds later, and the lane stops advancing.
 	 *
-	 * A snapshotted pass bounds that structurally: a failure costs one retry TOMORROW,
+	 * That is also what replaces the snapshot the previous version relied on. The snapshot
+	 * existed to stop the re-ask loop measured on 29-Aug -- realme issued 4,524 requests
+	 * against 1,004 distinct imeis, 4.5 asks each, 78% of the day's budget spent re-asking,
-	 * never one in five minutes, no matter how the far end misbehaves.
+	 * because a failed lookup wrote no row and was eligible again five minutes later.
+	 * Stamping closes that at the source instead, and costs nothing the snapshot was buying:
+	 * a failure still waits until tomorrow, DAYS=0 still means one ask per imei per day.
 	 *
-	 * Sizing, measured on prod 2026-08-31 for a pass starting at midnight: oppo 4,133 and
+	 * What the snapshot cost, and this does not: a restart threw the day away. The pass
-	 * 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
+	 * held one thread for 20+ hours and kept its position only in that thread's stack, so
-	 * seconds regress the pass will not finish and the tail rolls into the next day.
+	 * the 12:03 restart on 09-Sep forfeited roughly 4,000 lookups and the whole afternoon,
-	 * Watch the "Daily pass finished" line: counts short of the "starting" line are the
+	 * and the funnel had reported last_finish = -1 for three days running. A tick loses at
-	 * signal, and the lever is DAYS=1 (halves the work) rather than a second thread.
+	 * most the chunk in flight.
 	 *
+	 * Sizing, measured on prod 2026-08-31: oppo 4,133 and realme 2,118 imeis at 10.2s and
-	 * Excluding stock billed today or yesterday is correctness, not capacity -- measured,
+	 * 14.2s each is 20.1 hours of a single thread. Add 20s per chunk and it is 21.4 hours --
-	 * it trims 30 imeis from oppo and 9 from realme. A handset billed in the last 48
+	 * it fits, but only at those per-imei costs. Measured again on 09-Sep the lane was at
-	 * hours has essentially never been activated yet, and the cohort data agrees: the
+	 * ~21s per imei, twice the sizing, which needs ~35 hours and does not fit. So expect the
+	 * pool NOT to clear on a bad day: the lane will still be working at midnight, beginDay
+	 * will log the truncation, and the tail rolls over. The tick model makes that visible
-	 * sold-within-180-days cohort returns a date on 2.4% (vivo) to 8.4% (oppo) of
+	 * and survivable; it does not create capacity. The lever for capacity is DAYS=1, which
-	 * lookups, against 43-97% for stock sold over a year ago.
+	 * halves the daily load by asking each brand every other day.
+	 *
 	 * ⚠ 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
+	 * canvas wait is 15s against oppo's 8s, so the longer wait is the one expiring. Spacing
-	 * 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
+	 * the same volume across the day does not move that number -- total daily requests is
-	 * blocking and judge the change on dates written, not on timeout count. What the
+	 * what the far end counts -- so judge this change on dates written and on whether 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.
+	 * day clears, not on timeout count.
 	 */
 	public void checkBrowserImeiActivation() {
-		List<String> oppo = pendingFor("Oppo");
+		for (int attempt = 0; attempt < BROWSER_BRANDS.size(); attempt++) {
-		List<String> realme = pendingFor("Realme");
+			String brand = BROWSER_BRANDS.get(Math.floorMod(turn++, BROWSER_BRANDS.size()));
-		gauges.beginPass("Oppo", oppo.size());
+			List<String> chunk = dueNow(brand);
-		gauges.beginPass("Realme", realme.size());
+			if (chunk.isEmpty()) {
-		try {
-			if (oppo.isEmpty() && realme.isEmpty()) {
+				// Cleared for today. Say so once, then let every later tick pass in silence:
-				LOGGER.info("Oppo and Realme: nothing due today, not starting a browser");
+				// at 20 seconds a line per idle tick is 4,320 a day, per brand.
-				return;
+				gauges.endDay(brand);
-			}
-			int oppoDone = 0;
+				continue;
-			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.
+			runBrand(brand, chunk, batchFor(brand));
-			gauges.endPass("Oppo");
+			gauges.churned(brand, chunk.size());
-			gauges.endPass("Realme");
+			return;
+		}
+	}
 	/**
-	 * 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.
+	 * This brand's next chunk, and the day's denominator on the first tick after midnight.
+	 *
-	 * Chunking exists only to recycle the browser -- a driver held open for the whole
+	 * The full pool is fetched once a day purely to have something to measure progress
-	 * pass would leak memory on a box that has been OOM-killed twice, and a crash would
+	 * against -- POOL_CAP rows instead of CHUNK, one extra query per brand per day, the
-	 * cost the entire pool rather than CHUNK imeis. It deliberately does NOT re-query:
+	 * same query the old midnight pass ran. Its head doubles as that tick's chunk, so the
-	 * re-querying between chunks is what produced the 4.5 lookups per imei per day that
+	 * sizing costs no extra work. Every later tick asks for CHUNK and nothing more.
-	 * this rewrite removes.
 	 */
-	private int runChunk(String brand, List<String> pool, int from, ImeiBatch batch) {
+	private List<String> dueNow(String brand) {
-		if (from >= pool.size()) {
+		if (gauges.needsDayStart(brand)) {
+			List<String> pool = pendingFor(brand, POOL_CAP);
-			return 0;
+			gauges.beginDay(brand, pool.size());
+			return pool.size() <= CHUNK ? pool : new ArrayList<>(pool.subList(0, CHUNK));
+		}
-		List<String> chunk = pool.subList(from, Math.min(from + CHUNK, pool.size()));
-		runBrand(brand, chunk, batch);
+		return pendingFor(brand, CHUNK);
+	}
-		gauges.churned(brand, chunk.size());
+	private ImeiBatch batchFor(String brand) {
-		return chunk.size();
+		return "Oppo".equals(brand)
+				? oppoImeiActivationService::updateActivationDate
+				: realmeImeiActivationService::updateActivationDate;
+	}
 	/**
 	 * 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
 	private interface ImeiBatch {
 		void run(List<String> imeis) throws Exception;
+	}
 	/**
-	 * Everything due for one brand today, as a single list.
+	 * The next `maxResults` imeis due for one brand, newest query wins -- there is no
+	 * cached list anywhere, so this is the lane's only notion of position.
+	 *
 	 * 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
+	 * visible at all. See interleave for why they are merged by turns rather than joined
-	 * by ordering and a plain concatenation is enough.
+	 * end to end.
+	 *
+	 * ⚠ Neither named query has an ORDER BY, so rows arrive in whatever order MySQL
-	 * The pools are disjoint by construction -- the secondary query excludes anything
+	 * returns and each tick's chunk is an arbitrary slice of what is still due. That is
+	 * survivable but wasteful: hit rate per lookup is 8.4% for oppo stock sold within
-	 * with a FofoLineItem -- so distinct() is cheap insurance, not a fix for a known
+	 * 180 days against 97.5% for stock sold over a year ago, so an `order by
+	 * o.billingTimestamp asc` in the two named queries would drain the productive cohort
+	 * first. It is a dao change and deliberately not made here.
+	 *
-	 * overlap. The brand-generic call is used for every brand; the realme-named copy of
+	 * The brand-generic call is used for every brand; the realme-named copy of it has
-	 * it has been deleted, it was a verbatim duplicate down to the named query.
+	 * been deleted, it was a verbatim duplicate down to the named query.
 	 */
-	private List<String> pendingFor(String brand) {
+	private List<String> pendingFor(String brand, int maxResults) {
-		List<String> pool = new ArrayList<>();
+		List<String> secondary = serials(
-		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrand(brand, DAYS, POOL_CAP)
+				activatedImeiRepository.selectImeiActivationPendingByBrand(brand, DAYS, maxResults));
-				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));
+		List<String> tertiary = serials(
-		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrandTertiary(brand, DAYS, POOL_CAP)
+				activatedImeiRepository.selectImeiActivationPendingByBrandTertiary(brand, DAYS, maxResults));
+		List<String> pool = interleave(secondary, tertiary).stream()
+				.distinct()
+				.limit(maxResults)
-				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));
+				.collect(Collectors.toList());
-		if (pool.size() >= POOL_CAP) {
+		if (maxResults == POOL_CAP && pool.size() >= POOL_CAP) {
-			LOGGER.warn("{} pool hit the {} cap -- the pass will not cover everything due today", brand, POOL_CAP);
+			LOGGER.warn("{} pool hit the {} cap -- today's due count is a floor, not the true total",
+					brand, POOL_CAP);
+		}
+		return pool;
+	}
+	private static List<String> serials(List<ImeiActivationTimestampModel> rows) {
+		return rows.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList());
+	}
+	/**
+	 * Take from both queues by turns rather than concatenating them.
+	 *
+	 * Plain concatenation was correct while a pass snapshotted everything and walked it to
+	 * the end -- ordering could not starve anything that was going to be reached anyway.
+	 * A chunk-at-a-time lane has no such guarantee: it stops wherever midnight finds it,
+	 * and on the measured per-imei cost it often will not reach the end. Concatenated,
+	 * oppo's 163 tertiary serials sit behind 3,819 secondary ones and would be asked only
+	 * on a day that fully cleared -- so the smaller queue would go months untouched.
+	 *
+	 * The two are disjoint by construction (the secondary query excludes anything carrying
+	 * a FofoLineItem), so distinct() downstream is insurance rather than a fix.
+	 */
+	private static List<String> interleave(List<String> first, List<String> second) {
+		List<String> merged = new ArrayList<>(first.size() + second.size());
+		for (int i = 0; i < Math.max(first.size(), second.size()); i++) {
+			if (i < first.size()) {
+				merged.add(first.get(i));
+			}
+			if (i < second.size()) {
+				merged.add(second.get(i));
+			}
+		}
-		return pool.stream().distinct().collect(Collectors.toList());
+		return merged;
+	}
 	/**
 	 * Motorola: secondary + tertiary in ONE browser session, same shape as the
 	 * oppo/realme combined jobs.

Subversion Repositories SmartDukaan

(root)//trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java – Rev 37482 → 37565