Advanced features

  1. adjusting maximum of concurrent read/process/write operations
  2. choosing the mechanism used to control concurrent read/process operations
  3. using compression
  4. choosing between blocking and non-blocking IO

Adjusting maximum of concurrent read/process/write operations

EJOE strictly differentiates between two kinds of threads:

  • combined Read/Process threads
  • Writer threads
The main burden on serverside is handled within the combined read/process threads because they handle data receiving as well as executing your ServerHandler implementation.

Writer threads are used for sending data from the EJOE server to the clients only.

Per default EJOE uses 20 concurrent read/process threads and 10 concurrent writer threads.

If you expect hundreds or thousands of concurrent client connection you HAVE to adjust these settings to get an acceptable server throughput.

It is a recommended rough rule of thumb to use a lesser amount of writer threads than read/process threads.

To adjust the values used for the maximum of these two kinds of threads use the following two methods the EJServer class does provide:

ejserver.setMaxReadProcessors( int maxProcessors )
and 
ejserver.setMaxWriteProcessors( int maxProcessors )

Choosing the mechanism used to control concurrent read/process operations

It's sad (but true) news that the EJOE server can get comatose when dealing with a huge amount of clients or when using a slow server machine. If you encounter such issues changing the used mechanism contolling how concurrent read/process operations will be scheduled and executed within the EJOE server might help.

By default EJOE uses a non-blocking threadpool for scheduling read/process threads. That threadpool will accept unlimited new threads even if the server isn't able to execute all those threads within a moderate period.

EJOE offers a feature called "threaded processor usage" (i know that the name sucks) which can help you to prevent the server from getting comatose. If threaded processor usage is enabled, EJOE does block scheduling of new read/processor threads until the amount of already running read/processor threads will get lower than the limit. Read above how to adjust that limit.

You can enable "threaded processor usage" with the following line of code:

ejserver.enableThreadedProcessorUsage();
Be aware that you have to enable that feature before starting the server.

Using compression

EJOE does support compression of the used datastreams. This can be a helpful feature especially when dealing with large text-based datas eg. big XML documents.

Compression is a so called "selective feature" in EJOE. It means that a client can request compression but it will be used only if support for compression enabled in the EJOE server.

Use the following line of code to enable compression in the server:

ejserver.enableCompression();
Be aware that you have to enable that feature before starting the server.

On clientside you can enable/disable compression for each call or when you think that compression might be useful for the sent data or the expected answer by the server.

Use the following line of code to enable compression in the client:

ejclient.enableCompression(true);

Choosing between blocking and non-blocking IO

As of version 0.3.2 EJOE uses non-blocking IO for connection accept/select operations only, so that invoking of (de)serialize adapters can be done directly using blocking io streams. This should be a significantly improvement because tests have shown that the direct invoking of the (de)serialize adapters:

  1. setting the accepted socket connection to blocking mode
  2. open an InputStream directly on the socket
  3. hand over the InputStream to the (de)serialize adapter
is much faster (especially with large data) than EJOE's previous non-blocking aproach:

  1. receive data the non-blocking way, have to read them into a buffer
  2. create an InputStream on the buffer
  3. hand over the InputStream to the (de)serialize adapter
Sometimes you might want to use non-blocking io anyway, maybe because the server is getting heavy load and you need the the higher latency non-blocking io offers you.

To enable non-blocking io use the following line of code:

ejserver.enableNonBlockingIO();
The good news: The clients will handle the used io mechanism automatically.