[undertow-dev] Question about APR based connector in Undertow

[Andrig T. Miller]

I am hearing that some work is being put into an APR based connector for Undertow. I am wondering why we are doing this? 

Based on my own testing, and testing the performance team has done with AS 7.x/EAP 6.x/Wildfly, I see no performance reason to do it, and it creates more work for getting product out the door, and maintaining product. 

We have found that the APR based connector can exhibit very poor scalability, and consume large amounts of CPU resources when in a network environment that is having problems (TCP resets, dropped and retransmitted packets, etc.). 

In this situation, especially where we see these poor network conditions, the APR connector spends a lot of its time managing the connection data structure. That data structure is a ring (doubly linked list with head and tail pointing at each other, which you already know). That ring is sequentially searched for the socket to remove and it locks all access with a mutex before it does this. This causes both a CPU consumption issue, as it sequentially walks the linked list, and a blocking problem. When we first discovered this, I went into the code to see how easy it would be to change it. I don't think this is a simple fix, and since APR is the underpinning of other things, like Apache HTTPD, not a trivial thing to get accepted by the community either. This spurred us to look at the NIO2 based connector, which at the time was unsupported, and it didn't exhibit any of this poor behavior. That's what spurred the effort to move the NIO2 based connector to be fully supported. 

In the absence of poor network conditions, the APR connector behaves and performs well, but in the presence of poor network conditions its not good. So, with a viable alternative, which Undertow provides out of the box with its XNIO based architecture, there simple seems no good reason to do with for Undertow. 

Thanks. 

-- 

Andrig (Andy) T. Miller 
Global Platform Director, JBoss Middleware 
Red Hat, Inc. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20150615/ec84ae84/attachment.html