와스킹의 사건현장

개요
 JEUS로그에서 다음과 같은 메시지 발생
[2019.04.07 00:02:06][1] [ms-66] [WEB-3322] Worker (webtob_ms-hth0-7): Reading the request header from Socket[Ip:port, local=47488], sid=2 failed because of java.net.SocketTimeoutException: Read timed out
[2019.04.07 00:02:06][1] [ms-63] [WEB-3322] Worker (webtob_ms-hth0-4): Reading the request header from Socket[ip:port, local=47508], sid=28 failed because of java.net.SocketTimeoutException: Read timed out
[2019.04.07 00:02:06][1] [ms-76] [WEB-3322] Worker (webtob_ms-hth0-17): Reading the request header from Socket[ip:port, local=47530], sid=20 failed because of java.net.SocketTimeoutException: Read timed out

현상 
 DAS에서 MS에 대해 조회시 FAILED라고 뜨는 경우가 발생, USER의 서비스 처리 지연

원인
 WEBTOB에서 JEUS로 연결을 체크하는 부분과 JEUS에서 WEBTOB의 요청을 기다리는 부분에서 상충하여 발생

WEBTOB 설정의  SvrChkTime
*SERVER
ms            SVGNAME = jsvg_ms,            MinProc = 30,  MaxProc = 30, SvrChkTime = 300, Schedule=FA

JEUS 설정의 Read Timeout
DAS WEBADMIN - MS - Engine - WEB Connection - Read Timeout = 120000

여기에 설정된 시간 동안 WebtoB로부터 아무런 메시지가 오지 않는다면 커넥션에 문제가 있다고 간주하고 새로 맺는다.
WebtoB와 JEUS 사이에 방화벽이 있을 경우, WebtoB가 보내는 Ping 메시지 도착 여부를 이 설정으로 체크할 수 있다.

따라서 WEBTOB에서 JEUS로 연결을 체크하는 주기는 300초 이지만, JEUS에서는 120초가 지나면 연결을 끊도록 되어 있었기 때문에 발생한 문제

해결방안

 WEBTOB 설정의 SvrChkTime보다 JEUS 설정의 Read Timeout이 크도록 설정
 JEUS 설정의 Read Timeout을 500초로 지정하여 해결

 

개요
 AP서버에서 WAS의 JDBC Connection이 JDBCConnectionTimeout 발생

현상
 DB서버(2대-RAC구성) 재기동 이후 JDBC Connection 시도 시 JDBCConnectionTimeout 발생


원인
 1) 비정상 JDBC Connection을 확인하여 제거하는 WAS의 JDBC Connection 설정이 없음
 2) DB서버에 대해 RAC 구성이 되어 있지만, 설정의 primary가 크로스로 구성되어 있지 않았음.
    AP1 - DB2 , AP2 - DB2 =====TO-BE======> AP1 - DB1 , AP2 - DB2

 3) 현상 유발원인 예상 시나리오
  1. DB2의 서버 종료
  2. AP1, AP2 모두 DB1로 fail-over
  3. DB2의 서버 기동
  4. DB1의 서버 종료
  5. AP1, AP2 에 DB1로의 비정상 연결이 잔재
   
 
해결방안
 1) WAS에 아래의 설정을 추가하여 비정상 JDBC Connection을 제거 할 수 있도록 함.
  ※Tmax사의 권고 사항으로 RAC구조의 Datasource 설정을 할 시에는 아래의 설정이 필수

                    <check-query>SELECT 1 FROM dual</check-query>
-> 어플리케이션이 JDBC 커넥션 요청을 했을 때(getConnection) 특정 select 쿼리를 보내서 커넥션의 상태를 점검(validation)하는 기능이다.
                    <check-query-period>120000</check-query-period>
-> JDBC 커넥션을 일정 시간마다 체크하여 문제가 있는 커넥션을 닫아준다.
                    <check-query-timeout>15000</check-query-timeout>
-> check-query를 했을 때 DB 상황에 따라서 JDBC 드라이버가 응답을 못 받고 계속 기다릴 수 있다. 그에 대한 timeout
                    <non-validation-interval>5000</non-validation-interval>
-> connection 단위로 check-query를 할 때 마지막으로 커넥션을 사용한 시각과 현재 시각과의 차이가 어떤 시간 간격보다 작으면 체크하지 않는다. 
                    <destroy-policy-on-check-query>AllConnections</destroy-policy-on-check-query>
->JDBC 커넥션 유효성 체크가 실패했을 경우 해당 커넥션 풀에 있는 커넥션들을 어떻게 할지 정책을 결정하는 옵션이다.

해당 설정으로 인해 fail-bak이 실패한 모든 커넥션이 종료되고 새로이 커넥션을 맺으면서 문제가 없어짐.

하지만 Tmax에서는 해당 설정을 통한 fail-back을 보장하지 않으며, fail-back이 필요한 경우 재기동을 권고함

 2) RAC 설정의 primary를 크로스가 되도록 구성
    AP1 - DB1 , AP2 - DB2

