Просто приходит поток от клиента и пишется в файл
Надо чтобы он записывался в файл асинхнонно
Т.е., чтобы клиент синхронно получал ответ, когда стрим пришел на сервер, а дальше стрим уже неспешно в другом потоке куда-то записывался
Я знаю, что можно это написать через Task.Run(()=> { ... })
А как правильно? Чтобы через асинхронные методы FileStream
Здравствуйте, mDmitriy, Вы писали:
D>Я знаю, что можно это написать через Task.Run(()=> { ... }) D>А как правильно? Чтобы через асинхронные методы FileStream
Почему нет? Только надо протестировать, чтобы стрим не уничтожился после завершения основного метода.
D>>Я знаю, что можно это написать через Task.Run(()=> { ... }) D>>А как правильно? Чтобы через асинхронные методы FileStream AA>Почему нет? Только надо протестировать, чтобы стрим не уничтожился после завершения основного метода.
S>А клиент то что увидит? Он true также получит не раньше, когда копирование закончится.
не совсем понятно, к чему это?
изначальная цель была сделать из синхронного вызова асинхронный: речь идёт о масштабируемости на стороне сервера, при чём здесь клиент?
Здравствуйте, takTak, Вы писали:
S>>А клиент то что увидит? Он true также получит не раньше, когда копирование закончится.
T>не совсем понятно, к чему это? T>изначальная цель была сделать из синхронного вызова асинхронный: речь идёт о масштабируемости на стороне сервера, при чём здесь клиент?
Мне тоже показалось, что ТС хочет отпустить клиента вернув тру и уже самостоятельно обработать стрим. Но он видимо не догадывается о том, стрим он вот так сразу не улетает в космос.
Хотя может быть вопрос просто корявый.
S>>>А клиент то что увидит? Он true также получит не раньше, когда копирование закончится.
T>>не совсем понятно, к чему это? T>>изначальная цель была сделать из синхронного вызова асинхронный: речь идёт о масштабируемости на стороне сервера, при чём здесь клиент? AA>Мне тоже показалось, что ТС хочет отпустить клиента вернув тру и уже самостоятельно обработать стрим. Но он видимо не догадывается о том, стрим он вот так сразу не улетает в космос. AA>Хотя может быть вопрос просто корявый.
1) если так, до достаточно , наверное, просто забыть про await на стороне клиента, если будут какие-то исключения на стороне сервера, о них клиент не узнает
2) ThreadPool.QueueUserWorkItem(async o => await FireAndForget());
3) Task.Factory.StartNew(async () => await FireAndForget()); что аналогично Task.Run, но на стороне сервера такое делать неэффективно
Здравствуйте, takTak, Вы писали:
S>>А клиент то что увидит? Он true также получит не раньше, когда копирование закончится.
T>не совсем понятно, к чему это? T>изначальная цель была сделать из синхронного вызова асинхронный: речь идёт о масштабируемости на стороне сервера, при чём здесь клиент?
На сколько я понял, принимаем поток, возвращаем true и асинхронно его сохраняем. Т.е. клиент узнает (true) о факте
приема, а не о конечном результате. Ну так я понял пожелание ТС. А на счет масштабируемости -- вроде так и так
будет поток на запрос.
Здравствуйте, takTak, Вы писали:
T>3) Task.Factory.StartNew(async () => await FireAndForget()); что аналогично Task.Run, но на стороне сервера такое делать неэффективно
А почему не просто
Task.Factory.StartNew(() => FireAndForget() );, иначе -- стартануть поток, чтобы стартануть поток. Зачем?
T>>3) Task.Factory.StartNew(async () => await FireAndForget()); что аналогично Task.Run, но на стороне сервера такое делать неэффективно
S>А почему не просто S>Task.Factory.StartNew(() => FireAndForget() );, иначе -- стартануть поток, чтобы стартануть поток. Зачем?
я исходил из того, что FireAndForget- асинхронный метод и по привычке добавил async — await, хотя если ждать не нужно и ошибки тоже не интересуют, это излишнее,
кстати, Task.Factory.StartNew — более общий случай, чем Task.Run, но в 99% случаев лучше использовать Task.Run
Здравствуйте, varenikAA, Вы писали:
AA>Мне тоже показалось, что ТС хочет отпустить клиента вернув тру и уже самостоятельно обработать стрим. Но он видимо не догадывается о том, стрим он вот так сразу не улетает в космос. AA>Хотя может быть вопрос просто корявый.
ну вот и подскажите, плиз, раз уж вы в теме:
мне нужно чтобы клиент получал Ок как только весь стрим примет сервер
Здравствуйте, varenikAA, Вы писали:
AA>Еще раз подумав, хочу залать вопрос зачем вам асинх? Если клиент колом встает, то и асинку надо на клиенте лепить. AA>можно и там и там. иначе никак.
грубо говоря — клиент не должен ждать, что поток где-то там запишется на диск с неизвестной скоростью
он должен отправить весь поток и получить ОК
или ошибку, что сервер поток не получил
что там делает дальше с потоком сервер — не его забота
Здравствуйте, mDmitriy, Вы писали:
D>Здравствуйте, varenikAA, Вы писали:
AA>>Еще раз подумав, хочу залать вопрос зачем вам асинх? Если клиент колом встает, то и асинку надо на клиенте лепить. AA>>можно и там и там. иначе никак. D>грубо говоря — клиент не должен ждать, что поток где-то там запишется на диск с неизвестной скоростью D>он должен отправить весь поток и получить ОК D>или ошибку, что сервер поток не получил D>что там делает дальше с потоком сервер — не его забота
Клиент просто должен сделать выполнить вызов сервера асинхронным, оберни
его в _ = Task.Run( () => ApiInstance.ProcessStream(streamObj));
в C# не нужно специально проверять дошел ли стрим до сервера. будет исключение если случится ошибка.
Вот исключение и надо ловить внутри вызова Task.Run( () => try {ApiInstance.ProcessStream(streamObj);catch ...);
Главное чтобы стрим на клиенте жил до конца передачи, то есть случайно не вызвать диспоуз.
Совет как-то идентифицировать сообщения, чтобы проверять без повторной передачи, что стрим уже передан ранее на случай сетевых сбоев.
AA>Клиент просто должен сделать выполнить вызов сервера асинхронным, оберни
не понял — клиенту это зачем?
клиент должен дождаться конца отправки потока, остальное его не интересует
AA>Главное чтобы стрим на клиенте жил до конца передачи, то есть случайно не вызвать диспоуз.
как раз синхронный вызов и ожидание его завершения это и обеспечит
AA>Совет как-то идентифицировать сообщения, чтобы проверять без повторной передачи, что стрим уже передан ранее на случай сетевых сбоев.
это не нужно в конкретном случае, при неудаче достаточно зафиксировать ошибку
меня вообще интересует сервер и только сервер
чтобы он быстрее обрабатывал и отпускал запрос
Здравствуйте, varenikAA, Вы писали: AA>Быстрее чем клиент передаст стрим не получится. AA>Успешная запись стрима на сервере и будет логикой успешного завершения операции.
имеет ли тогда смысл синхронно сохранить стрим на сервере в память (MemoryStream),
вернуть клиенту Ок
а потом неспешно и асинхронно писать из MemoryStream на диск?
D>имеет ли тогда смысл синхронно сохранить стрим на сервере в память (MemoryStream), D>вернуть клиенту Ок D>а потом неспешно и асинхронно писать из MemoryStream на диск?
Зависит от. Если приложение нагруженное, то нет конечно. Т.е. есть два варианта-- буфферизировать, и тогда по факту получения всех данных отпускать клиента, либо -- полученные данные сразу потоком писать на диск, возможно, асинхронно. Буфферизация кажется быстрее, нету работы с диском, но можно как-то и асинхронно сделать и с потоком напрямую.
Здравствуйте, mDmitriy, Вы писали:
D>имеет ли тогда смысл синхронно сохранить стрим на сервере в память (MemoryStream), D>вернуть клиенту Ок D>а потом неспешно и асинхронно писать из MemoryStream на диск?
Клиент получил ок, а на последнем шаге бамп!!! не записался стрим.
Что тогда, в асинхронке без айди сообщения никуда, посмотрите как это реализовано в kafka.