Include log4j2.

[enozcan]

Closes #129

[hasancelik]

👍

[enozcan]

Thanks for the review @hasancelik.
Do you have any idea why the builder does not fail on other architectures but s390x? TBH the logs do not make sense to me: https://travis-ci.org/github/hazelcast/hazelcast-docker/jobs/728021165

EDIT 2:

FYI: I have narrowed the issue down to the logger's layout pattern at our default log4j2.properties. The build passes without the layout pattern provided. Let me try some other patterns.

appender.console.layout.pattern=%d [%highlight{${LOG_LEVEL_PATTERN:-%5p}}{FATAL=red, ERROR=red, WARN=yellow, INFO=green, DEBUG=magenta}] [%style{%t{1.}}{cyan}] [%style{%c{1.}}{blue}]: %m%n

EDIT:

I believe passing properties file is the origin of the problem. Container crashes upon creation:

# CLASSPATH=/opt/hazelcast/*:/opt/hazelcast/lib/*
# starting now....
########################################
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x000003ffae71524e (sent by kill), pid=1, tid=7
#
# JRE version: OpenJDK Runtime Environment (11.0.5+10) (build 11.0.5+10-alpine-r0)
# Java VM: OpenJDK 64-Bit Server VM (11.0.5+10-alpine-r0, mixed mode, tiered, compressed oops, parallel gc, linux-s390x)
# Problematic frame:
# V  [libjvm.so+0x495252]  Copy::conjoint_memory_atomic(void const*, void*, unsigned long)+0x27a
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /opt/hazelcast/core.1)
#
# An error report file with more information is saved as:
# /opt/hazelcast/hs_err_pid1.log
#
# If you would like to submit a bug report, please visit:
#   https://bugs.alpinelinux.org/projects/alpine/issues
#

and removing -Dlog4j.configurationFile=${HZ_HOME}/log4j2.properties jvm opt prevents container from crashing:

# CLASSPATH=/opt/hazelcast/*:/opt/hazelcast/lib/*
# starting now....
########################################
ERROR StatusLogger No log4j2 configuration file found. Using default configuration: logging only errors to the console.

[leszko]

Goog job Enes! I really like the new logs!

Added 2 comments.

[enozcan]

s390x arch forms a super weird behavior for logging pattern. For instance, I couldn't make it work to print logger names with abbreviations (i.e. [c.h.c.CPSubsystem]). It needs %c{1.} pattern that causes the container to crash on s390x with SIGFPE. Moreover, where [DEBUG][main] is fine, having a space between them [DEBUG] [main] causes it to crash again. I haven't seen any reported issue similar to this but come up with these by trial and error. 🤯

So I have 2 suggestions:

• Having a common pattern for all archs compatible with s390x.

  • pros: no extra arch dependent work is needed
  • cons: logs will lose abbreviation format for logger names. (i.e.[c.h.c.CPSubsystem] becomes [com.hazelcast.cp.CPSubsystem] vice versa).

• Changing format via env vars (as we do for logging level) when s390x is detected.

  • pros: other architectures will not be affected by this.
  • cons: some ugly works needed in start.sh

@leszko Do you have any further suggestions? WDYT?

[leszko]

s390x arch forms a super weird behavior for logging pattern. For instance, I couldn't make it work to print logger names with abbreviations (i.e. [c.h.c.CPSubsystem]). It needs %c{1.} pattern that causes the container to crash on s390x with SIGFPE. Moreover, where [DEBUG][main] is fine, having a space between them [DEBUG] [main] causes it to crash again. I haven't seen any reported issue similar to this but come up with these by trial and error. 🤯

So I have 2 suggestions:

• Having a common pattern for all archs compatible with s390x.

  • pros: no extra arch dependent work is needed
  • cons: logs will lose abbreviation format for logger names. (i.e.[c.h.c.CPSubsystem] becomes [com.hazelcast.cp.CPSubsystem] vice versa).

• Changing format via env vars (as we do for logging level) when s390x is detected.

  • pros: other architectures will not be affected by this.
  • cons: some ugly works needed in start.sh

@leszko Do you have any further suggestions? WDYT?

That's all very weird. I'd go with the second option. Because we don't know of anyone even using Hazelcast on s390x, so I'd not adjust anything for that architecture. If it's possible to detect it and use different logging for s390x docker image, then I'd go for that. However, I'm not sure what this ugly works is. Do you already know how this ugly IF will look like?

[enozcan]

Not exactly but something like:

BASE="%d [%highlight{${LOG_LEVEL_PATTERN:-%5p}}{FATAL=red, ERROR=red, WARN=yellow, INFO=green, DEBUG=magenta}]"
ARCH=`arch`

if [[ "$ARCH" == "s390x" ]]; then
  export LOGGING_FORMAT="$BASE [%style{%t{1.}}{cyan}] [%style{%c{1.}}{blue}]: %m%n"
else
  export LOGGING_FORMAT="$BASE[%style{%t{1.}}{cyan}] [%style{%-10c}{blue}]: %m%n"
fi

[leszko]

Not exactly but something like:

BASE="%d [%highlight{${LOG_LEVEL_PATTERN:-%5p}}{FATAL=red, ERROR=red, WARN=yellow, INFO=green, DEBUG=magenta}]"
ARCH=`arch`

if [[ "$ARCH" == "s390x" ]]; then
  export LOGGING_FORMAT="$BASE [%style{%t{1.}}{cyan}] [%style{%c{1.}}{blue}]: %m%n"
else
  export LOGGING_FORMAT="$BASE[%style{%t{1.}}{cyan}] [%style{%-10c}{blue}]: %m%n"
fi

I think this is ok.

[enozcan]

@leszko The build is now passing. PTAL.

[leszko]

@leszko The build is now passing. PTAL.

Looks good from my end 👍

[hasancelik]

👍