Поэтому приятнее всего работать в продуктовых командах, имхо)

Можно научиться ответственности за то что ты делаешь и заинтересованности в этом)

Ага, сказал такой "нужно закупить серваков таких то на 200к зелени", их закупили, а оказалось что 90% можностей недозагружено 😂

Вроде в вг команда участвует в выборе и расчете кол-ва закупаемых железок

Ну в качестве трамплина аутсорс не так плох. Если ты только ради 300к в наносекунду то тебе даже гуру НТ ничем не поможет будешь реально куа макакой

Можно попробовать без parallel controller.
По описанию важно только дождаться ответа по HTTP. И параллельно чего-то ждать в JSR223 уже не надо.
До HTTP-запроса отправить что-то в MQ, потом HTTP-запрос и ожидание ответа на него, потом зачистка или что-то что должно выполниться после, просто через PostProcessor.

И в приложении архитектурная проблема. Перед асинхронным интерфейсом (перед очередью) стоит синхронный интерфейс в виде HTTP REST-ручки. Надо на эту ручку выставлять огромный таймаут. И заводить дефект, просто по факту существования такой организации работы

Если оставить Parallel Controller, то надо добавить PostProcessor к HTTP-запросу, который может упасть раньше, чем придет ответ в очередь, которую вы читаете видимо в JSR-223 Sampler. В PostProcessor заполнить какой-то флаг, который скажет, что можно больше не ждать ответа. Организовать синхронизацию двух потоков Parallel Controler-а. Непростой вариант. Все из-за особеностей Parallel Controller, он не наследует ничего из родительсткого потока. Возможно только Property (props) можно использовать. Но вот вопрос, какую Property использовать - ? Сложно в общем

Простой формат синхронизации потоков такой. В JSR 223 при старте создать переменную со значением

def stop = System.currentTimeMillis() + 60000; //где 60 sec - таймаут на ответ по HTTP

Задать такой же таймаут 60 сек в HTTP-запросе. Есть такое поле.

А потом в JSR-223 добавить условие, что он выполняется пока
System.currentTimeMillis() < stop
и другие условия выполнения тоже должны быть истина

Синхронизация по времени

Про то, что тут нужно дефект архитектурный писать из-за того, что связка HTTP + Queue я загнул. Работаю тоже с сервисами, где запрос приходит по HTTP, а дальше там kafka и так далее.
Но меня не простые HTTP, а webSocket, то есть запрос асинхронный и ответ такой же. А внутри очереди.
А если запрос сихронный, а внутри очереди, то высокий риск тормозов.

Очереди они не про скорость. А про то, чтобы растянуть процесс выполнения во времени. Чтобы обработчик мог с комфортной для него скоростью обрабатывать запросы.

Бывает еще один баг про асихронность и сихронность. Надо уметь и ответы от очередей обрабатывать неспеша. По чуть-чуть. Бывает в приложениях с очередями такой тип дефекта произодительности, что когда в очередь одно приложение другому отвечает сразу 1000 ответов, то первое может попробовать создать сразу 1000 потоков обработки этих ответов. И тут у него закончатся все ресурсы. А надо не 1000 создавать, а по 10 например. Это же очередь, ее можно по чуть-чуть читать

Ты чего так про QA то говоришь )

Я как то QA задел?))

Прочитал тред да понял о чем )

Обычно это делают до 😀

Тут это до было слишком далеко)

ты ещё скажи, что инструкции читаешь ДО того как всё сломается)

ну ладно ладно, раскрыла, до не интересно😂

Ну а как же, можно же "до"  и до тз докапаться )

Это достойно мема)

И даже вопроса на собесе)

Вообще, я пока нашел из-за чего сыр бор,  прочитал советы от Славы, про аутсорс )