Hello Charles,
I know servlet containers have an asynchronous mode, however I don't believe the purpose is the same as what Vert.x wants to achieve. With the servlet asynchronous mode, you effectively release one thread but the operation you do asynchronously will likely simply use another thread (from another pool). This only makes sense - in my opinion - when you simply have long-running operations and you don't want them to hold your container (Jetty, Tomcat, etc.) threads, but at the end of the day this only moves the "problem" somewhere else. With the Vert.x application, everything is event-based (to simplify: basically like Node.js or using C's select/(e/k/etc.)poll), meaning you could potentially receive thousands simultaneous requests without needing thousands of threads, as long as your services perform asynchronous I/O operations. This would be the case for my "API gateway" application, or for pretty much any service only deal with asynchronous/reactive libraries, say, a Couchbase client, file writing, etc. Michael -----Original Message----- From: Canning, Charles [mailto:ccann...@stubhub.com] Sent: Friday, October 9, 2015 10:19 PM To: Michael Putters <michael.putt...@binarygenetics.com>; dev@cxf.apache.org Subject: RE: Vert.x support Micheal, I cant answer the CXF portion, but i wanted to clarify one of your points. If you use CXF and a servlet container in async mode, then you can have an event io based solution. We actually have it working in a reactive way. Just a possible solution. Hope this is useful. Chuck From: Michael Putters Sent: 10/9/15, 11:09 AM To: dev@cxf.apache.org Subject: Vert.x support Hello, I'd very interested in having JAX-RS annotations - and a CXF implementation for them - running within Vert.x, for two main reasons: 1. the typical features you get from CXF (duh), with the possibility of doing operations asynchronously re-using the continuation mechanism already present 2. to use Vert.x as a mostly-automated API gateway: a. some of the back-end's micro services would be registered in the gateway (using the JAR that holds the interface with the JAX-RS annotations) b. the implementation of those services would be a simple proxy that forwards the request to the back-end through an asynchronous CXF client, once the typical validation/etc. are performed c. interceptors would make it possible to add features such as the ability to do throttling/etc. based on tokens, for example The main advantage over servlets being the event-based I/O rather than distributing requests over a pool of threads. Now, I'm fairly new to the CXF codebase, but I've used CXF quite a bit in the past (but also Camel, so the whole Message/Exchange part is not entirely foreign to me). Which leads to me think maybe I could try to get this working and submit a pull-request when it gets to a point where it's useable. However, just to make sure my pull-request doesn't get instantly refused, I have some question regarding what I plan to do (mostly: is it OK if I do it this way?). Here's the plan: - turn the cxf-rt-transports-http project and its classes into something more abstract, extracting the servlet-specific parts to a new cxf-rt-transports-http-servlet project; this is mostly the various parts/methods that use ServletConfig, ServletContext, HttpServletRequest, etc. - this cxf-rt-transports-http-servlet project would depend on cxf-rt-transports-http and implement servlet-specific versions of the generic abstract classes and methods present in cxf-rt-transports-http - create a cxf-rt-transport-http-vertx project that does just the same, but using Vert.x classes and mechanisms rather than the servlet equivalent, eg: HttpServletRequest becomes HttpServerRequest - update the cxf-rt-transports-http-* projects so that they depend on cxf-rt-transports-http-servlet rather than cxf-rt-transports-http This would cover a first step that only includes a slice of the server-side elements and nothing regarding the CXF client. Can anyone confirm that this would be the right way to add Vert.x support to CXF? Thanks, Michael