개요
 JEUS 기동 시 TM로그 관련된 Exception메시지 기록

현상
 JEUS 기동 시 로그에서 아래와 같은 Exception 발생

Caused by: org.objectweb.howl.log.LogFileOverflowException: /shcsw/logs/jeus/TM/_`hostname`_"container_name"_LOCATION_0_10061_10_121_11_33_61/jeusres_1.log: high mark = 34bd000000; active mark for Logger = 33c2000037
        at org.objectweb.howl.log.LogFileManager.getLogFileForWrite(LogFileManager.java:389)
        at org.objectweb.howl.log.BlockLogBuffer.init(BlockLogBuffer.java:363)
        at org.objectweb.howl.log.LogBufferManager.getFillBuffer(LogBufferManager.java:591)
        at org.objectweb.howl.log.LogBufferManager.put(LogBufferManager.java:685)
        at org.objectweb.howl.log.Logger.put(Logger.java:207)
        at org.objectweb.howl.log.xa.XALogger.putCommit(XALogger.java:420)
        at jeus.transaction.logging.HowlLogManager.registerXaResourceFactory(HowlLogManager.java:282)
        ... 70 more

원인
 LogFileOverflowException이 발생한 로그 파일은 JEUS transaction 로그입니다.
 transcation 로그란? 예상치 못한 문제 상황에 있어서 거래의 무결성을 보장하기 위해 거래정보를 저장하는 로그 입니다.
 LogFileOverflowException은 JEUS transaction 로그파일에 더 이상 용량이 없을 경우 발생합니다. (default로 4K block을 500개 사용하여 2M의 file을 2개 사용)
 일반적으로 대량의 거래가 발생 하였을 경우 해당 현상이 발생할 수 있으며, 거래에 영향을 주지는 않습니다.

해결방안
 1) 컨테이너 중지 후 transaction 로그 삭제 후 기동
  -> LogFileOverflowException 확률이 있음

 2) transaction 로그 파일 size 튜닝
  JEUSMain.xml의 command-option에 추가, 증가 시킨 후 모니터링이 필요.

   -Dhowl.log.MaximumFiles=5
   -Dhowl.log.MaximumBlocksPerFile=1000

 3) TM 로그 disable 방법
  JEUSMain.xml의 command-option에 추가, 증가 시킨 후 모니터링이 필요.

   -Djeus.tm.noLogging=true

개요
 Java Minor Upgrade 후 JEUS 기동 실패

현상
 Java Minor Upgrade (1.6.0.20 -> 1.6.0.37) 후 JEUS 기동 실패

 1)JEUS Log
jeus.server.JeusServerException: failed to start the node security manager
        at jeus.server.JeusServer.start(JeusServer.java:317)
        at jeus.server.JeusServer.main(JeusServer.java:991)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at jeus.server.Bootstrapper.callMainMethod(Bootstrapper.java:718)
        at jeus.server.Bootstrapper.callMain(Bootstrapper.java:790)
        at jeus.server.Bootstrapper.main(Bootstrapper.java:784)
        at jeus.server.JeusBootstrapper.main(JeusBootstrapper.java:8)
Caused by: java.lang.ExceptionInInitializerError
        at javax.crypto.Cipher.getInstance(Cipher.java:429)
        at jeus.security.util.EncryptionUtil.decode(EncryptionUtil.java:458)
        at jeus.security.util.EncryptionUtil.decryptPassword(EncryptionUtil.java:642)
        at jeus.security.resource.Password.<init>(Password.java:72)
        at jeus.security.resource.DefaultPasswordFactory.getCredential(DefaultPasswordFactory.java:130)
        at jeus.security.impl.atnrep.XMLAccountConverter.fromXMLTree(XMLAccountConverter.java:128)
        at jeus.security.util.XMLConverter.unmarshal(XMLConverter.java:34)
        at jeus.security.util.XMLConverter.unmarshal(XMLConverter.java:51)
        at jeus.security.util.XMLConverter.unmarshal(XMLConverter.java:42)
        at jeus.security.impl.atnrep.XMLAccountPersistedDistributedMemoryAuthenticationRepositoryService.refreshRead(XMLAccountPersi
stedDistributedMemoryAuthenticationRepositoryService.java:97)
        at jeus.security.impl.atnrep.XMLAccountPersistedDistributedMemoryAuthenticationRepositoryService.doCreate(XMLAccountPersiste
dDistributedMemoryAuthenticationRepositoryService.java:36)
        at jeus.security.base.Service.create(Service.java:121)
        at jeus.security.base.Service.create(Service.java:107)
        at jeus.security.base.Domain.createAll(Domain.java:263)
        at jeus.security.impl.installer.JeusSecurityDomainInstaller.makeCustomDomains(JeusSecurityDomainInstaller.java:112)
        at jeus.security.impl.installer.JeusSecurityDomainInstaller.installMasterSecurityServer(JeusSecurityDomainInstaller.java:78)
        at jeus.security.impl.installer.JeusSecurityDomainInstaller.doInstallSecurity(JeusSecurityDomainInstaller.java:41)
        at jeus.security.spi.SecurityInstaller.installSecurity(SecurityInstaller.java:191)
        at jeus.server.JeusServer.start(JeusServer.java:311)
        ... 9 more
