Subversion Repositories SmartDukaan

Rev

Go to most recent revision | Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
37565 30 d 22 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ IMEI activation: 20s tick lanes for oppo/realme/vivo, idle once the day clears

Replaces the two once-a-day passes with chunk-per-tick lanes. Each tick takes one
chunk and returns; when a brand's pool comes back empty its turn is skipped, and
when everything is clear the ticks do nothing and stay silent until midnight.

- browser lane (StandAlone): one chunk of 25 for one brand every 20s, oppo and
realme by turns. Still exactly one ChromeDriver alive at a time.
- vivo lane: its own tick, chunk of 250. It must not share the browser lane --
0.24s an imei against oppo's 10.2s means it would need ~70 hours behind them
for work it does alone in 39 minutes.

The snapshot is gone; the pool query is the cursor. That is what makes a restart
cost one chunk instead of the day: the 12:03 restart on 09-Sep forfeited ~4,000
lookups and the whole afternoon, and last_finish had read -1 for three days.

The snapshot existed to stop the re-ask loop (realme, 29-Aug: 4,524 requests
against 1,004 distinct imeis). That is now closed at the source instead -- oppo,
realme and motorola stamp every imei they asked about, not just the ones that
produced a map entry, so a failed lookup rests until tomorrow rather than coming
back on the next tick. Motorola is fixed pre-emptively; nothing schedules it yet.

Also:
- secondary and tertiary are merged by turns rather than concatenated. Safe while
a pass walked to the end; without that guarantee oppo's 163 tertiary serials sat
behind 3,819 secondary ones and would only be reached on a day that cleared.
- vivo abandons a tick rather than the chunk when the captcha solver returns no
code -- one probe per 20s while it is down instead of 250, and no rows rested
over a transient outage.
- the funnel gauges move from a pass to a day. due is measured on the first tick
after midnight, the rest accumulate, and last_finish_epoch becomes a real
completion clock. Truncation is detected at the midnight rollover, which is the
case that never reaches an end-of-run at all.

This does not create capacity. At the 21s/imei measured on 09-Sep the pool still
needs ~35 hours and will not clear; it now rolls over visibly instead of silently.
The lever for that is DAYS=1.
 
36253 181 d 15 h amit /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Separate secondary/tertiary IMEI activation crons for Vivo/Oppo/Realme, perf fixes: shared saveActivation, Response leak fixes, /tmp cleanup, OpenCV static init, early break, remove class-level @Transactional from StandAlone  
34415 544 d 10 h amit.gupta /trunk/ Fixed oppo activation  
34413 545 d 7 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Fixed oppo tracking issues  
30377 1622 d 4 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Added Einvoice Files  
30372 1622 d 6 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Added Einvoice Files  
30355 1626 d 8 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Fixed ahead issue  
30352 1626 d 10 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Fixed oppo  
30315 1637 d 7 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ Added Einvoice Files  
30209 1659 d 8 h amit.gupta /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ Added Oppo Activation