Overview

The upgrade process applies to the major (1.X.0 -> 1.Y.0) and minor (1.X.Y -> 1.X.Z) versions. It requires individual analysis, the result of which is precise conditions and procedure of the upgrade process.


Patching

Overview

A patchset contains bug fixes and related small changes and is designed for particular version of JLupin Platform. Patchsets are differential, which means that all intermediate patchsets should be applied to get the latest version of JLupin Platform.

For example, to get JLP 1.5.0.3 having the release version (1.5.0.0) you have to apply the following patchsets in exact order:

  1. JLPEE150_ps1
  2. JLPEE150_ps2
  3. JLPEE150_ps3

The patchset number relates to release version (in this example: 1.5.0) and is reset after next release (for example: 1.5.1).

Patchsets are provided only for JLupin Platform Enterprise Edition and are available in download section.

NOTICE that also a patch can be provided as a bug resolution, in that case it's provided individually in our support portal, attached to the issue. Each patch provided in that way is also included in the next patchset.

Installation

Common

  1. Get the patchset file (for example: jlupin_platform_ee_patchset_number_1_5_0_2.zip)
  2. Create $JLUPIN_HOME/platform/patches directory if doesn't exist.
  3. Unzip the patchset file in $JLUPIN_HOME/platform/patches
  4. Go to patchset directory (in this example: $JLUPIN_HOME/platform/patches/JLPEE150_ps2)
  5. Shutdown JLupin Platform (node shutdown using control tool)
  6. Start the patchset installation process (on Windows: patch.cmd, on Linux: patch.sh)
  7. Check the logs (in this example: $JLUPIN_HOME/patches/JLPEE1_4_0_patch1/patch.log)
  8. Check if any individual tasks should be performed
  9. Start JLupin Platform and check if it's up and running.
  10. Raise an issue in case of any errors (through support portal), with patch.log and (optionally) any other problems that occurred.

Individual

Patchset 1.5.0.2 (JLPEE150_ps2)

  • $JLUPIN_HOME/platform/start/configuration/main.yml - the default values of some parameters has been changed, we strongly advice to adjust your configuration (especially if you are using defaults) to the following, it has a serious impact on performance resource needed from the infrastructure (search for comments starting with !!! CHANGE):
ZONE:
  name: default
MAIN_SERVER:
  name: NODE_1
  location: DC1
SERVERS:
  JLRMC:
    port: 9090
    readTimeout: 480000
    waitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 256 # !!! CHANGE: 512 -> 256
    receiveBufferSize: 256 # !!! CHANGE: 1024 -> 256
    isReuseAddress: false
    threadPoolSize: 128 # !!! CHANGE: 1024 -> 128
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
  ELASTIC_HTTP:
    port: 8082
    readTimeout: 480000
    waitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 0
    receiveBufferSize: 0
    isReuseAddress: false
    threadPoolSize: 64 # !!! CHANGE: 128 -> 64
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
  QUEUE:
    port: 9095
    readTimeout: 480000
    waitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 256 # !!! CHANGE: 128 -> 256
    receiveBufferSize: 256
    isReuseAddress: false
    threadPoolSize: 128 # !!! CHANGE: 256 -> 128
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
  TRANSMISSION:
    port: 9096
    readTimeout: 480000
    waitForFinishExecuteAllRequests: false
    waitToShutdownThreadsOnStop: 60000
    backlog: 0
    receiveBufferSize: 0
    isReuseAddress: false
    threadPoolSize: 32 # !!! CHANGE: 64 -> 32
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
  INFORMATION:
    port: 9097
    readTimeout: 480000
    waitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 0
    receiveBufferSize: 0
    isReuseAddress: false
    threadPoolSize: 32 # !!! CHANGE: 64 -> 32
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
  INFORMATION_HTTP:
    port: 9098
    readTimeout: 480000
    waitForFinishExecuteAllRequests: true
    waitToShutdownThreadsOnStop: 60000
    backlog: 0
    receiveBufferSize: 0
    isReuseAddress: false
    threadPoolSize: 32 # !!! CHANGE: 64 -> 32
    logPeriodicOnDebug: true
    destroyThreadOnTimeout: false
    [...]
MICROSERVICES_LOAD_BALANCER_SETTINGS:
  singleRequestRepeatsAmount: 3
  howOftenCheckingMicroservicesInMillis: 5000
  externalHealthCheckPeriod: 4000 # !!! CHANGE: 5000 -> 4000
  externalNodePeersStartCheckDelayInMillis: 5000 # !!! CHANGE: 1000 -> 5000
[...]  
  • $JLUPIN_HOME/platform/server-resources/log4j/log4j2.xml - there two improvements that help a lot in troubleshooting if something goes wrong with log4j (search for comments starting with !!! CHANGE).
<?xml version="1.0" encoding="UTF-8"?>

<!-- ===================================================================== -->
<!--                                                                       -->
<!--  Log4j2 Configuration                                                  -->
<!--                                                                       -->
<!-- ===================================================================== -->

<!--
   | For more configuration information and examples see the Apache Log4j2
   | website: https://logging.apache.org/log4j/2.x/index.html
-->

<Configuration status="WARN" dest="errors/log4j_status.log"> <!-- !!! CHANGE: additional attribute -->
    <!-- Extract log directory and file name into variables -->
    <Properties>
        <Property name="logDirectory">../logs/server/main/</Property>
        <Property name="logFileName">main_server_running</Property>
    </Properties>

    <Appenders>
        <!-- RollingFileAppender configured to role every day -->
        <RollingFile name="FILE">
            <FileName>${logDirectory}/${logFileName}.log</FileName>
            <FilePattern>${logDirectory}/${logFileName}.%d{yyyy-MM-dd}.log</FilePattern>

            <!-- Compress log files to gzip -->
            <!-- More configuration https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy -->
            <!-- <FilePattern>${logDirectory}/${logFileName}.%d{yyyy-MM-dd}.log.gz</FilePattern> -->

            <!-- Do not truncate file -->
            <Append>true</Append>

            <!-- The default pattern: Date Priority [Category] (Thread) Message\n -->
            <PatternLayout pattern="%d %-5p [%c] (%t) %m%n" />

            <Policies>
                <!-- Rollover every microservice start - very useful for debugging -->
                <!-- <OnStartupTriggeringPolicy /> -->

                <!-- Rollover at the top of each day -->
                <TimeBasedTriggeringPolicy interval="1" modulate="true" />

                <!-- Rollover if file size is greater than 200 MB -->
                <!-- <SizeBasedTriggeringPolicy size="200 MB"/> -->
            </Policies>
            <CreateOnDemand>true</CreateOnDemand> <!-- !!! CHANGE: additional line -->

            <!-- Keep last 10 log files -->
            <!-- More configuration https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy -->
            <!-- <DefaultRolloverStrategy max="10" /> -->
        </RollingFile>

        <!-- AsyncAppender for high performance -->
        <Async name="ASYNC_FILE">
            <BufferSize>1000</BufferSize>
            <AppenderRef ref="FILE" />
        </Async>
    </Appenders>

    <Loggers>
        <!-- Setup for root logger with AsyncAppender -->
        <Root level="info">
            <AppenderRef ref="ASYNC_FILE" />
        </Root>
    </Loggers>
</Configuration>