Request Handling in CE using the FCA

[former_member189326]

I recently ran into a situation with a customer using SAP NetWeaver CE that went like this: the customer was load testing a custom-developed HTTP application (using servlets as well as other J2EE components). Putting the system under moderate load quickly quickly caused the system to accept no further requests and opening the AS Java Threads monitor in SAP MMC showed that all the HTTP Worker threads were red (below a shot of what I’m talking about, except that this picture shows them as they are green, i.e. normal).

Why does this happen? In this case, it wasn’t surprising since the system hadn’t been configured for the load scenario it

was being subjected to – something was bound to be maxed out on an out-of-the-box configuration of a development system.

The answer lies in the FCAServerThreadCount property. This parameter specifies the number of HTTP worker threads that can accept requests from the ICM.

By default, this is set to 5 threads for development configurations (which is where my customer's scenario was maxing out, 5 simultaneous clients). Increasing this value and restarting results in more HTTP Worker entries in the AS Java Threads monitor.

My colleague Iliyan introduced the subject in his earlier blog on Robust Java with SAP NetWeaver CE 7.1. Let's go into a little more detail on how requests are handled in CE and some of the motivation behind the Fast Channel Architecture (FCA). This diagram shows request handling and illustrates the role the FCA plays.

Here's what happens for HTTP requests, briefly:

1. HTTP worker threads wait for requests to come into the HTTP Request Queue. A free thread processes a request when it comes in. In our case above, we had no free threads, so the queue was filling up and no threads were available for processing.
2. The HTTP worker thread reads the data from the FCA connection.
3. The connection is forwarded to the appropriate container (EJB, Web, etc).
4. The response is written to the FCA connection.
5. The session table is updated if necessary (session status change).
6. The FCA connection is freed once the request / response cycle has been processed

There are a few things I'd like to point out about this architecture. Firstly, it's queue-based, which means the server is capable of rerouting entries in queues associated with nodes that go down, since each node has its own queue. Secondly, performance of this architecture is very good, since it's based on shared memory and can outperform TCP/IP connections used in the same manner. Finally, it's scalable since the FCA connections are bound to a request/response cycle and not to a TCP/IP connection (which is much longer-living).

Looking back at the ICM Architecture documentation shows that the FCA is based on memory-pipes, and that it plays a role for both ABAP (left hand side) and Java request processing. If you are familiar with the architecture of NetWeaver 04, you will notice that the J2EE dispatcher has been removed from this scenario.