FWD » Core Development

Please improve the server_install.odt chapter in the p2j_docs/runtime_installation_configuration_and_administration_guide/ project. The chapter is mostly just a list of ideas/notes. You should also change or add anything else that you find would be useful.

I have some questions regarding this task
For system requirements I didn't find anything about network and how it should scale for p2j (except Firewall allowing outbound/inbound TCP connection)
File System Structure:

"GES: Document an example set of the files needed in the server install, where they “normally” reside and the purpose of each one."

This example will contain the information about jar files needed for server, the server key store and trust store files, where they can be found related to p2j build or who should provide them, and where they should be placed, together with directory configuration files , bootstrap configuration files and how to configure them ?(like a full example of installing the server?).

The network scalability discussion has 2 components:

1. How to calculate the number of sockets that will be used at one time by the application server. Generally, there is one socket opened for each user and that socket is kept open for the duration of the user's session. If there are application and/or batch programs that connect to the P2J server, then there is at least one socket open for each of them. Hand coded applications can create more than 1 session with the server, if they do that, there is 1 socket per session. You can get some further details from Constantin.

2. How to calculate the network traffic. This one is difficult because we really have not done much network analysis of real traffic for our environment. I did some work in this area to identify where we could make the protocol more efficient and I implemented the findings from that work. The result was a more performant protocol. I haven't looked at this since then. The network processing is primarily driven (at this time) using our own remote object protocol. Since we split the client from the server (where Progress runs both parts in a single "fat" client process), our design is necessarily different than the Progress approach. It is certainly true that there will be more network traffic with our solution than there was with the original application, unless all the clients are on the same system as the application server. Again, please discuss this with Constantin and put some text in place. It is OK to state that at this time, we have not yet developed any specific equations that can be used to estimate the traffic. But you probably should put in a list of the kinds of application activities (in terms of the 4GL features like I/O, UI, file system management...) that will cause network traffic where there was no such traffic in the original 4GL system. As a result, it will make sense to ensure good performance for the network connection between the clients and the application server.

The file system discussion:

"like a full example of installing the server?"

I was thinking it would be more of a full listing of the installed files for an example server. This could be in a table and there might be a 2nd column that describes the purpose of each file.

On File System:
Where can I find more info about the p2j jars? (p2jadmin.jar , p2jpl.jar, p2jrt.jar ,p2jspi.jar) besides their content classes and how they are build (from the ant script) didn't find other info.

p2jadmin.jar contains the minimum P2J runtime code needed to run the Administration Console, which is implemented as an applet. This jar is dynamically sent down to the browser and it contains all code needed to make the connection to the P2J server and to call all the admin APIs. Of course, it also has the swing based GUI code that implements the UI. All of the real work happens on the server, behind the admin API. The applet is just the user interface to it. This jar is not used by the server (because all the server-side classes are already part of the p2j.jar). But it still needs to be included in the classpath so that the server can find the jar when it needs to send it down to the browser.

p2jpl.jar contains the minimum P2J runtime code that is needed to run user-defined functions (written in Java) inside PostgreSQL. It includes the functions themselves as well as the supporting data types and so forth. This is "registered" with PLJava. There should be details on this in the dev guide.

p2jrt.jar is something that is not used at this time. You can ignore it.

p2jspi.jar is the collation service provider that we use to get H2 to sort the same way that Progress does. There are details in the dev guide. It has to be installed as an extension of the JRE, so it must be placed in a very specific directory that is part of the JRE/JDK install.

Please feel free to discuss this in more detail with Constantin.