cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Canning, Charles" <>
Subject RE: Vert.x support
Date Fri, 09 Oct 2015 20:46:12 GMT

When you use NIO on the container (whoch the all do for async), you get the same functionality
as the C-based select - this is what NIO is and the async-servlet spec.

For the threads, if you want pure node-like single thread event-loop, you can specify that
it uses a single thread - then you jave to make sure your service code behaves correctly.
This os where using a reactive framework comes into play (which is what vert.x uses based
on their docs).

What you want to achieve is possible using a standard container like tomcat or jetty.

Throw in something like the lmax disrupter or akka actors and you can easily push to 5-15
million messages/events per second as long as your code doesnt block. The reactive component
i mentioned is one such solution.


From: Michael Putters
Sent: 10/9/15, 1:35 PM
Subject: RE: Vert.x support
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.


-----Original Message-----
From: Canning, Charles []
Sent: Friday, October 9, 2015 10:19 PM
To: Michael Putters <
Subject: RE: Vert.x support


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.


From: Michael Putters
Sent: 10/9/15, 11:09 AM
Subject: Vert.x support

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

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,

-          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



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message