Configuration

Configuration files are provided with queue microservices. If consists of two files:

configuration.yml

This is a standard configuration file for native microservices, where some of the parameters have been adjusted to characteristic of their functions in the environment (queuing) and should be always considered in the process of system design:

  • amount of memory (HEAP)
  • number of threads
SERVERS:
  JLRMC: #JLupin Remote Method Calls Fast Protocol:
    readTimeout: 480000
    isWaitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 256
    receiveBufferSize: 256
    isReuseAddress: false
    threadPoolSize: 8
    isLogPeriodicOnDebug: true
    isDestroyThreadOnTimeout: false
    threadExecutingTimeOut: 240000
    isStartOnMainServerInitialize: true
  TRANSMISSION:
    readTimeout: 480000
    isWaitForFinishExecuteAllRequests: false
    waitToShutdownThreadsOnStop: 60000
    backlog: 0
    receiveBufferSize: 0
    isReuseAddress: false
    threadPoolSize: 2
    isLogPeriodicOnDebug: true
    isDestroyThreadOnTimeout: false
    threadExecutingTimeOut: 3600000
    isStartOnMainServerInitialize: true
  QUEUE:
     readTimeout: 480000
     isWaitForFinishExecuteAllRequests: true
     waitToShutdownThreadsOnStop: 60000
     backlog: 256
     receiveBufferSize: 256
     isReuseAddress: false
     threadPoolSize: 8
     isLogPeriodicOnDebug: true
     isDestroyThreadOnTimeout: false
     threadExecutingTimeOut: 240000
     isStartOnMainServerInitialize: true
ENTRY_POINTS:
  QUEUE:
    isStartOnMainServerInitialize: true
    threadAmount: 8
    DELEGATOR_SETTINGS:
      repeatsAmount: 3
      timeToWaitBetweenRepeatProbeInMillis: 1000
    SERVICE_REPOSITORY_SETTINGS:
      isAlive: true
      howOftenCheckingMicroservicesInMillis: 5000
      externalNodePeersStartCheckDelayInMillis: 5000
      SOCKET_PROPERTIES_TO_CONNECT_WITH_PEERS:
        connectionTimeoutInMillis: 1000
        readTimeoutInMillis: 90000
        isKeepAlive: false
        isOOBInline: false
        isTcpNoDelay: false
        isReuseAddress: false
        sendBufferSize: 0
        receiveBufferSize: 0
        soLinger: 0
        trafficClass: 0
    LOAD_BALANCER_SETTINGS:
      ALGORITHM:
        type: priority
      PROPERTIES:
        changeServerIntervalInMillis: 5000
        repeatsAmount: 3
  TRANSMISSION:
     SERIALIZER:
      producer: 'com.jlupin.impl.functional.supplier.serializer.JLupinJAVASerializerSupplierImpl'
     MICROSERVICES_GRANT_ACCESS:
      MICROSERVICES_LIST:
      #- microserviceName: 'sampleMicroservice'
        #serviceName: 'sampleServiceName'
        #methodName: 'sampleMethodName'
      #- microserviceName: 'sampleMicroservice2'
        #serviceName: 'sampleServiceName2'
        #methodName: 'sampleMethodName2'
PROPERTIES:
  platformVersion: '1.6.1.0'
  #jvmOptions1: '-Xms128M -Xmx256M -Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml -agentlib:jdwp=transport=dt_socket,address=12998,server=y,suspend=n'
  jvmOptions1: '-Xms128M -Xmx256M -Dlog4j.configurationFile=${sys:microservice.dir}/log4j2.xml' #jvmOptions_2 - default the same as jvmOptions_1
  #jvmOptions2: '-Xms128M -Xmx256M'
  externalPort: '8000'
  version: '1.0'
  switchDelayTime: 0
  connectionSocketTimeoutInMillis: 1000
  readTimeoutInMillis: 30000
  isKeepAlive: false
  isOOBInline: false
  isTcpNoDelay: false
  isReuseAddress: false
  sendBufferSize: 0
  receiveBufferSize: 0
  soLinger: 0
  trafficClass: 0
  #javaExecutablePath: 'c:\\jvm\\bin\\java.exe'
  #additionalClassPath: 'c:\\temp\\*'
  isStartOnMainServerInitialize: true
  priorityStartOnMainServerInitialize: 4
  waitForProcessInitResponseTimeInMillis: 900000
  waitForProcessStartResponseTimeInMillis: 900000
  waitForProcessDestroyResponseTimeInMillis: 30000
  isAllFilesToJVMAppClassLoader: false
  isArchiveOnStart: false
  startLogMode: INFO
  isInitErrorCauseWithNetworkInformation: true
  isJmxEnabled: true
  jmxOptions: '-Dcom.sun.management.jmxremote.local.only=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false'
  jmxPrimaryPort: -1
  jmxSecondaryPort: -1
  checkAvailableScript: 'function isAvailable(checkResponseTimeInMillis, jrmcActiveThreads, jrmcMaxThreads,
                                              queueActiveThreads, queueMaxThreads, servletActiveThreads, servletMaxThreads,
                                    jvmMaxMemoryInBytes, jvmTotalMemoryInBytes, jvmFreeMemoryInBytes,
                                    jvmProcessCpuLoadInPercentage, userAvailableFlag) {

                          var isAvailableByUser = Boolean(userAvailableFlag);
                          if(checkResponseTimeInMillis > 20000 || !isAvailableByUser) {
                             return false;
                          }
                          return true;
                         }'
APPLICATION:
  applicationContainerProducerClassName: 'com.jlupin.impl.microservice.partofjlupin.asynchronous.jlupin.configuration.JLupinApplicationContainerProducerImpl'
INITIALIZING_LOGGER:
  #directoryPath: '/logs/server'
  #fileName: 'file_name'
  fileExtension: 'log'
  fileSizeInMB: 20
  maxFiles: 10
MEMORY_ERRORS:
  isRestartOnError: true
  howManyTimes: 4
  percentageGrowth: 15
  isHeapDump: true
THREAD_POOLS:
  THREAD_POOL_1:
    size: 0
    waitingTimeForTasksCompletionInMillis: 10000
  THREAD_POOL_2:
    size: 0
    waitingTimeForTasksCompletionInMillis: 10000

queues.yml

This file contains queues definitions and their parameters.

Section 'DELEGATOR_SETTINGS'

It is configuration for delegator which is used by queue microservice for communication with microservices which are processing tasks. The appropriate part of the configuration file:

DELEGATOR_SETTINGS:
  repeatsAmount: 3
  timeToWaitBetweenRepeatProbeInMillis: 1000

Description:

Parameter Description
repeatsAmount The number of attempts made by the delegator to deliver the request to a microservice (during each attempt, the delegator checks the entire environment available to him in order to find an available microservices)
timeToWaitBetweenRepeatProbeInMillis The time period (expressed in milliseconds) at which the queue delegator waits between successive attempts to execute results.

Section 'SERVICE_REPOSITORY_SETTINGS'

The appropriate part of the configuration file:

SERVICE_REPOSITORY_SETTINGS:
  isAlive: true
  howOftenCheckingMicroservicesInMillis: 5000
  externalNodePeersStartCheckDelayInMillis: 5000
  SOCKET_PROPERTIES_TO_CONNECT_WITH_PEERS:
    connectionTimeoutInMillis: 1000
    readTimeoutInMillis: 90000
    isKeepAlive: false
    isOOBInline: false
    isTcpNoDelay: false
    isReuseAddress: false
    sendBufferSize: 0
    receiveBufferSize: 0
    soLinger: 0
    trafficClass: 0

Section 'LOAD_BALANCER_SETTINGS'

The appropriate part of the configuration file:

LOAD_BALANCER_SETTINGS:
  ALGORITHM:
    type: priority
  PROPERTIES:
    changeServerIntervalInMillis: 5000
    repeatsAmount: 3

Section 'QUEUES'

Each entry in this section is a definition of a queues. The name of the entry is the name of a queue that should be used during asynchronous invocations. Each queues has the following set of parameters:

The appropriate part of the configuration file:

QUEUES:
  SAMPLE:
    innerQueuesAmount: 4
    waitTimeBetweenCheckingTaskReadyToStartInMillis: 500
    storageClassName: 'com.jlupin.impl.microservice.partofjlupin.asynchronous.storage.queue.impl.memory.JLupinMemoryQueueStorageImpl'
    #storageClassName: 'com.jlupin.impl.microservice.partofjlupin.asynchronous.storage.queue.impl.disk.JLupinDiskQueueStorageImpl'
    threadAmount: 8
    maxSendProbeAmount: 2
    maxAcceptExceptionAmount: 1
    exceptionStringToRepeat: 'java.lang.Exception'
    garbageThreadAmount: 2
    garbageStartDelayInMillis: 60000
    howLongTaskStatusWillBeInATransientStateInMillis: 5000
    howLongTaskResultShouldBeOnQueueWithoutDownloadingItInMillis: 240000
    howLongTaskInputShouldBeOnQueueWithoutResultItInMillis: 240000
    waitTimeBetweenCheckingTaskByGarbageManagerInMillis: 30000
    delaySendProcessTaskToExecuteInMillis: 0

Description:

Parameter Description
innerQueuesAmount The number of inner queues that a queue consists of.
waitTimeBetweenCheckingTaskReadyToStartInMillis The time in milliseconds, after which the inner queue is switched from writing mode to reading mode.
storageClassName The implementation class of storage, where requestes and results are located (default is in-memory)
threadAmount The number of threads assigned to each inner queues for handling asynchronous requests.
maxSendProbeAmount The number of attempts that a thread processes the request. When maxSendProbeAmount is exceeded, the request is removed from the queue.
maxAcceptExceptionAmount The additional attempts in case of catching exceptionStringToRepeat exception (the whole stack trace is checked with regular expression)
exceptionStringToRepeat The string that identifies exceptions while processing responses on a queue (important if maxAcceptExceptionAmount > 0).
garbageThreadAmount The number of threads assigned to queue garbage collection process (cleaning queues).
howLongTaskStatusWillBeInATransientStateInMillis The maximum amount of time that a request or response in inconsistent state is kept by a queue. After this time a request or resposnse that is still in inconsistent state is discarded by the queue and removed by the garbage collector.
howLongTaskResultShouldBeOnQueueWithoutDownloadingItInMillis The maximum time in milliseconds that results are kept in a queue without downloading them by the clients.
howLongTaskInputShouldBeOnQueueWithoutResultItInMillis The maximum time in milliseconds that requests are kept in a queue without getting results from microservices.
waitTimeBetweenCheckingTaskByGarbageManagerInMillis The time period (expressed in milliseconds) at which the queue garbage collector waits between checking tasks iterations.
delaySendProcessTaskToExecuteInMillis The minimum delay time in milliseconds between a request comes in and the start of its processing.

Why 'isDestroyThreadOnTimeout' is set to 'true'?

Let's assume that platform is under heavy load and occurred read timeout on client's side. Client closed his socket but server still waits on read method of InputStream and stops thread. Then in case of heavy load CPU usage reaches 100% (it's related with code which waits for data from input stream). Unfortunatelly in this situation closing server's socket (it's done by socket's garbage collector) does not free this thread. Only calling stop method on this threads causes thread freeing (thread is reproduces by thread pool, so pool has always constant configured number of threads which are processing requests). This is the only possible solution to "save" queue microservice and CPU (it will go back to normal working state).