Início / coding / Perguntas / 79598962
Accepted
Jürgen Dengel
Asked: 2025-04-30 02:11:43 +0800 CST

ClassNotFoundException ocorrendo aleatoriamente no Wildfly@Openshift com PVC montado

  • 772

Um ambiente de aplicação Java está atualmente em execução em [email protected] sob Java21. A aplicação foi exaustivamente testada e está estável na pilha de testes. Agora, ela será implantada em um cluster Openshift.

Vários contêineres foram construídos consistindo de wildfly-33.0.2.Final-jdk21.tar.

sh-5.1$ cat /etc/system-release
Red Hat Enterprise Linux release 9.5 (Plow)

sh-5.1$ java --version
openjdk 21.0.4 2024-07-16 LTS
OpenJDK Runtime Environment Temurin-21.0.4+7 (build 21.0.4+7-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.4+7 (build 21.0.4+7-LTS, mixed mode, sharing)

sh-5.1$ /opt/jboss/wildfly/bin/jboss-cli.sh --connect --controller=localhost:9990 --command="version”
JBoss Admin Command-line Interface
JBOSS_HOME: /opt/jboss/wildfly
Release: 25.0.2.Final
Product: WildFly 33.0.2.Final
JAVA_HOME: /opt/java/openjdk
java.version: 21.0.4
java.vm.vendor: Eclipse Adoptium
java.vm.version: 21.0.4+7-LTS
os.name: Linux
os.version: 5.14.0-427.49.1.el9_4.x86_64

Os aplicativos são copiados para o contêiner durante a construção do Docker

FROM dxc.com/basys3-base:v1 AS builder
USER jboss
ENV JBOSS_ROOT=/opt/jboss
ENV JBOSS_HOME=/opt/jboss/wildfly
ENV DEPLOY_DIR=$JBOSS_HOME/standalone/deployments/
COPY benutzungsdienst.war $DEPLOY_DIR/benutzungsdienst.war 
RUN touch $DEPLOY_DIR/benutzungsdienst.war.dodeploy
WORKDIR $JBOSS_HOME 
EXPOSE 8080 9990
CMD [“/opt/jboss/wildfly/bin/standalone.sh”, “-b”, “0.0.0.0”, “-bmanagement”, “0.0.0.0”]

e então, consequentemente, no cluster openshift

oc version
Client version: 4.17.10
Kustomize version: v5.0.4-0.20230601165947-6ce0bf390ce3
Kubernetes version: v1.30.7

com tal implantação YAML implantado

apiVersion: apps/v1
kind: Deployment
metadata:
  name: xxx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: basys3film
  template:
    metadata:
      labels:
        app: basys3film
    spec:
      containers:
      - name: basys3film-container
        image: xxx.xxx.xxx.xxx:5000/xxx:v1
        imagePullPolicy: Always
        ports:
          - containerPort: 8080
          - containerPort: 9990
        securityContext:
          runAsUser: 1000650000
          allowPrivilegeEscalation: false
          runAsNonRoot: true
          capabilities:
            drop: [“ALL”]
          seccompProfile:
            type: RuntimeDefault
        env:
        - name: TZ
          value: “Europe/Berlin”
        - name: WILDFLY_LOG_FILE_NAME
          value: “server.film.log”
        volumeMounts:
        - name: wildfly-dat
          mountPath: /opt/jboss/wildfly/standalone/data
        - name: wildfly-tmp
          mountPath: /opt/jboss/wildfly/standalone/tmp
        - name: wildfly-log
          mountPath: /opt/jboss/wildfly/standalone/log
      volumes:
      - name: wildfly-dat
        persistentVolumeClaim:
          claimName: pvc-dat
      - name: wildfly-log
        persistentVolumeClaim:
          claimName: pvc-log
      - name: wildfly-tmp
        persistentVolumeClaim:
          claimName: pvc-tmp

Três reivindicações de volume persistentes são montadas nos contêineres que se parecem com isso

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-tmp
spec:
 storageClassName: crc-csi-hostpath-provisioner
 accessModes:
 - ReadWriteMany
 resources:
  requests:
   storage: “1Gi”

A inicialização do Wildflys é limpa e os aplicativos são implantados sem erros. O problema é que erros podem ocorrer muito esporadicamente durante os casos de teste e, posteriormente, com mais frequência:

Caused by: java.lang.ClassNotFoundException: com.xxx.yyy.benutzung.dao.datatable.DateUtils from [Module “deployment.benutzungsdienst.war” from Service Module Loader]

Caused by: java.lang.ClassNotFoundException: com.xxx.yyyy.benutzung.utils.Utils from [Module “deployment.benutzungsdienst.war” from Service Module Loader]

Caused by: java.lang.ClassNotFoundException: com.xxx.yyyy.zzz.controller.mag.mag0102.MAG010202Bean from [Module \“deployment.film.war\” from Service Module Loader]"}}

Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.ClassNotFoundException: com.xxx.yyyy.zzz.controller.mag.mag0102.MAG010202Bean from [Module \“deployment.basys3film.war\” from Service Module Loader]

Se tal classe Java não puder ser encontrada pelo Wildfly, ela ainda estará presente no sistema de arquivos e poderá ser rastreada com find -name.

Parece-me que essa imagem de erro só aparece depois que eu crio as montagens de PVC. Se eu remover a montagem e implantar novamente, não consigo mais recriar o padrão de erro.

Li que tais erros podem ocorrer ao usar links simbólicos e também tentei a opção Java -Djboss.vfs.forceCanonical=true, mas isso também não ajudou.

Você tem alguma ideia de como evitar esse comportamento?

Muito obrigado e cumprimentos, Juergen

openshift

1 respostas

  1. Best Answer

    O problema pode ser causado pelo armazenamento do repositório de conteúdo do WildFly ( $JBOSS_HOME/standalone/data) em um volume persistente.

    Conforme explicado na documentação do WildFly , quando uma implantação é implantada no WildFly (o que você está fazendo em seu Dockerfilequando você COPY benutzungsdienst.war), os binários reais (e suas classes) são armazenados no repositório de conteúdo.

    Não sei o que seus testes estão fazendo, mas é possível que você acabe com binários do repositório de conteúdo no volume persistente que não correspondem mais às classes implantadas (já que o PV tem precedência sobre o sistema de arquivos do contêiner).

    Tente remover o PV para wildfly-datevitar esses erros aleatórios. Os outros PV para os diretórios log e tmp estão funcionando corretamente.

    • 1

relate perguntas