All configuration files exist in the 'start/configuration' subdirectory.

All configuration file have JAVA language syntax.
Main configuration file is defined in start.cmd(sh). File is named: ( the name of this file can be changed - but be aware of JAVA language rules!)

To get better understanding of configuration defined by class, please check the below figure:

In order to simplify maven configuration management we recommend to copy the following xml to server home directory as SERVERHOME/pom.xml file.

Content of that pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi=""






The next step is jlupin-all-assembly library import to Maven local repository with the following command (the library is available here: -->jlupin-all-assembly-1.3.0.jar)

Execute maven command:

mvn install:install-file -DgroupId=com.jlupin -DartifactId=jlupin-all-assembly -Dversion=1.3.0 -Dpackaging=jar -Dfile=jlupin-all-assembly-1.3.0.jar

It improves edition of JLupin configuration files in your IDE as presented on the below picture:

Examine the following file:

public class JLupinGlobalMultiProcessConfigurationImpl implements JLupinGlobalMultiProcessConfiguration {

    public JLupinGlobalMultiProcessConfigurationImpl() {

    public void before() {


    public void after() {

    public JLupinGlobalServer[] getJLupinGlobalServers() {

        JLupinDefaultGlobalServerImpl defaultServer = new JLupinDefaultGlobalServerImpl("default");

        JLupinDefaultGlobalServerImpl commandDESServer = new JLupinDefaultGlobalServerImpl("commandDES");

        JLupinDefaultGlobalServerImpl webServiceServer = new JLupinDefaultGlobalServerImpl("soap");

        JLupinDefaultGlobalServerImpl restServer = new JLupinDefaultGlobalServerImpl("restservice");

        JLupinDefaultGlobalServerImpl mThreadCycleListServer = new JLupinDefaultGlobalServerImpl("asynchronous_3");

        return new JLupinGlobalServer[] { defaultServer,commandDESServer,

    public JLupinMultiProcessEntryPoint[]  getJLupinMultiProcessEntryPoints() {

        //                  JLUPIN JAVA REMOTE OBJECT INVOCATION
        JLupinDefaultBinarySynchronousMultiProcessEntryPointImpl multiProcessEP =
                new JLupinDefaultBinarySynchronousMultiProcessEntryPointImpl();

        //                 JLUPIN REMOTE CONSOLE MANAGER
        JLupinDESXMLInStreamOutGlobalCommandEntryPointImpl dESXMLInStreamOutGlobalCommandEP =
                new JLupinDESXMLInStreamOutGlobalCommandEntryPointImpl();

        //                   JLUPIN SOAP XML WEBSERVICE
        JLupinWebserviceSoapXmlMultiProcessEntryPointImpl wsEP =
                new JLupinWebserviceSoapXmlMultiProcessEntryPointImpl();

        //                   JLUPIN HTTP REST WEBSERVICE
        JLupinRestJsonMultiProcessEntryPointImpl restEP =
                new JLupinRestJsonMultiProcessEntryPointImpl();

        JLupinCycleListBinaryAsynchronousEntryPointImpl mThreadAsynchCycleEP = new

        //                   CYCLE BUS DEFINITION
                new JLupinCycleTaskListBusImpl(2000,16,0,2,1000,3));

        //                    CYCLE BUS DEFINITION WITH 5000 MILLISECONDS DELAY
                new JLupinCycleTaskListBusImpl(2000,16,5000,2,1000,3));

        return new JLupinMultiProcessEntryPoint[]{multiProcessEP, dESXMLInStreamOutGlobalCommandEP,
                wsEP, restEP, mThreadAsynchCycleEP};

    public JLupinMultiProcessManager getJLupinMultiProcessManager() {

        JLupinLocalServerProcessConfigurator jLupinFirstSampleApplication = new JLupinLocalServerProcessConfigurator();
        jLupinFirstSampleApplication.setPrimaryJvmOptions("-Xms128M -Xmx256M");
        jLupinFirstSampleApplication.setSecondaryJvmOptions("-Xms128M -Xmx256M");

        JLupinLocalServerProcessConfigurator jLupinSecondSampleApplication = new JLupinLocalServerProcessConfigurator();
        jLupinSecondSampleApplication.setPrimaryJvmOptions("-Xms128M -Xmx256M");
        jLupinSecondSampleApplication.setSecondaryJvmOptions("-Xms128M -Xmx256M");

        JLupinDefaultNewMultiProcessManagerImpl jLupinDefaultMultiProcessManagerImpl =
                new JLupinDefaultNewMultiProcessManagerImpl();



        return jLupinDefaultMultiProcessManagerImpl;

    public JLupinMultiProcessManagerHandler getJLupinMultiProcessManagerHandler() {
        return null;

    public JLupinLogger getJLupinLogger() {
        return JLupinLoggerOverLog4jImpl.getInstance();

    public JLupinSerializer getJLupinSerializer() {
        return JLupinFSTSerializerImpl.getInstance();

The file above implements configuration interface (JLupinGlobalMultiProcessConfiguration). These are the main instructions for the server start engine to create and start defined servers on defined ports and link those servers with proper entry points. They also link entry points with the process manager which is responsible for managing separate JVM processes as JLNS microservices.

Look at the following JLupinGlobalMultiProcessConfiguration interface:

public interface JLupinGlobalMultiProcessConfiguration {

    void before();
    void after();
    JLupinGlobalServer[] getJLupinGlobalServers();
    JLupinMultiProcessEntryPoint[] getJLupinMultiProcessEntryPoints();
    JLupinMultiProcessManager getJLupinMultiProcessManager();
    JLupinMultiProcessManagerHandler getJLupinMultiProcessManagerHandler();
    JLupinLogger getJLupinLogger();
    JLupinSerializer getJLupinSerializer();

Explanations of methods:

public void before();

this method is invoked before the server and microservices start-up

public JLupinLogger getJLupinLogger();

in this method you can define implementation of JLupinLogger interface - details about JLupinLogger ( see Logging chapter ).

Important – in app code usage of JLupin logger is voluntary. You can use login mechanism that is the best for you.

public JLupinSerializer getJLupinSerializer();

in this method you can define implementation of JLupinSerializer interface which is used to send and receive serialized objects between the server and microservices (other JVM processes)

public JLupinMultiProcessManagerHandler getJLupinMultiProcessManagerHandler();

in this method you can implement interface JLupinMultiProcessManagerHandler which is very helpful on start and restart application processes - with that implementation you have a handler on success or error methods after the start and restart of microservices - by default returns null

public JLupinMultiProcessManager getJLupinMultiProcessManager();

This method returns the main engine that starts and manages microsevices. In this method, all microservices managed by Jlupin are defined. Default implementation will be presented later.

public JLupinMultiProcessEntryPoint[] getJLupinMultiProcessEntryPoints();

in this method you define an array of entry points which are implementations of specific data exchange protocols (for example web service or asynchronous executions )

public JLupinGlobalServer[] getJLupinGlobalServers();

in this method you define an array of servers on various ports which are linked (by setEntryPointIndex(int index); method) with proper entry points

The server engine performs the following actions on start-up:
Like the IOC container, JLNS makes singleton objects and sets proper references

1. Invokes method: public void before() - where you can do anything you want before JLNS start-up (ex: send emails, check any resources)

2. Creates JLupinLogger singleton

3. Creates JLupinSerializer singleton

4. Creates JLupinMultiProcessManager singleton which is responsible for managing separate JVM processes (in default implementation).

5. Creates an array of JLupinMultiProcessEntryPoint interface implementations and injects JLupinMultiProcessManager singleton into these implementations( method: public void setJLupinMultiProcessManager( JLupinMultiProcessManager jLupinMultiProcessManager) );

6. Creates an array of JLupinGlobalServer interface implementations and injects proper singleton positions from an array (see point above) of JLupinMultiProcessEntryPoint given by index from method public int getEntryPointIndex(); and invokes public void start() which (in default implementation ) starts the server

Below you can find details on default implementations of particular methods that are delivered together with server implementation.

Let’s start from getJLupinMultiProcessEntryPoints();

Here are instructions for default JLupinMultiProcessManager implementation.
To create default implementation just create an object with no parameter constructor:

JLupinDefaultNewMultiProcessManagerImpl jLupinDefaultMultiProcessManagerImpl = new JLupinDefaultNewMultiProcessManagerImpl();

and then add microservice (new JVM process) by addApplicationConfiguration method.
Look at the single JLupinLocalServerProcessConfigurator object and parameters:

First Create object with no parameter constructor:

JLupinLocalServerProcessConfigurator jLupinSampleApplication = new JLupinLocalServerProcessConfigurator();

and set proper parameter values:


Sets name of local server (as application JVM process) which is either bound by the operating system or by the name 'localhost'. When it is bound by the name, local processes are not accessible from remote machines.


Sets the primary port on which the local server listens - this primarily means that the port will be used on the start process


Sets the secondary port on which the local server listens after executing the appRestart command. When the appRestart command will be executed again the server will be listening on the primary port and again after next appRestart will be listening on the secondary port - this is the loop in which the ports switch after every appRestart command is executed.


Sets the primary port on which the local server will listen and which will service inner JLNS command requests - such as: start,stop,restart and other command requests.


Sets the secondary port on which the local server will listen and which will service inner JLNS command requests - such as: start,stop,restart and other command requests. After executing the appRestart command, the ports will switch on secondary port when the appRestart command will be executed again switch on primary port - this is the loop in which the ports switch after every appRestart command is executed.


Sets the socket connection (!NOT SO_TIMEOUT to read data from InputStream) time-out. To create connection with the already started process, this connection is needed to communicate the main server with microservice and to execute inner JLNS command


It sets time to read data from a given process.


Sets the logging mode for the local process. Available modes are: INFO, DEBUG, ERROR, WARN, STACK.
The selected logging mode is only for the start process not for application logging modes.


Sets time in milliseconds which is needed to start an application on a local process.
In the default implementation this is the time needed to start the Spring IOC container. If the spring IOC container has not started during this time, an error will be thrown and proces will be destroy.
If application needs more time to start then increase this value.


Sets time in milliseconds so that the process will be terminated after x number of milliseconds. This time is taken into consideration during commands for closing operation of a server or a given single microservice. It is not considered during performance of "force" commands – e.g. appStopForce, serverQuitForce. This time is taken into account, if all requests were not executed in time from sending a command for stopping a server of a given microservice until time stops. If all started requests were done before that time, this parameter would not be then taken into consideration. Therefore, server or microservice is stopped earlier.

jLupinSampleApplication.setPrimaryJvmOptions("-Xms512M -Xmx1024M");

Sets the primary JVMOptions (any Java parameters also with a remote debugging port) for a local process (proper microservice). In this case 'primary' means the same as primary port few points above.

jLupinSampleApplication.setSecondaryJvmOptions("-Xms512M -Xmx1024M");

Sets the secondary JVMOptions (any Java parameters also with a remote debugging port) for a local process (proper application). In this case 'secondary' means the same as secondary port as mentioned a few points above.


Sets the name of an microservice's configuration Java file stored in the start/configuration server directory. After defining the required microservice`s start parameter definitions those definitions linked with the microservice name must be added to JLupinMultiProcessManager.


Name of the microservice`s directory (located in $SERVER_HOMEapplication) must be equal to the name of the microservice: SERVERHOMEapplicationsampleApplication

jLupinSampleApplication.setStartProcessCommand ("…");

The above mentioned method sets the whole starting route to the process. This method should be used only if automatic starting mechanisms of JLupin process fail.

jLupinSampleApplication.setJavaBinPath("C:Program FilesJavajdk1.8.0_45binjava.exe ");

The above mentioned method sets the route to the JVM executable file. If this route is not set (it is not from default), JLupin uses route to JVM from JAVA_HOME.


The above mentioned method informs when the server must archive files composing a given microservice. Default flag is set to false.

jLupinSampleApplication.setJLupinMemoryOverFlowBehaviourSettings(JLupinMemoryOverFlowBehaviourSettings jLupinMemoryOverFlowBehaviourSettings)

The above mentioned method will set parameters of automatic application restart if errors concerning memory flow for JVM (StackOverFlow oraz Java Heap Space) occur. If the above mentioned errors occur, by default JLupin Next Server will 4 times activate a new process with memory allocation 20% larger than Xmx variable in start parameters. After every process activation, Xmx variable will be increased by 20% and this will constitute a basis for next calculation of new memory allocation.

To manually change the above mentioned parameters, the object should be set as shown below (5 times process restart with memory allocation 30% larger than the previous one – two first parameters of class constructor JLupinMemoryOverFlowBehaviourSettings respectively), initial memory allocation is 256 mega-bytes:

JLupinMemoryOverFlowBehaviourSettings jLupinMemoryOverFlowBehaviourSettings = new JLupinMemoryOverFlowBehaviourSettings(5, 30);

Let’s discuss other methods of configuration class.
Examine the following methods:

public JLupinLogger getJLupinLogger();

In this method we must define the implementation of the JLupinLogger interface which is the main JLNS logger engine.

Available implementation (for global server):


Implementation above log in path:

$server_directory/log/server/global/start - for start process
$server_directory/log/server/global/run   - for running process

The foregoing implementation is based on the log4j library available in the server library. You can define your log paths using standard log4j utilities (properties, xml files, log4j api, etc.)


Does nothing - it can be used, for example, during an application performance test, when delays associated with logging process are unwanted.

Now lets see at method:

public JLupinSerializer getJLupinSerializer();

In this method we must define implementation of the JLupinSerializer interface which is the main JLNS object serialization engine (JLNS serialize and deserialize objects between the delegator or balancer and the global and local server - and between those layers serializers must serialize and deserialize objects in the same way - so use the same serializer implementation on every part on JLNS). Available implementation:


The above serializer is configured by default in Jlupin distribution. It is based on Fast Serialization mechanisms -

See the following method:

public JLupinMultiProcessEntryPoint[] getJLupinMultiProcessEntryPoints();

At this point we must return array of JLupinMultiProcessEntryPoint interfaces. JLNS provides a few implementations of this interface which supports proper communication protocols. It is a so called entry point layer.

Now we will iterate and describe every implementation.


JLupinDefaultBinarySynchronousMultiProcessEntryPointImpl is responsible for support of JLupin Java Object Remote Invocation protocol. It allows to remotely initiate any method on any class – provided that it is available as a remote service.

It defines two constructors – one without parameters and the other one with boolean logPeriodicOnDebug parameter. What does this parameter mean? It means that if a logger is set to debug (for more information about login modes read a chapter concerning loggers) and a given class logs any information to logs to debug mode periodically/cyclically, a flag must be set to false (it is set to true by default) to prevent collecting logs of repetitive information in files.

!IMPORTANT this flag can be set in the constructor by all classes of entry point layer.

Every entry point allows setting of the below mentioned values:

public void setSilentErrorMessageMode(boolean isSilentErrorMessageMode)

The above method switches on the so called silent stack trace mode that appears during the performance of a given service (remotely shared class). Therefore, it hides stack trace that generates the so called exception handler (for more information about exception handler read a chapter concerning exception handler).

Let’s discuss other entry points.


provides (based on the JLupin DES-XML-Stream cryptographic network protocol) an entry point to manage the JLupin Next Server by remote command console - see 'command console management' chapter.


JLupinWebserviceMultiProcessEntryPointImpl provides a web service protocol to invoke business services as Java Beans - how to do that - see client chapter. It is responsible for support of Web Service SOAP-XML protocol. It allows to remotely initiate any method on any class – provided that it is available as a remote service. It is initiated by SOAP protocol and representation in XML language of input/output objects.

The above entry point allows setting of the below mentioned values:

public void setKeepAliveOverNetProtocolTimeInMillis(int keepAliveOverNetProtocolTimeInMillis)

It sets server socket opening time after finishing the command request and sending a complete output message. This parameter is very helpful, if there are many network instruments between a client and a server (firewall, VPN concentrators). Extended server socket opening time prevents from situations in which a client does not receive the complete message and a server sends FIN or RST flag depending on configuration/situation. (By defaulf, value of this variable is 0). The above variable is taken into account, only if the below value is set to true (it is set to false by default).

public void setCheckKeepAlive(boolean checkKeepAlive)

The above variable set to true means that if a "connection" header is sent in http protocol and its value is set to "keep-alive", a socket will be closed after time determined by a variable described in the previous section.


JLupinRestJsonMultiProcessEntryPointImpl is responsible for support of Web Service http-JSON protocol. It allows to remotely initiate any method on any class – provided that it is available as a remote service. It is initiated by http protocol and representation in JSON language of input/output objects. The above entry point also includes setKeepAliveOverNetProtocolTimeInMillis and setCheckKeepAlive methods. These methods were described in the discussion about JLupinWebserviceMultiProcessEntryPointImp class.


JLupinCycleListBinaryAsynchronousEntryPointImpl is responsible for asynchronous support which means queue support. It allows to remotely initiate any method on any class – provided that it is available as a remote service. It is initiated by JLupin Asynchronous Java Object Remote Invocation protocol and task id is returned as an output. Initiation processing for a given method is made at the background asynchronously.

JLupinCycleListBinaryAsynchronousEntryPointImpl allows defining many queues as shown below:

mThreadAsynchCycleEP.addJLupinCycleTaskListBus("simpleBus",new JLupinCycleTaskListBusImpl(2000,16,0,2,1000,1,false));

mThreadAsynchCycleEP.addJLupinCycleTaskListBus("simpleCycleBusWithDelay",new JLupinCycleTaskListBusImpl(2000,16,5000,2,1000,1,false));

The above example presents configuration of two queues. First queue named "simpleBus" processes data immediately after receiving them. Second queue named "simpleCycleBusWithDelay" starts data processing 5 seconds after receiving them. New queue is added by initiating addJLupinCycleTaskListBus method on an object JLupinCycleListBinaryAsynchronousEntryPointImpl. First parameter of the above mention method is the name of a queue, the second one is an object of queue definition of JlupinCycleTaskListBusImpl.

Meaning of parameters of class constructor JlupinCycleTaskListBusImpl:

  1.    First parameter is time presented in milliseconds of switching between internal queues (number of internal queues is the last parameter)  
  2.    Second parameter is the number of threads regarding one internal queue – therefore number of threads for the whole queue is the last parameter increased by the second parameter – because every internal queue has its own poll of threads, they do not block or saturate  
  3.    Third parameter is a delay in milliseconds, which is a minimal time that must pass for a task to be ordered to a microservice. If time does not pass, task is moved at the end of internal queue. Therefore it is important to adjust number of internal queues to capacity and pool of threads for that internal queue. Of course, one task is taken by one thread from the pool, therefore at least "$number of threads in a pool" of tasks from a queue is collected and only date is checked or tasks is sent to a particular microservice  
  4.    Fourth parameter is the number of trails to send task to application – task returns to a queue only in two cases: connection timeout or if microservice is off  
  5.    Fifth parameter is the number of internal queues  

See the following method:

public JLupinGlobalServer[] getJLupinGlobalServers();

What is the JLupinGlobalServer ?
The JLupinGlobalServer is the network server. It services socket network communication, listens for requests and establishes communication between a client and the server. At this point the server may decide that is TCP or UDP server. The JLNS provides a default implementation of its interface - JLupinDefaultBaseServerImpl.

The JLNS server socket establishes an algorithm by setting the following parameters:

public void setInetAddress(InetAddress inetAddress);

if this variable is set in the first step - JLNS creates a server socket based on three parameters ServerSocket(port, backlog, inetAddress);

public void setSocketAddress(SocketAddress socketAddress);

if this variable is set in the second step - JLNS creates a server socket by the following algorithm:

ServerSocket serverSocket = new ServerSocket();

if(backlog > 0 ) {
   serverSocket.bind(socketAddress, backlog);

If the above variables, InetAddress and SocketAddress, are not set, socket will be established as shown below (variable port must be set by setPort(int port) method)

ServerSocket serverSocket = new ServerSocket(port);

Then, regardless the previous steps in which ServerSocket has been set, the below variables are set (if their value is larger than 0):

public void setSoTimeout(int soTimeout)

see ->

public void setReceiveBufferSize(int receiveBufferSize)

see ->

public void setReuseAddress(boolean reuseAddress)

see - >

public void setPort(int port);

sets the listen server port

public void setBacklog(int backlog);

sets the server backlog

other server parameters:

public void setWaitToShutdownThreadsOnStop(int waitToShutdownThreadsOnStop);

if a user has given the command "serverQuit" and if any threads perform processing for longer than this time, they will be retained after this time

public void setThreadPoolSize(int threadPoolSize);

determines the size of the main thread pool.It should be at least equal to the total pool of threads in all applications

public void setThreadExecutingTimeOut(int threadExecutingTimeOut);

specifies the maximum lifetime of a single thread. If the thread is processing a request for longer than a specified time, the thread will be interrupted

public void setJLupinConnectionStrategyCallableFactory(JLupinConnectionStrategyCallableFactory jLupinConnectionStrategyCallableFactory)

The above method sets strategy factory for request support – JLupin defines 2 factories and each of them defines 2 strategies for request support:

  • by default.

It gives two strategies of request support.

If destroyThreadOnTimeout variable set by the method:

public void setDestroyThreadOnTimeout(boolean destroyThreadOnTimeout)

is set to false (by default), strategy for request support will be


– it accepts all requests coming to a server. If number of requests exceeds the size of defined pool of threads (threadPoolSize), requests will be directed to a queue and depending on availability of threads pool those requests are released form a queue and initiated.

If a given thread exceeds executing time threadExecutingTimeOut, only sockets are switched off and a thread executes its code until it is finished.

If destroyThreadOnTimeout variable is set to true, strategy for request support will be


It works similarly to JLupinAddingConnectionServiceStrategyImpl, but if a thread exceeds executing time threadExecutingTimeOut sockets are switched off and a thread is destroyed.

JLupinAddingConnectionWithThreadTimeControlServiceStrategyImpl strategy should be wisely used, because if a thread exceeds executing time, variable in unset status (global, volatile), locks on databases, lack of data consistency between systems and any other issues may occur in a system.

Another factory submitted by JLupin is


It gives two strategies for request support.

If destroyThreadOnTimeout variable set by

public void setDestroyThreadOnTimeout(boolean destroyThreadOnTimeout)

is set to false (by default), strategy for request support will be


– it accepts all requests coming to a server up to the size of defined pool of threads (threadPoolSize). If number of requests exceeds the size of pool of threads, requests will be rejected by a server. If a given thread exceeds executing time threadExecutingTimeOut, only sockets are switched off and a thread executes its code until it is finished.

If destroyThreadOnTimeout variable is set to true, strategy for request support will be


It works similarly to JLupinClosingConnectionServiceStrategyImpl, but if a thread exceeds executing time threadExecutingTimeOut sockets are switched off and a thread is destroyed.

JLupinClosingConnectionWithThreadTimeControlServiceStrategyImpl strategy should be wisely used, because if a thread exceeds executing time, variable in unset status (global, volatile), locks on databases, lack of data consistency between systems and any other issues may occur in a system.