EJOE strictly differentiates between two kinds of threads:
ejserver.setMaxReadProcessors( int maxProcessors )
ejserver.setMaxWriteProcessors( int maxProcessors )
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:
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:
Use the following line of code to enable compression in the client:
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:
To enable non-blocking io use the following line of code: