Регекспы, как Слава доказал, можно использовать - лни почти как баундари (хотя это от регулярки зависит и от размера текста, хехе)

Всем привет, кто нибудь сталкивался с такой проблемой в гатлинге? грубо говоря если пользоваться тулзой(bloomrpc) для отправки запросов то один сервис работает если выбрать сервер серт, а другой работает только с рут серт. Видимо гатлинг использует по умолчанию некий сервер серт если проводить аналогию с bloomrpc. А вот тот сервис который использует рут серт получаю такую ошибку:

Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
cause: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 000006040000000000000500004000

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

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

1) берёшь
2) тестируешь

ну нам чтобы что то подсказать нужно знать что за протоколы там хотя бы используются, какая архитектура

вот от кого я токсика не ожидал

нужна конкретика :(

на самом деле нужно понимание, в чём сложности с оплатой
Без неё звучит, как "подскажите статьи, где говорится, как тестировать"

тут ответ - недавно была отличная статья от Дмитрия из MIRO

вот эта

клиент серверная архитектура, mobile ios/android. Протоколы не подскажу, мне для ознакомления, пока что занимаюсь учебой.

какие экстракторы сложные?

благоларю, с этим ознакомлен, хороший доклад👍. еще такой же у них есть по андроиду

ну тогда наш коллективный ответ, берёшь инстурмент (jmeter) для простоты и пишешь скрипты на протоколе котроый нужно, настраиваешь мониторинг, поом запускаешь тестирование, смотришь мониторинги - делаешь выводы

ios android с большой долей вероятности шлют http запросы или подобное

поэтому неважно, просто эмулируешь скриптами работу приложения

Я думаю, что все, которые перед чтением преобразуют текст в объект

boundary и regexp могут начать читать мегабайтный текст, найти первое совпадение и остановиться.
css / xml и прочие сперва читают весь ответ, парсят его своими парсерами и потом уже в полученном объекте ищут
Чем больше ответ - тем медленее они будут работать, я так думаю

косвенно об этом же говорит славин доклад

PS регулярку можно написать так, чтобы она тоже анализировала весь текст. Но с регулярками вообще много как можно ухудшить себе жизнь, это не повод так делать :)

то есть не сложные а медленные?

А Слава на хейзене выступал с ним?

ну, я вот думаю, что я не стал бы это выносить в антипаттерны
потому что если анализируемый текст мелкий - разница будет не существенной, а вот удобнее будет