Caused by: java.lang.SecurityException: Cannot set up certs for trusted CAs
        at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:267)
        ... 28 more
Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
        at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593)
        at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
        at javax.crypto.JceSecurity.access$700(JceSecurity.java:37)
        at javax.crypto.JceSecurity$1.run(JceSecurity.java:258)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:234)
        ... 28 more

원인
 256bit 이상 암호화를 해야하는 경우 JAVA의 local_policy.jar와 US_export_policy.jar를 버전에 맞게 패치해 주어야 한다.
 Minor Upgreade 한 1.6.0.37에는 /opt/java6/jre/lib/security/policy의 limited 디렉토리와 unlimited 디렉토리에 각각 존재하지만,
 1.6.0.20에는 /opt/java6/jre/lib/security에 존재하였다.
 따라서 Upgrade 이 후 /opt/java6/jre/lib/security에 있는 local_policy.jar와 US_export_policy.jar를 참조하게 되면서 발생한 문제로 보인다.
 JEUS의 경우 기동시 JEUS Manager 를 올리기 위하여 ${JEUS_HOME}/config/`hostname`/security/SYSTEM_DOMAIN/account.xml 파일의 계정정보를 참조하게 되는데
 해당 파일에 AES로 암호화된 패스워드가 들어 있기 때문이다.

해결방안
 local_policy.jar와 US_export_policy.jar를 /opt/java6/jre/lib/security로 복사

개요
 Network의 문제로 기인한 Web 서비스 지연 및 불가 상황

현상
 Web 화면 호출이 전혀 되지 않고, 단순 image파일 개별 호출도 되지 않는 현상 발생.
 WebtoB/JEUS 재 기동 후에는 서비스 정상 작동함.

원인
 1) wsadmin을 통한 확인(wsadmin : st -s, si)
    html서비스의 평균 처리시간이 오래 걸렸으며(60초이상), Queueing 또한 발생.
    이 상황으로 인해 단순한 image파일도 호출되지 않았음.
 

 2) WebtoB의 error log 확인 결과
    [27/Mar/2018:08:43:45 +0900] [error] [client -] TIMEOUT is expired while svc is running
   [27/Mar/2018:08:43:49 +0900] [error] [client -] TIMEOUT is expired while svc is running
   위 로그에서 확인되는 사항은 사용자의 요청이 WebtoB의 TIMEOUT(300초)시간을 지났다는 로그임.
   WebtoB의 TIMEOUT은 Client와 WebtoB사이의 데이터 전송 중 TIMOUT시간 (300초) 이상 어떠한 패킷(데이터)도 Client와 WebtoB사이에 전송되지 않았을 경우 적용되는 값임.
    Network Bottleneck이나 기타 요인으로 인해 패킷 전송지연이 발생되었을 것으로 판단됨.

해결방안
 본 상황은 큰 파일을 동시에 많은 사용자가 다운 받음으로 인해 발생된 서비스 지연에 해당한다.
 즉 시스템적인 오류가 아닌 업무적인 특성으로 인해 과부하가 발생한 것으로, Network 전송속도를 개선하는 것이 근본적인 해결방법임.

 

개요
 WAS의 2중화 구성 환경에서 WAS1과 WAS2가 세션을 공유하지 못하는 현상이 발생

현상
 WAS의 2중화 구성 환경에서 이미지 업로드 하는 거래의 Flow를 진행 시 세션 공유가 되지 않음.
 이미지 업로드 거래 Flow
  1. 뷰어를 띄우는 부분 (WAS1 서버로 연결)
  2. 뷰어에서 ActiveX 에디터를 띄우는 부분 (WAS1 서버로 연결)
  3. ActiveX 에서 이미지 저장을 시작하는 부분 (WAS1 서버로 연결)
   3.1 StartUp (WAS2 서버로 연결)
   3.2 Update (WAS1 서버로 연결)
   3.3 Complete (WAS2 서버로 연결)
    ※ 위 3.1~3 부분은 세션상에서 받아온 userid를 파라매터로 처리
 3의 3.1 부터 세션 정보를 잃어버림.

원인
 이미지 업로드 거래를 처리하는 WAS(JEUS6)의 session-timeout 설정이 0으로 설정되었을 경우,
 JEUS6에서 세션서버를 사용 시 세션 정보를 자체적으로 삭제를 해버림.
 따라서 세션 공유가 불가능한 상황.

해결방안
 session-timeout 을 명시적으로 0이외의 시간으로 설정
 session-timeout은 web.xml에서 설정 가능

        <session-config>
            <session-timeout>180</session-timeout>
        </session-config>

 ※JEUS6의 session-timeout 적용 우선 순위
  1. web.xml
  2. $JEUS_CONFIG/servlet/webcommon.xml