title: Vert.x Event loop - How is this asynchronous?
body: <p>I'm playing around with Vert.x and quite new to the servers based on event loop as opposed to the thread/connection model.</p>
  
  <pre><code>public void start(Future&lt;Void&gt; fut) {
      vertx
          .createHttpServer()
          .requestHandler(r -&gt; {
              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&lt;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 -&gt; {
            if (result.succeeded()) {
              fut.complete();
            } else {
              fut.fail(result.cause());
            }
          });
      System.out.println("Server started ..");
    }
  </code></pre>
  
  <ul>
  <li>I'm just trying to simulate a long running request handler to understand how this model works. </li>
  <li>What I've observed is the so called event loop is blocked until my first request completes. Whatever little time it takes, subsequent request is not acted upon until the previous one completes.</li>
  <li>Obviously I'm missing a piece here and that's the question that I have here.</li>
  </ul>
  
  <p>Edited based on the answers so far:</p>
  
  <ol>
  <li>Isn't accepting all requests considered to be asynchronous? If a new
  connection can only be accepted when the previous one is cleared
  off, how is it async? 
  
  <ul>
  <li>Assume a typical request takes anywhere between 100 ms to 1 sec (based on the kind and nature of the request).  So it means, the
  event loop can't accept a new connection until the previous request
  finishes(even if its winds up in a second). And If I as a programmer
  have to think through all these and push such request handlers to a
  worker thread , then how does it differ from a thread/connection
  model? </li>
  <li>I'm just trying to understand how is this model better from a traditional thread/conn server models? Assume there is no I/O op or
  all the I/O op are handled asynchronously? How does it even solve
  c10k problem, when it can't start all concurrent requests parallely and have to wait till the previous one terminates?</li>
  </ul></li>
  <li><p>Even if I decide to push all these operations to a worker thread(pooled), then I'm back to the same problem isn't it? Context switching between threads?
  <strong>Edits and topping this question for a bounty</strong></p>
  
  <ul>
  <li>Do not completely understand how this model is claimed to asynchronous.</li>
  <li>Vert.x has an async JDBC client (Asyncronous is the keyword) which I tried to adapt with RXJava.</li>
  <li>Here is a code sample (Relevant portions)</li>
  </ul>
  
  <p>server.requestStream().toObservable().subscribe(req -> {</p>
  
  <pre><code>        LocalDateTime start = LocalDateTime.now();
          System.out.println("Request for " + req.absoluteURI() +" received - " +start.format(DateTimeFormatter.ISO_DATE_TIME));
          jdbc.getConnectionObservable().subscribe(
                  conn -&gt; {
  
                      // Now chain some statements using flatmap composition
                      Observable&lt;ResultSet&gt; resa = conn.queryObservable("SELECT * FROM CALL_OPTION WHERE UNDERLYING='NIFTY'");
                      // Subscribe to the final result
                      resa.subscribe(resultSet -&gt; {
  
                          req.response().end(resultSet.getRows().toString());
                          System.out.println("Request for " + req.absoluteURI() +" Ended - " +LocalDateTime.now().format(DateTimeFormatter.ISO_DATE_TIME));
                      }, err -&gt; {
                          System.out.println("Database problem");
                          err.printStackTrace();
                      });
                  },
  
                  // Could not connect
                  err -&gt; {
                      err.printStackTrace();
                  }
                  );
  
  });
  server.listen(4568);
  </code></pre>
  
  <ul>
  <li>The select query there takes 3 seconds approx to return the complete table dump.</li>
  <li>When I fire concurrent requests(tried with just 2), I see that the second request completely waits for the first one to complete.</li>
  <li>If the JDBC select is asynchronous, Isn't it a fair expectation to have the framework handle the second connection while it waits for the select query to return anything.?</li>
  </ul></li>
  </ol>