Я играю с Vert.x и совершенно новичок в серверах на основе цикла событий, в отличие от модели потока/подключения.
public void start(Future<Void> fut) {
vertx
.createHttpServer()
.requestHandler(r -> {
LocalDateTime start = LocalDateTime.now();
System.out.println("Request received - "+start.format(DateTimeFormatter.ISO_DATE_TIME));
final MyModel model = new MyModel();
try {
for(int i=0;i<10000000;i++){
//some simple operation
}
model.data = start.format(DateTimeFormatter.ISO_DATE_TIME) +" - "+LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME);
} catch (Exception e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
r.response().end(
new Gson().toJson(model)
);
})
.listen(4568, result -> {
if (result.succeeded()) {
fut.complete();
} else {
fut.fail(result.cause());
}
});
System.out.println("Server started ..");
}
- Я просто пытаюсь смоделировать длинный обработчик запросов, чтобы понять, как работает эта модель.
- То, что я наблюдал, так называемый цикл событий блокируется до тех пор, пока мой первый запрос не завершится. Какое бы небольшое время он ни потребовал, последующий запрос не действует до тех пор, пока предыдущий не завершится.
- Очевидно, что мне не хватает части здесь и того вопроса, который у меня есть здесь.
Отредактировано на основе ответов:
- Не принимает все запросы, которые считаются асинхронными? Если новый
соединение может быть принято только при удалении предыдущего
как это происходит?
- Предположим, что типичный запрос занимает от 100 мс до 1 с (в зависимости от характера и характера запроса). Таким образом, это означает, что цикл события не может принять новое соединение до предыдущего запроса заканчивается (даже если он затягивается в секунду). И если я как программист должны продумать все это и направить таких обработчиков запросов на рабочий поток, то как он отличается от потока/соединения модель?
- Я просто пытаюсь понять, как эта модель лучше от традиционных моделей потоков/коннекторов? Предположим, что нет операций ввода-вывода или все операции ввода/вывода обрабатываются асинхронно? Как это решить? c10k, когда он не может одновременно запускать все параллельные запросы и ждать, пока предыдущий не завершится?
-
Даже если я решит нажать все эти операции на рабочий поток (объединенный), я вернусь к той же проблеме, не так ли? Переключение контекста между потоками? Редактирование и использование этого вопроса для награды
- Не совсем понимаю, как эта модель претендует на асинхронность.
- У Vert.x есть async JDBC-клиент (Asyncronous - это ключевое слово), которое я пытался адаптировать с помощью RXJava.
- Вот пример кода (соответствующие части)
server.requestStream(). toObservable(). subscribe (req → {
LocalDateTime start = LocalDateTime.now(); System.out.println("Request for " + req.absoluteURI() +" received - " +start.format(DateTimeFormatter.ISO_DATE_TIME)); jdbc.getConnectionObservable().subscribe( conn -> { // Now chain some statements using flatmap composition Observable<ResultSet> resa = conn.queryObservable("SELECT * FROM CALL_OPTION WHERE UNDERLYING='NIFTY'"); // Subscribe to the final result resa.subscribe(resultSet -> { req.response().end(resultSet.getRows().toString()); System.out.println("Request for " + req.absoluteURI() +" Ended - " +LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME)); }, err -> { System.out.println("Database problem"); err.printStackTrace(); }); }, // Could not connect err -> { err.printStackTrace(); } ); }); server.listen(4568);- Запрос выбора занимает около 3 секунд, чтобы вернуть полный дамп таблицы.
- Когда я запускаю одновременные запросы (только с двумя), я вижу, что второй запрос полностью ждет завершения первого.
- Если выбор JDBC является асинхронным, не так ли справедливое ожидание того, что инфраструктура обрабатывает второе соединение, пока он ожидает, что запрос выбора будет возвращать что-либо.
