FWD » Core Development » Runtime Infrastructure

Teodor, feel free to commit any intermediary work on #11275. I intend to also make some tests on another customer for early performance analysis, exactly like you do for your customer.

I will commit the changes soon, I need to fix the web clients real quick.

Committed revision 16459 on task branch 11275a:
- Allow only UDS clients to authenticate on the process account. Additional fixes.
- For INSECURE connections, the process ID sent through protocol is ignored. It should behave exactly the same as before.
- Added support for Web clients.

Teodor, I think the path of the UDS file needs to be calculated automatically by FWD, using some random UUID and placed in the temporary folder. More, these files need to be cleaned (by the FWD server) when the client terminates, otherwise they will never be cleaned up.

Next: is p2j.net.SessionListener.terminate notification still working?

Constantin Asofiei wrote:

Next: is p2j.net.SessionListener.terminate notification still working?

Yes, is still working and I don't see why it might not work after the changes.

Constantin Asofiei wrote:

Teodor, I think the path of the UDS file needs to be calculated automatically by FWD, using some random UUID and placed in the temporary folder. More, these files need to be cleaned (by the FWD server) when the client terminates, otherwise they will never be cleaned up.

Currently, the UDS path is provided by server Bootstrap config. On my setup, I have changed server.sh so it adds this parameter:

uds_params="net:server:uds=/tmp/fwd-${appname}-${instance}.sock" 

# run the FWD server
JAVA_CMD="$prog $dump $perf $hprof $maxheap $srvr $jmx $dtxt $agent $spi $open_api $cpath $cdsparams $entrypoint $mode $batch $cfg $port $uds_params $profile" 

Constantin Asofiei wrote:

More, these files need to be cleaned (by the FWD server) when the client terminates, otherwise they will never be cleaned up.

There are multiple scenarios when you can't guarantee the execution of shut down logic of FWD server, like OOME, server crash, system crash/power outage, etc. This is why I have added the probing mechanism, which makes it behave similar like a TCP port.

Also, I don't quite understand what do you mean by cleaning when the FWD client terminates, as long as the FWD server is still running. These files are per server, like how you are using a TCP port for accepting socket connections.

Teodor Gorghe wrote:

Also, I don't quite understand what do you mean by cleaning when the FWD client terminates, as long as the FWD server is still running. These files are per server, like how you are using a TCP port for accepting socket connections.

Then please explain something: is this single file used by all FWD clients connected to the FWD server?

Yes, the same file is used by all clients and appserver and all data transfer is done in memory.

UDS can simulate Stream (TCP), Datagram (UDP) or RAW.
In case of Stream sockets, connection multiplexing and demultiplexing is done at kernel level and you don't have to worry about this aspect, it is like how you use one TCP port (and handle a TCP Java NIO socket).

Teodor Gorghe wrote:

Yes, the same file is used by all clients and appserver and all data transfer is done in memory.

OK, I thought there are some different files created for each connection. Then, I'd still rather compute this filename automatically and place it in the temp-folder as reported by JVM. And in the bootstrap config, just let a flag to enable UDS.

Constantin Asofiei wrote:

Teodor Gorghe wrote:

Yes, the same file is used by all clients and appserver and all data transfer is done in memory.

OK, I thought there are some different files created for each connection. Then, I'd still rather compute this filename automatically and place it in the temp-folder as reported by JVM. And in the bootstrap config, just let a flag to enable UDS.

The idea is that you need to know this path before running the FWD server. Swing/ChUI clients needs to know this port in order to connect through UDS.

Please also take in consideration the fact that for database UDS, we still use junixsocket.
This was introduced for Java 8 because there is no native support for this version.

Teodor, I did the trivial patch of #11275-6. I did not saw any performance improvement per se, but I want to ensure that:

java -Xmx64m -Djava.awt.headless=true -Djava.library.path=[...] -classpath [...] com.goldencode.p2j.main.ClientDriver net:server:host=localhost net:socket:nio=false net:ssl:trackSeqNo=false net:connection:secure=true net:server:secure_port=3333 net:server:uds=/tmp/fwd-0.sock client:mode:batch=true client:driver:background=true security:provider:name=conscrypt server:spawner:uuid=b4ab6301-1c8b-4970-8826-392e1ba32c4c server:clientConfig:outputToFile=/dev/null

These are the right Java client args. Is there any need to secure_port, secure? This is for an appserver.

java -Xmx512m -Djava.awt.headless=true -Duser.country=NL -Duser.language=nl -Djava.library.path=[...] -classpath [...] com.goldencode.p2j.main.ClientDriver net:server:host=localhost net:socket:nio=false net:ssl:trackSeqNo=false net:connection:secure=true net:server:secure_port=3333 net:server:uds=/tmp/fwd-0.sock server:spawner:uuid=006a61c2-ab5a-4461-a8b7-414b5c51abeb

Same question about host, secure, and secure_port. This is a web client.

com.goldencode.p2j.main.FwdLauncher server.xml net:connection:secure=true net:server:secure_port=3333 net:server:insecure_port=3433 net:server:uds=/tmp/fwd-0.sock

Server has this config; again, is the secure_prot, secure and insecure_port required?

Last but not least, are all clients communicating within the same socket? I guess yes, considering that a single port was used for tcp/ip.

Alexandru Lungu wrote:

Server has this config; again, is the secure_prot, secure and insecure_port required?

net:server:secure_port=3333 net:server:insecure_port=3433 are not required and I think your FWD clients has connected through UDS.

Alexandru Lungu wrote:

Last but not least, are all clients communicating within the same socket? I guess yes, considering that a single port was used for tcp/ip.

Yes, all clients are connected through the same socket, provided at server startup.

I will also considering testing the scenario which you are trying, to see if there is something else.

Also, I have a question. For web clients to connect on UDS, you need to use revision 16459.
I think you are using revision 16458, which web clients are not supported.

Also, I have a question. For web clients to connect on UDS, you need to use revision 16459.

I used 11275a/rev. 16461.

I will also considering testing the scenario which you are trying, to see if there is something else.

I am testing #11184 mostly (the one that triggered my comment in the first place), but also #11242.

I saw you made a comment on #11242 - that is the one that is really intensive in terms on server-client communication - many (>150) with >1MB of data in total.