FWD » Core Development » Runtime Infrastructure

The current design of our appserver support, including how we execute REST requests, is to forward requests to a pool of agent sessions. Each agent requires a FWD client and any platform specific processing will occur in that client JVM (which runs in batch mode).

The idea is to allow these requests to occur directly on the calling thread instead of forwarding the request to the agent. Doing this will greatly reduce the overhead of the current approach and should scale better.

The downside is that we have to consider security more carefully, handle swapping session context on the calling thread and we must limit/eliminate client side usage. Or we can enable the client-side usage to be executed in the server, but again it requires some security considerations to be handled.

I think that the solution should be made generic enough that it can work with non-REST cases as well. I think this means allowing any server-side invocation of 4GL code to be done in place, without a client process associated with the session. This would enable usage for appserver calls.

I presume this may also require a way to quickly/easily establish a security context and start a legacy "session" (initialize the transaction support and so forth).

From email by Constantin:

I'm sorry, but there was a misunderstanding on my part for #4406 - I read that as 'execution without agent's FWD client', to remove the FWD client from the agent (as there is no need for a FWD client if there is nothing to execute on it).

After reading that correctly, things are a little more tricky, as making the REST worker thread to act like an agent is really dependent on truly client-less agent support. I haven't really thought about how to implement it.

Eliminating the client is one step on the path to the complete solution here. It is mostly enabled by #4065, but we would need to change how we startup such client-less agents. That extra work would be in this task.

Later, we could take the next step to implement the "in-place" execution of legacy code from the REST handling thread. It is not clear to me what the savings in performance will be, I'm interested in your opinion here.