VS
а нужно явно и свой
Size: a a a
2019 November 09
RI
Мне нравится, это и async клиент появился из коробки, и корутины. Можно будет наконц-то использовать jmeter вместо gatling
Ⓢ
Ⓢ
Ⓢ
Вот это правильно или нет?
AN
вот так тоже не рекомендуют делать, поскольку снаружи отминить нельзя. Вполне рабочий вариант, но идеоматично все-таки прокидывать скоупы сверху вниз, не собирая их руками
VS
вот так тоже не рекомендуют делать, поскольку снаружи отминить нельзя. Вполне рабочий вариант, но идеоматично все-таки прокидывать скоупы сверху вниз, не собирая их руками
Что именно отменить нельзя снаружи?
Вот API для «отмены»: https://github.com/apache/jmeter/blob/02029f53b0732f96412db24684a5a6b398dbad53/src/core/src/main/kotlin/org/apache/jmeter/threads/MultitaskThreadGroup.kt#L74
И оно даже работает
Вот API для «отмены»: https://github.com/apache/jmeter/blob/02029f53b0732f96412db24684a5a6b398dbad53/src/core/src/main/kotlin/org/apache/jmeter/threads/MultitaskThreadGroup.kt#L74
И оно даже работает
AN
Вот это правильно или нет?
Вполне. Можно даже сам AppState сделать скоупом
RI
Вполне. Можно даже сам AppState сделать скоупом
И получается все несвязанные скоупы, вдруг стали одним целым?
AN
Что именно отменить нельзя снаружи?
Вот API для «отмены»: https://github.com/apache/jmeter/blob/02029f53b0732f96412db24684a5a6b398dbad53/src/core/src/main/kotlin/org/apache/jmeter/threads/MultitaskThreadGroup.kt#L74
И оно даже работает
Вот API для «отмены»: https://github.com/apache/jmeter/blob/02029f53b0732f96412db24684a5a6b398dbad53/src/core/src/main/kotlin/org/apache/jmeter/threads/MultitaskThreadGroup.kt#L74
И оно даже работает
скоуп нельзя уронить.
AN
И получается все несвязанные скоупы, вдруг стали одним целым?
Это не догма. Я просто транслирую чего у Елизарова вычитал. Насколько я понял, смысл в том, чобы не делать изолированных скоупов без очень острой необходимости
RI
Это не догма. Я просто транслирую чего у Елизарова вычитал. Насколько я понял, смысл в том, чобы не делать изолированных скоупов без очень острой необходимости
Ну в такой схеме два независимых load станут вдруг зависимыми, я не думаю что это тут подразумевалось
AN
Если надо - прокаладываться супервайзерами,
AN
У двух независимых лоадов должен быть общий предок. Это вполне оправдано
RI
У двух независимых лоадов должен быть общий предок. Это вполне оправдано
Нет, это могут быть два независимых запроса, экрана, виджета и т.д.
AN
Нет, это могут быть два независимых запроса, экрана, виджета и т.д.
Ну вот я где-то у Елизарова как раз читал, что делать виджеты и экраны скоупами - не совсем хорошо. Хотя я сам так до недавнего времени делал.
RI
Ну т.е. у тебя есть два запроса на сервере, которые ессно назависимые, ты предлагаешь их пихать под один общий скоуп получается?
SM
fun CoroutineScope.serviceCallЕсть функция с такой сигнатурой (сигнатуру менять нельзя):
Задача: заиметь возможность вызывать suspend функции внутри этого метода.
Поэтому и написали билдер, что выше скинул. Теперь вот так
Если serviceC
fun method(): ServiceCall<Requst, Response>
Задача: заиметь возможность вызывать suspend функции внутри этого метода.
Поэтому и написали билдер, что выше скинул. Теперь вот так
fun method(): ServiceCall<Requst, Response> = serviceCall {
// this I can call suspend method
}Если serviceC
all будет как CoroutineScope.serviceCall, то как мне его вызывать, если класс, который содержит method совсем не CoroutineScope 🙁AN
Ну т.е. у тебя есть два запроса на сервере, которые ессно назависимые, ты предлагаешь их пихать под один общий скоуп получается?
Ну если там суперивизоры проложены почему нет?