Параллельная работа puppeteer-with-fingerprints?

Поддержка
  • Спасибо, я сейчас как раз попробую простой пример из examples.
    Вариант с разными "setWorkingFolder" для разных процессов тоже думал, возможно мне будет достаточно простой реализации, скоро увидим )

  • Я сейчас использую метод из examples, а именно: multithreading.js через какое-то время вываливаются ошибки:

    UNCAUGHT EXCEPTION: Lock is not acquired/owned by you
    Error: Lock is not acquired/owned by you
        at C:\Users\Administrator\Develope\PROC\node_modules\proper-lockfile\lib\lockfile.js:285:43
        at LOOP (node:fs:2824:14)
        at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
    

    Всего 10 потоков :(( посоветуйте что делать?

  • @DevBox попробуйте использовать разные папки для потоков, ещё для безопасности можно синхронизировать полностью участок fetch + launch, например, с помощью этого пакета - https://www.npmjs.com/package/async-lock.

  • Я как раз ищу mutex :) спасибо, попробую!

  • @DevBox said in Параллельная работа puppeteer-with-fingerprints?:

    К чему вы пришли, как лучше запускать параллельно?

    BAS стартует, запускает сторонний скрипт, которые генерит для него задания. Далее BAS обрабатывает задания и запускает другой скрипт с параметрами запущенных браузеров(remote-debugging-port).

    Последний скрипт делает всю работу по управлению браузерами, логикой, etc.

    https://github.com/sergerdn/py-bas-automation

  • С одним вроде справляешься, новое вылезает 🤦

    UNCAUGHT EXCEPTION: read ECONNRESET
    Error: read ECONNRESET
        at TCP.onStreamRead (node:internal/stream_base_commons:217:20)
    

    Кладёт всё приложение вне зависимости сколько там у тебя потоков и сколько папок :(( пока не нажмёшь ctrl+c

  • @DevBox есть такое решение, хоть и не идеальное:

    https://github.com/CheshireCaat/browser-with-fingerprints/issues/13#issuecomment-1793508120

  • Я как раз таким решением ловлю подобные вещи. Но это прям всё приложение вешает, даже setInterval стопаются, которые мне статистику скидывают. Попробую stack trace нарулить или хотя бы момент где это происходит.

  • Вот где-то тут жёстко виснет, условно навсегда )

    --------------------------------
    2024-05-20T12:55:05.768Z: read ECONNRESET
    Error: read ECONNRESET
        at TCP.onStreamRead (node:internal/stream_base_commons:218:20)
    --------------------------------
    2024-05-20T13:05:35.377Z: write ECONNABORTED
    Error: write ECONNABORTED
        at afterWriteDispatched (node:internal/stream_base_commons:161:15)
        at writeGeneric (node:internal/stream_base_commons:152:3)
        at Socket._writeGeneric (node:net:953:11)
        at Socket._write (node:net:965:8)
        at writeOrBuffer (node:internal/streams/writable:564:12)
        at _write (node:internal/streams/writable:493:10)
        at Writable.write (node:internal/streams/writable:502:10)
        at Socket.<anonymous> (C:\Users\Administrator\Develope\PROC\node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18)
        at Socket.emit (node:events:520:28)
        at addChunk (node:internal/streams/readable:559:12)    
    
  • @DevBox попробуйте на сам socket повешать обработчик ошибок, видимо client рвет соединение. Но ещё нужно смотреть почему он его рвёт, я сильно не изучал как там все устроено.

  • @UserTrue Я сам сокет не создаю :\ это где-то внутри node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18
    Т.е. скрипт работает, тупо встаёт, допустим через час я к монитору подхожу, вижу что висит, шлю ему SIGKILL (ctrl + c)
    Он вываливает ошибку:

    --------------------------------
    2024-05-20T20:02:56.118Z: write ECONNABORTED
    Error: write ECONNABORTED
        at afterWriteDispatched (node:internal/stream_base_commons:161:15)
        at writeGeneric (node:internal/stream_base_commons:152:3)
        at Socket._writeGeneric (node:net:953:11)
        at Socket._write (node:net:965:8)
        at writeOrBuffer (node:internal/streams/writable:564:12)
        at _write (node:internal/streams/writable:493:10)
        at Writable.write (node:internal/streams/writable:502:10)
        at Socket.<anonymous> (C:\Users\Administrator\Develope\PROC\node_modules\browser-with-fingerprints\src\plugin\connector\server\index.js:18:18)
        at Socket.emit (node:events:520:28)
        at addChunk (node:internal/streams/readable:559:12)
    --------------------------------
    2024-05-20T20:03:42.856Z: read ECONNRESET
    Error: read ECONNRESET
        at TCP.onStreamRead (node:internal/stream_base_commons:218:20)  
    

    И самое интересное, продолжает дальше работать как ни в чём не бывало )))
    Т.е. там где-то внутри соке ждёт без какого-либо таймаута, хрен бы с ним вывалил бы какю-нибудь ошибку, я бы её обработал и пошёл он дальше гулять, так нет, он просто встаёт :(
    И это такие свистопляски на AMD EPYC 7351P 16-Core Processor с оперативкой в 256 гиг, я бы ещё понял, если бы я на древнем селероне запускал и он бы так выпендривался. но нет, вполне сносный процессор, чистого chromium он может держать примерно 50-56 потоков.

  • @DevBox посмотрю, когда буду обновлять движок у плагинов - не могу сказать причину (сервер всегда стартует на рандомном свободном порту), почему рвется соединения, но постараюсь повторить.

    Пока попробуйте это - https://stackoverflow.com/questions/71980181/nodejs-uncaught-econnaborted-socket-exception.

    Так же можете до обновления добавить error handling сюда (прямо руками в node_modules), возможно поможет:

    https://github.com/CheshireCaat/browser-with-fingerprints/blob/master/src/plugin/connector/server/index.js#L10

  • @DevBox said in Параллельная работа puppeteer-with-fingerprints?:

    Т.е. скрипт работает, тупо встаёт

    Я когда-то давно смотрел как работает что внутри, если не ошибаюсь, то сделано так, что при наличии любых ошибок посланной команды, скрипт будет висеть вечно. Не проверяется ничего и нигде. Тестов толком тоже нет.

    Также есть библиотека на python для удаленного вызова функций из BAS, там сделано также. Офигел в свое время переделывать.

    Было даже так, что коннектишься к браузеру, убиваешь браузер из консоли, а скрипт как висел, так и будет висеть, потому что внутри библиотеки архитектурная ошибка логики работы с websocket между скриптом и BAS.

  • @Oyasumi-Punpun , спасибо, попробую

  • 0 Votes
    3 Posts
    594 Views
  • 0 Votes
    1 Posts
    361 Views
  • 0 Votes
    6 Posts
    764 Views
  • 0 Votes
    2 Posts
    501 Views
  • 0 Votes
    3 Posts
    767 Views