재시도

https://docs.oracle.com/cd/E13203_01/tuxedo/tux81/rfcm/rfcmd29.htm#1032112:~:text=When%20a%20server,use%20LIBPATH.

When a server is booted, the variables TUXDIR, TUXCONFIG, TUXOFFSET, and APPDIR, with values specified in the configuration file for that machine, are placed in the environment. The environment variable LD_LIBRARY_PATH is also placed in the environment of all servers. Its value defaults to $APPDIR:$TUXDIR/lib:/lib:/usr/lib:lib where lib is the value of the first LD_LIBRARY_PATH= line appearing in the machine ENVFILE. See UBBCONFIG(5) for a description of the syntax and use of the ENVFILE. Some UNIX systems require different environment variables: for HP-UX systems, use the SHLIB_PATH environment variable; for AIX, use LIBPATH.

AIX 6.1

#       Copyright (c) 2014 Oracle, Inc.

#       All rights reserved
#
#       THIS IS UNPUBLISHED PROPRIETARY
#       SOURCE CODE OF ORACLE, Inc.
#       The copyright notice above does not
#       evidence any actual or intended
#       publication of such source code.
#
TUXDIR=/ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0; export TUXDIR
TUXCONFIG=/ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/tuxconfig; export TUXCONFIG
ULOGPFX=/ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/logs/ULOG; export ULOGPFX

TM_SHUTDOWNTIMEOUT=31; export TM_SHUTDOWNTIMEOUT
#TM_KILL_WITH_BBLOCK=Y; export TM_KILL_WITH_BBLOCK
#TM_SVCTIMEOUT_SIGTERM=YES; export TM_SVCTIMEOUT_SIGTERM
TMULOGUSINGSERVICENAME=YES; export TMULOGUSINGSERVICENAME
TMNOTHREAD=YES; export TMNOTHREAD
#TM_NOALOG=YES; export TM_NOALOG

JAVA_HOME=/usr/java8_64/jre; export JAVA_HOME

JVMLIBS=$JAVA_HOME/lib/ppc64/classic:$JAVA_HOME/lib/ppc64:$JAVA_HOME/bin export JVMLIBS
PATH=$TUXDIR/bin:$JAVA_HOME/bin:$PATH; export PATH
COBCPY=:$TUXDIR/cobinclude; export COBCPY
COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP -C TRUNC=ANSI -C OSEXT=cbl"; export COBOPT
SHLIB_PATH=$TUXDIR/lib:$JVMLIBS:$SHLIB_PATH; export SHLIB_PATH
LIBPATH=$TUXDIR/lib:$JVMLIBS:$LIBPATH; export LIBPATH
LD_LIBRARY_PATH=$TUXDIR/lib:$JVMLIBS:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
WEBJAVADIR=$TUXDIR/udataobj/webgui/java; export WEBJAVADIR
LLE_DEPRECATION_WARN_LEVEL=NONE; export LLE_DEPRECATION_WARN_LEVEL

고객사 테스트를 위해서 패치 버전 RP152를 RP163으로 업데이트하는 테스트를 진행하였다.

패치 파일을 unzip하게 되면 .tar.Z 파일이 나오는데 

zcat 파일이름 | tar zvf -

로 하면 .tar 파일과 .Z 파일을 한번에 해제할 수 있다.

그리고 README를 읽어보면 패치가 install 이라는 쉘 스크립트만 돌리면 되기 때문에 매우 간편하게 진행할 수 있다.

중요할 점은 기동 중인 tuxedo와 tlisten이 있다면 모두 엔진을 꺼주어야한다.

또한 RP152로 패치가 되어있는 상태이므로 uninstall 쉘 스크립트를 실행시켜 패치를 none으로 변경시켜줘야한다.

RP152 디렉토리로 들어가서 쉘스크립트를 실행시킨다. 

# ./uninstall

The uninstallation finished successfully.



버전을 확인해보자.

# tmadmin -v

INFO: Oracle Tuxedo, Version 10.3.0.0, 64-bit, Patch Level (none)

이제 RP163을 설치한다.

# ./install
DIR=/ofm/jwchoi/sw/tp/Opatch rpreleasenote = AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo portreleasenotes= AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo Installing server and client files...
Enter owner for patch files: jwchoi
Enter group for patch files: ofm




The patch installation finished successfully.

# 테스트환경 

AIX IBM 7.2 / oracle Tuxedo 10.3 

oracle Tuxedo는 12c 부터 설치시 Opatch  디렉토리가 자동적으로 생기지만 

아래 버전들은 따로 디렉토리를 만들어 주어야 한다.

+

12c 보다 패치방식 훨씬 간단하다고 생각한다.

12c는 patch file의 경로와 oraInst.loc 파일의 경로를 모두 잡아주어야하는 번거로움이 있어서 그렇달까...

# 패치 순서 

1.  오라클에서 받은 패치 파일을 IBM AIX으로 보내고 압축해제를 해준다.

나는 Opatch 디렉토리를 새로 만들어 이곳에 설치파일을 떨어뜨렸다.

# ls
p20445464_10300_AIX64-5L.zip

# unzip p20445464_10300_AIX64-5L.zip
Archive:  p20445464_10300_AIX64-5L.zip
  inflating: README.txt
 extracting: RP152.tar.Z
  inflating: patchlev
  inflating: releasenotes.txt
  


# ls
README.txt   RP152.tar.Z   p20445464_10300_AIX64-5L.zip  patchlev    releasenotes.txt

압축을 해제했다면 일단 README.txt 파일을 읽어보자. 고맙게도 패치 방법이 있다.

패치는 RP152 이고 실행은 install.sh(UNIX) 또는 exe file(windows)로 할 수 있다~ 라는 내용도 있다.

2. tar.Z 파일을 gzip -d 로 압축 해제 해주고 

# gzip -d RP152.tar.Z

# ls
README.txt                    RP152.tar                     p20445464_10300_AIX64-5L.zip  patchlev                      releasenotes.txt

3, tar 파일을 tar -xvf로 해제 해준다.

# tar -xvf RP152.tar
x .
x ./udataobj
x ./udataobj/binfiles, 3595 bytes, 8 tape blocks
x ./udataobj/cwbinfiles, 146 bytes, 1 tape blocks
x ./udataobj/joltbinfiles, 219 bytes, 1 tape blocks
x ./udataobj/wbinfiles, 1826 bytes, 4 tape blocks
x ./udataobj/RpReleaseNote.txt, 65 bytes, 1 tape blocks
x ./udataobj/Usysfl32, 3085 bytes, 7 tape blocks
x ./udataobj/Usysflds, 3085 bytes, 7 tape blocks
x ./udataobj/jolt
x ./udataobj/jolt/jolt_signed.jar, 127305 bytes, 249 tape blocks
x ./udataobj/jolt/RE.html, 126 bytes, 1 tape blocks
x ./udataobj/jolt/jolt.jar, 116523 bytes, 228 tape blocks
x ./udataobj/jolt/jolt.zip, 216384 bytes, 423 tape blocks
x ./udataobj/jolt/joltadmin.jar, 70468 bytes, 138 tape blocks
x ./udataobj/jolt/jolti18n.jar, 116855 bytes, 229 tape blocks
x ./udataobj/jolt/joltjse.jar, 29343 bytes, 58 tape blocks
x ./udataobj/jolt/joltwls.jar, 14203 bytes, 28 tape blocks
x ./udataobj/mib_views.V, 1912 bytes, 4 tape blocks
x ./udataobj/patchlev, 19286 bytes, 38 tape blocks
x ./udataobj/releasenotes.txt, 8513 bytes, 17 tape blocks
x ./udataobj/security
x ./udataobj/security/bea_ldap_filter.dat, 1225 bytes, 3 tape blocks
x ./udataobj/tmib_views.V, 31239 bytes, 62 tape blocks
x ./udataobj/tpadm, 44587 bytes, 88 tape blocks
x ./udataobj/webgui
x ./udataobj/webgui/java
x ./udataobj/webgui/java/bea
x ./udataobj/webgui/java/bea/tuxadm
x ./udataobj/webgui/java/bea/tuxadm/TuxApplet.jar, 248075 bytes, 485 tape blocks
x ./install, 39803 bytes, 78 tape blocks
x ./uninstall, 25365 bytes, 50 tape blocks
x ./README.txt, 1346 bytes, 3 tape blocks
x ./bin
.
.
.
.

3. ./install 실행하면 

다음과 같은 스크립트가 나온다.

owner와 group을 보려면 id 커맨드로 확인하면 된다.

# ./install
DIR=/ofm/jwchoi/sw/tp/Opatch
rpreleasenote =  AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo
portreleasenotes= AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo
Installing server and client files...
Enter owner for patch files:
Enter group for patch files:


# id
uid=720(jwchoi) gid=700(ofm)

설치가 완료 되었다고 한다.

# ./install
DIR=/ofm/jwchoi/sw/tp/Opatch
rpreleasenote =  AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo
portreleasenotes= AIX 5.3 64-bit Power5-RISC, 64bits Tuxedo
Installing server and client files...
Enter owner for patch files:
jwchoi
Enter group for patch files:
ofm

The patch installation finished successfully.

3. tmadmin -v 로 패치가 적용된 것을 확인한다.

# tmadmin -v
INFO: Oracle Tuxedo, Version 10.3.0.0, 64-bit, Patch Level 152

튜닝을 위해서는 OS / 네트워크 / Tuxedo 환경설정  

3가지가 필요하다.

==

자세한 글은 아래 출처에 있으며 Tuxedo 환경설정만 가져왔다.

==

Tuxedo ubbconfig 환경설정

1) WSH의 개수 설정

  WSH의 역할은 WS 클라이언트와 통신하는 역할을 하며, 하나의 WSH은 멀티 플렉싱 기능을 이용하여 하나 이상의 WS 클라이언트와 통신이 가능하다.

  하나의 WSH가 몇 개의 WS 클라이언트와 통신을 할지는 ubbconfig의 WSL 정의 부분에 CLOPT 부분에 "-x" 옵션으로 지정하는데, 일반적으로 10`50개 사이의 값으로 설정하고, 하나의 WSH가 50개 이상의 클라이언트를 처리해야 하는 경우는 WSH의 수를 늘려야 한다.

2) 서버의 갯수의 설정

  Tuxedo 상의 어플리케이션 서버 프로세스의 수는 가능하면 적은 값이 좋습니다. 많은 수의 어플리케이션 프로세스가 기동되게 되면, OS의 자원이 많이 필요할 뿐만 아니라 Bulletin Board에 대한 Lock 경합이 발생하여 성능저하를 유발할 수 있기 때문이다.

  적정 서버수의 선정은 여러 서버를 운영하면서, tmadmin의 pq 옵션 등을 통해서 각 서버 프로세스 내의 Queue에 pending 되는 메시지가 많아지는 것이 원인이 되어 응답속도가 현저하게 떨어질 경우에 그 개수를 늘려주면 된다.

  Tuxedo 서버의 개수는 각 서버의 MIN과 MAX 값으로 설정할 수 있는데, 일반적으로 MIN과 MAX 값은 피크 타임을 기준으로 설정하는게 일반적이다.

3) SYSTEM_ACCESS

  RESOURCES 섹션에 정의되는 값으로 shared memory 영역에 대한 접근 방법을 정의한다. 크게 PROTECTED와 FASTPATH 두 가지로 구분된다.

① FASTPATH로 설정을 해 놓으면 shared memory 영역을 server가 항상 attach 하면서 사용한다. 시스템의 ACCESS 속도는 빠르지만 사용자 어플리케이션에서 잘못된 메모리 영역에 대한 ACCESS를 하거나 core dump나 kill -9와 같은 비 정상 종료시에는 shared memory 영역을 access 하던 중 종료되면 shared memory 영역이 깨져서 비정상적인 작동을 유발하기 때문에 사용자가 개발한 어플리케이션이 안정적일 경우에만 사용하는 것을 권장한다.

② PROTECTED로 설정을 해놓으면 shared memory 영역을 사용할 때만 attach하게 된다. 사용할 때마다 attach와 detach가 발생하기 때문에 속도는 떨어지지만 사용자 어플리케이션이 불안정하여 자주 shared memory 영역을 침범하였을 경우에는 이를 방지하여 안정적인 시스템 운영을 할 수 있도록 해준다.

4) BLOCK TIMEOUT과 TRANSACTION TIMEOUT

  BLOCKTIME은 Tuxedo 클라이언트가 request 보낸 후에 response를 받을 때 까지 시간의 허용값을 정의한다. 만약 이 BlockTIME 보다 시간이 더 소요되면 클라이언트에 이 내용을 알려서 무기한적으로 response를 기다리는 것을 방지한다.

  BLOCKTIME 값의 설정은 SCANUNIT 값에 영향을 받는데, 이 BLOCKTIME에 대한 검사는 SCANUNIT 주기로 발생하기 때문에, 만약 SANITYSCAN이 10초, BLOCKTIME을 60초로 해놓고 서비스를 호출하면 서비스를 호출하는 시점과 SCANUNIT 간격이 다르므로 60초가 아니라 60초 내지 70초 사이에 timeout이 발생한다. transaction timeout도 이와 마찬가지로 tpbegin에 지정한 시간에 정확히 timeout이 발생하는 것이 아니라 SCANUNIT 만큼의 오차가 있을 수 있다.

5) REPLYQ=Y

  각 Service간의 호출이 있고, 호출하는 쪽 (Caller)가 MSSQ를 사용할 때 REPLYQ를 설정해야 한다. 예를 들어 서비스 A에서 서비스 B를 호출할 때, 서비스 B가 호출이 작업이 끝나면 그 내용을 서비스 A의 서버의 request Q로 return한다. 이때 이 서버가 MSSQ를 사용하고 있다면 여러 서버가 이 MSSQ를 공유하고 있기 때문에, Caller 서버가 아닌 전혀 엉뚱한 서버로 갈 수 가 있다.

  이런 상황을 막기 위해서 caller 쪽에 REPLYQ를 따로 지정해서 이런 현상을 방지 하게 된다.

6) MSSQ 사용의 선택

  MSSQ는 Tuxedo에서 여러 개의 어플리케이션의 request Q를 하나로 통합하여 Q의 사용효율성을 높이고 효과적인 부하분산을 하고자 하는데 그 목적이 있으며, 아래와 같은 상황에 따라서 사용 여부를 선택해야 한다.

① MSSQ를 사용할 수 있는 경우

   -같은 MSSQ를 사용하는 모든 서버의 서비스가 동일해야 한다.

② MSSQ를 사용하면 좋은 경우

   -서버가 2개~12개 사이인 경우

   -메시지의 크기가 비슷한 경우

③ MSSQ를 사용하지 말아야 할경우

   -하나의 MSSQ를 사용하는 서버가 12개를 넘을 경우에는 MSSQ를 분리하는 것이 좋다.

   -메시지가 너무 큰경우

   -각각의 서버의 메시지의 크기가 상이하게 다른경우

8) Multithread Option OFF

  각 Tuxedo의 어플리케이션 서버가 Multi Threading을 사용하도록 구현이 되어 있는 경우에, Tuxedo에서는 이 각 Thread간의 동기화를 위해서 Mutex를 사용하는데, 만약 MultiThreading을 사용하지 않는다하더라도 이 Mutex가 Locking을 위해서 사용이되고, 이로 인한 부하를 유발할 수 있다.

  그래서 사용자 어플리케이션에서 Multi Threading을 사용하지 않는다면, 이 Mutex를 사용하지 않도록 설정하여 성능 향상을 기대할 수 있다.

Unix 환경 변수에서 “TMNOTHREADS=Y”로 설정해 주면 된다.

9) Turn off XA transaction

  Tuxedo에서 NON-XA 프로그래밍을 했을 때도 (TMS를 사용하지 않았음에도) Tuxedo에서는 내부적으로 transaction 처리를 위해서 몇가지 기능을 수행을 한다. 그러나 이 NON-XA에서는 사용자가 어플리케이션에서 직접 transaction 관리를 하기 때문에, 이러한 처리는 불필요하고 이로 인해서 불필요한 부하를 유발할 수 있다.

  그래서 NON-XA로 구성된 도메인의 경우 XA transaction 처리를 Turn OFF 할 경우 성능 향상을 기대할 수 있다.

  XA transaction을 Turn off 하기 위해서는 RESOURCES 부분의 OPTIONS에 NO_XA라는 옵션을 추가하면 된다. NO_XA는 XA transaction을 사용하지 않겠다는 의미이기 때문에 TMS를 사용하면 에러를 발생 시키게 된다.

10) Tuxedo Spincount 설정

  Tuxedo는 운영중의 RUNTIME 정보를 BB (Bulletin Board)에 저장해 놓는다. 이 BB는 각 Tuxedo 프로세스간의 공유 메모리 공간이기 때문에, 한 프로세스가 BB를 액세스 하고 있을 때, 다른 프로세스가 BB를 액세스 할 수 없도록 BB에 대한 LOCK을 걸어서 다른 프로세스의 접근을 제어한다.

  이때 BB Lock을 잡고 있는 이외의 프로세스 중에 BB Lock을 잡기 위해 대기 하는 프로세스는 BB Lock이 release 되었는지를 체크하게 되는데, 이 대기 프로세스는 BB Lock이 release 되었는지를 몇 번의 Loop를 돌아서 체크를 한 후에, 만약 Loop내에 Lock이 release가 되지 않으면, 자신의 프로세스 상태를 sleep 상태로 전환한다.

  BB Lock을 잡고 있는 프로세스가 해당 작업을 다 끝내고 Lock을 release할 때, BB Lock을 잡기 위해서 대기중인 프로세스 중에서 sleep 상태인 프로세스가 있으면 notify를 하여 BB Lock이 release가 되었음을 알리고, 다음 프로세스가 BB Lock을 잡고 BB에서 작업을 할 수 있도록 한다.

  위에서 설명한 바와 같이, BB Lock을 얻기 위해서 대기중인 프로세스는 일정주기 만큼 체크를 하다가 그 주기동안 BB Lock을 얻지 못하면 sleep 상태로 빠지는데, 이 sleep과 notify는 OS Level에서 많은 비용을 필요로 하는 작업이다.

  그래서 대기 프로세스가 sleep상태로 가기 전에 BB Lock이 release 되는 것을 체크하는 기간을 길게 줘서 sleep 비율을 줄이는 것이 성능에 유리한데, 이 설정이 MACHINES 섹션의 SPINCOUNT라는 값이다.

  CPU가 1개인 machine에서는 이 SPINCOUNT를 1로 설정하는 것이 성능에 유리하고, 2개 이상의 CPU를 가진 machine에서는 이 SPINCOUNT를 5000~100,000 사이의 값으로 설정하는데, 이 값의 지정은 SPINCOUNT값을 변경 시켜 가면서, Application 성능 테스트를 하고 그 중에서 최적값을 찾아서 선택한다.

예) SPINCOUNT=5000

11) OPENINFO절의 SesWt 설정

  Oracle에 XA를 사용하고 있는 환경에서 application server의 수행 시간 등이 길어져 Transaction time out이 발생한 경우 TMS에 큐잉이 되는 경우에 Oracle의 SesWt를 조정할 필요가 있다.

  SesWt는 다른 session에 의해 사용 중인 transaction branch를 얼마나 기다릴 것인가를 초단위로 지정하기 위한 parameter로 default 값은 60(초)이다.

  application server가 XA를 사용하는 경우 서비스가 시작되면 xa_start()가 수행되고 서비스가 끝나면 xa_end()가 수행된다. 수행 시간이 길어져 Transaction time out이 발생하게 되면 TMS에 의해 xa_rollback() 요청이 있게 되는데, 이때 Oracle은 xa_end()가 수행되지 않은 session에 대해 SesWt에 지정된 시간만큼 xa_rollback()을 wait한다.

  결과적으로 Oracle로부터 xa_rollback()의 return을 받지 못하므로 TMS에 큐잉이 발생한다.

  SesWt은 Oracle에서 xa_open string의 한 field로 제공하는 것으로, ubbconfig의 OPENINFO에서 설정할 수 있다.

12) CLOPT = "-r" 옵션을 이용한 운영 정보의 수집과 분석

이 옵션을 사용하면 각 서버의 서비스 사용 내역이 stderr에 logging된다. 이 내용을 txrpt를 이용해서 분석하면 튜닝에 필요한 정보를 리포트 형식으로 받을 수 있으며, 이 내용을 이용해서 서버의 개수 등과 같은 Tuxedo 운영상 필요한 튜닝을 할 수 있다.

13) 서비스간의 호출

① 같은 Machine내에서는(최소한 같은 GROUP내에서는) Service에서 Service를 호출하는 형태의 Transaction이 발생하지 않도록 Service를 구성하여야 한다. 이를 위해서는 단위 업무 기능을 함수로 구축하고 Service에서 이들 함수를 차례로 호출하도록 한다. 그래서 Service를 마치함수 호출하듯이 사용하는 형태의 프로그램이 나오지 않도록 한다.

② 만일 다른 Machine의 Service를 호출할 필요가 있을 때에는 tpcall()같은 Blocking Call 대신에 tpforward()같은 Non-Blocking Call을 사용하여 Server Process가 필요 없이 대기하고 있는 상황을 방지한다. 다른 Service를 호출하는 Service가 호출의 결과를 필요로 하는 곳에서는 Service를 분할하는 것이 좋다.

Non-Blocking Call을 사용하는 것은 CPU에서 Pipeline을 사용하는 것과 같은 형태의 기법이다. 그래서 Non-Blocking Call을 사용할 때에도 이러한 Pipeline의 효과를 극대화할 수 있는 방법을 사용하여야 할 것이다.

③ Blocking Call이 발생하는 것을 줄이기 위해 Global Transaction의 기동(tpbegin())과 완료(tpcommit())는 반드시 Client에서 호출하도록 한다. Service에서 Global Transaction을 기동하고 완료하는 경우에는완료의 성공메시지가 Service로 반환된후에 Service가 Client로 메시지를 반환하기 전에 장애가 발생하면 Global Transaction은 정상적으로 완료되었지만 Client에서는 이 사실을 알 수 없는 상황이 발생할 수 있다. 그러므로 원칙적으로 Global Transaction의 기동과 완료를 Client에서하여야 한다.

14) 동일 서버 내의 서비스 요청 시

  동일 Application 서버 내의 서비스에 대해 tpcall시에 TPENOENT 에러가 발생한다.

  tpcall시에 TPENOENT에러는 해당 서비스가 없을 때(해당 서버가 shutdown 되었거나, tpcall시 서비스명 기술을 잘못 하였을 때 등) 발생하게 된다.

  그런데 엄연히 해당 서비스가 구동되어 있는 상태인데도 불구하고, 동일 Application 서버 프로세스 내의 한 서비스에서 다른 서비스를 tpcall하는 경우 TPENOENT 에러를 발생시키게 되는데, 그 이유는 deadlock을 방지하기 위함이다.

  Tuxedo Application은 default로 multithread를 사용하지 않도록 생성이 된다(7.1 이후부터 multithread 사용 가능함).

  따라서 위와 같은 요청을 받아주게 되면, tpcall한 서비스는 tpcall 작업에 대한 응답을 받을 때까지 blocking이 될 것이고, 서비스 요청은 해당 서버 프로세스가 이미 tpcall 작업에 걸려있기 때문에 해당 요청을 받아줄 수 없는 상태가 되어 버린다(결국 deadlock을 유발한다.).

  동일 서버이더라도 해당 서버가 여러 개 기동이 되어 있는 경우에는 이와 같은 작업이 가능하다. 이때 tpcall을 하는 프로세스와 tpcall을 받아 서비스를 해주는 프로세스는 서로 다른 프로세스가 된다. 이런 경우 되도록이면 서비스를 다른 서버 프로세스로 분리해 주어야 한다.

4. Tuxedo 환경 변수

https://mc529.tistory.com/1373

출처 

# oracle tuxedo 리뷰

Online Transanction process성 업무를 다루는 Tuxedo에서 Client가 Server로 서비스를 호출하는 테스트를 진행하다가 tuxedo가 만들어내는 솔루션에 대한 생각을 해보았다.

늘 그렇듯, 

들어가는 문은 한정적이나 인구는 박이 터진다. 

하나의 예를 들어보자면 서울의 지하철은 출퇴근길에 지옥철로 유명하다.

전세계적으로 보아도 대한민국 서울의 지하철 밀집도는 늘 상위권에 머무른다.

출퇴근을 위해서 사람들은 지하철을 타기 위해 역으로 몰려든다.

하지만 지하철의 최대 탑승객 인원은 한정적이기 때문에 탑승하지 못한 승객은 다음 지하철을 기다려야한다.

지하철 탑승객들의 이러한 불편함을 한명이라도 줄이기 위해서는 사람들이 많을 수록 더 많은 지하철이 필요하다.

서비스업에서는 모두가 마찬가지일 것이다. ( 물론 사업이 잘 나가야한다는 전제조건이 필요하겠지만)

Tuxedo 프로세스는 서울의 지하철과 비슷하다.

service(지하철탑승)를 요청하는 Client(탑승객)는 수없이 많을 것이고 Server(지하철)는 한정적일 것이다.

server는 강남신세계백화점이라고 생각하면 쉽겠다!

손님(client)들은 강남역으로 가는 원활한 지하철을 이용하여 강남신세계백화점(server)에 도착하고 싶어한다.

신세계백화점(server)에는 모두가 사고 싶어하는 나이키신발(service)가 있다.

그런데 신세계백화점의 나이키매장은 한정적인데 나이키신발도 별로 없는거지...

장이 열리고 닫히는 주식시장에서의 매도와 매수가 활발하게 이루어지는 주식을 예를 들어 보자.

우리 (클라이언트)는 주식을 매수/매도 하기 위해 웹어플리케이션이나 모바일어플리케이션을 이용할 것이다.

여기서 어느 한 종목의 주식의 트레이딩을 주어진 시간에 나만 사용할 텐가? 절대 아닐 것이다. (물론 그럴 수 있다...)

셀수 없이 많은 나와 같은 Client와 그리고 나와 동시에 트레이딩을 할 수 있는 Client들이 수십명 또는 수천, 수억 명 또는 거래 횟수가 수천 번, 수억 번이 될 수도 있다. (물론 아마도 국내 이용자들은 이정도일 수는 없을 것이다...) 

이렇게 많은 Client들의 service request는 어떻게 처리될까? 서비스를 요청받는 Server에 부하가 이루어지지 않을까?

이러한 서비스들을 원할하게 이루어질 수 있도록 하는 것이 미들웨어단이 맡은 역할이라고 나는 생각한다.

사업의 특성상... 몰려오는 Client를 어떻게 할 수는 없을 것이다.

우리는 너희가 없어도 돈을 충분히 버니까 오지마라!

이럴 수도 없다. 

장사가 망할 수도 있는데...

그렇다면 Server는 어떻게 하면 될까?

간단하게 생각하자.

클라이언트가 원하는 서비스를 가진 어플리케이션서버들을 더 많이 만들면 된다. 

서비스를 사용하는 클라이언트가 많아지면 많아질수록 그 서비스를 가지고 있는 더욱 더 많은 서버를 만들면 되는 것이다.

신세계백화점에 나이키매장이 하나였는데 나이키 매장을 10곳을 더 만든다면?

분명히 손님의 밀집도도 나뉘어져서 매장의 service도 원할하게 이루어질 것이다.

너무 많은 예를 들어서 헷갈릴 수도 있겠다.

이러한 문제점들을 솔루션으로 제시하는 미들웨어가 Tuxedo라고 할 수 있다.

고객이(client)이 원활한 지하철(middleware)을 이용하여 신세계백화점(server)에 가서 원하는 나이키신발(service)을 가지고 나올 수 있도록 도와주는 매개체인 것이다.

즉,

Client와 server 사이에 위치하는 놈이 tuxedo 라고 할 수 있다.

즉, Tuxedo는 OS 상에 올라가는 미들웨어이다.

1. Weblogic console 접속 및 배치 선택 

2. 설치 선택 

3. 어플리케이션이 배포가 되기 위해서는 WEB-INF 라는 디렉토리에  web.xml 이 필요하다. 

    따라서 배포 하려는 어플리케이션이 존재하는 디렉토리에 WEB-INF 디렉토리가 필수로 존재하여야한다.

   배포할 디렉토리의 경로를 확인하고 선택 후 다음 버튼 클릭 

4. 설치 유형 및 범위 선택 

어플리케이션으로 설치하기 선택 후 다음 

5. 배포 대상 선택

6. 옵션 

디폴트값으로 진행 후 다음 클릭 

7. 검토하고 클릭 

8. 배포된 어플리케이션 확인 

# tmshutdown 

tmshutdown 커맨드와 주로 사용하는 옵션으로는

-cy 지만  (client들이 연결되어있어도 프로세스를 shutdown 하겠다 라는 옵션)

-w 옵션을 주어서 shutdown을  delay 시킬 수 있다.

# tmshutdown 예시 

* 예를 들어 >

> tmshutdown -w 2 -s simpserv 

server를 2초의 시간으로 딜레이를 주어 shutdown 시키겠다는 커맨드다.

-w 옵션은

1. SIGTERM 으로 죽이고, 그래도 내려가지 않는 경우에 

2. SIGKILL 로 죽인다.

# tmshutdown SIGKILL SIGTERM ? 

> tmshutdown -k TERM 으로

 tmshutdown을 하면 SIGTERM 함수를 보내어 tpsvrdone()을 수행하면서 process들이 종료가 되는데 SIGTERM 은 Application Server Process의 Hang 현상을 remove하기 위해 생겨진 함수이기 때문에

System Server Process들은 shutdown 되는 대상에서 제외가 된다.

*System Server Process :  DBBL, BBL, GWTDOMAIN, WSL 

> tmshutdown -k KILL 커맨드는 

엔진 내부적으로 SIGKILL 함수를 보내 Application Server Process에게 전달되어 tpsvrdone() 에 의해 종료된다.

(이때 WSH는 tuxedo 엔진 입장에서는 일종의 client이기 때문에 SIGKILL 시그널을 직접 받지 못하기 때문에 종료되지 않는다. 즉, 정상적인 종료인 경우에 WSL의 tpsvrdone 함수에서 WSH를 정리하는 단계가 있으나, 현재 SIGKILL시그널을 받아 갑자기 종료가 되므로 tpsvrdone 함수를 만나지 못하게 되어 WSH를 정리하지 못하고 종료되어 WSH 프로세스가 남는 것이다.)

테스트 환경

IBM AIX 7.2

-

Oracle Tuxedo 12c

Oracle Tuxedo 10.3g

테스트

한 계정으로 서로 다른 버전의 Tuxedo 엔진을 기동하는 테스트 진행 

테스트 내용 

UNIX OS상에서 같은 계정으로 접속하여 .profile에 각기 다른 환경설정을 해주고 엔진을 기동하였을 때,

하나의 Tuxedo가 올라가면 다른 version의 Tuxedo는 올라가지 않는 것을 확인하였다.

테스트 결과 

* 버전이 다를 경우 나오는 ULOG들 

LIBTUX_CAT:590: ERROR: Unable to read the TUXCONFIG file, version type mismatch

- 버전이 맞지 않기 때문에 환경변수파일을 읽고 올라갈 수 없다.

CMDTUX_CAT:111: ERROR: TUXCONFIG (/ofm/jwchoi/sw/tp/tux103/samples/atmi/simpapp/tuxconfig) of machine node1 
must be the same as the TUXCONFIG environment variable (/ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/tuxconfig)

CMDTUX_CAT:867: ERROR: tmloadcf: Above errors found during syntax checking

- 현재 엔진을 기동시키려는 버전의 환경변수가 현재 기동중인 버전의 환경변수를 읽고 올라갈 수 없다.

TMADMIN_CAT:188: ERROR: Error while obtaining the Bulletin Board parameters

- Bulletin Board 파라미터를 가져올 수 없다.

테스트 솔루션

현재 올라가있는 버전의 Tuxedo의 환경변수인 ubbconfig를 읽고 올라갈 수 없도록 

현재 기동시키려는 버전의 Tuxedo의 환경변수를 다시 export 해준다.

export TUXCONFIG=/ofm/jwchoi/sw/tp/tux103/samples/atmi/simpapp/tuxconfig

그리고

tmloadcf -y ubbsimple

tmboot -y

tmadmin -r

로 확인하여주면 정상적으로 기동되는 것을 확인할 수 있다.

BBL로 떠 있는 BBL을 확인한다.

두 개가 떠있는 것을 확인하였으므로 서로 다른 버전의 기동이 한계정으로 가능하다는 것이 결론

# ps -ef | grep BBL
  jwchoi  6685424        1   0 10:45:45 pts/11  0:00 BBL -C dom=simpapp -g 30002 -i 0 -u node1 -U /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/logs/ULOG -m 0 -A
  jwchoi  9110178  3146340   0 11:19:39 pts/16  0:00 grep BBL
  jwchoi 17105416        1   0   Nov 25      -  0:01 BBL -C dom=simpapp -g 30002 -i 0 -u node1 -U /ofm/jwchoi/sw/tp/tux103/samples/atmi/simpapp/ULOG -m 0 -A

Tuxedo service rename 방법

#실행 결과

> 실제 서비스 이름 : TOLOWER

- psc로 확인 했을 때 service name이 TOLOWER2로 호출 되어야 함.

   * TOLOWER2은 예시. 수정 가능

수정이 필요한 환경변수

*SERVER

*SERVICES 

1. *server단에서 simpserv2 수정

2. CLOPT에 -s 옵션을 추가하여 TOLOWER2(변경될 서비스명):TOLOWER(변경할 서비스명) 

ex)

CLOPT=" -s TOLOWER2:TOLOWER"

ubbconfig예시)

simpserv2       SRVGRP=GROUP2 SRVID=200
                CLOPT="-A -r -s TOLOWER2:TOLOWER -o /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/stdout2 -e /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/simpapp/stder
r2 -- -s TOLOWER2:TOLOWER"
                RQADDR="test2"
                RQPERM=0600 MIN=10 MAX=30  REPLYQ=Y   CONV=N  SEQUENCE=11
                MAXGEN=255  GRACE=86400

3. *service단에서 TOLOWER2 추가 

*services 에 서비스 추가 

*SERVICES
TOLOWER2        SRVGRP=GROUP2
TOUPPER
TOLOWER

4. Client에서 서비스함수를 TOLOWER2로 수정 후 컴파일 

buildclient -w -o simpcl -f simpcl.c 

5. AP Server로 서비스 호출이 되는지 확인

./simpcl AAAAAAAAAAAAAAAA  

엔진 재기동 후 커맨드

tmshutdown -cy 

tmloadcf -y ubbshm

tmboot -y

tmadmin -r 

psc 

printservice

psc
Service Name Routine Name Prog Name  Grp Name  ID    Machine  # Done Status
------------ ------------ ---------  --------  --    -------  ------ ------
TOUPPER      TOUPPER      simpserv4  GROUP4   400       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   200       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   401       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   201       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   402       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   202       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   403       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   203       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   404       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   204       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   405       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   205       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   406       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   206       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   407       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   207       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   408       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   208       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   409       AIX1       0 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   209       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   300       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   100       AIX1       0 AVAIL
DMADMIN      DMADMIN      DMADM      DOMGRP   300       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   301       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   101       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   302       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   102       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   303       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   103       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   304       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   104       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   305       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   105       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   306       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   106       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   307       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   107       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   308       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   108       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   309       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   109       AIX1       0 AVAIL
TUXDOM1      GWS          GWADM      DOMGRP   310       AIX1       0 AVAIL
TOUPPER      GWS          GWTDOMAIN  DOMGRP   320       AIX1       0 AVAIL
TOLOWER      GWS          GWTDOMAIN  DOMGRP   320       AIX1       0 AVAIL

변경 후  printservice 

TOLOWER-> TOLOWER2

> psc
Service Name Routine Name Prog Name  Grp Name  ID    Machine  # Done Status
------------ ------------ ---------  --------  --    -------  ------ ------
TOUPPER      TOUPPER      simpserv4  GROUP4   400       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   200       AIX1      68 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   200       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   401       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   201       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   201       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   402       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   202       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   202       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   403       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   203       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   203       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   404       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   204       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   204       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   405       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   205       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   205       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   406       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   206       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   206       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   407       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   207       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   207       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   408       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   208       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   208       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv4  GROUP4   409       AIX1       0 AVAIL
TOLOWER2     TOLOWER      simpserv2  GROUP2   209       AIX1      69 AVAIL
TOLOWER      TOLOWER      simpserv2  GROUP2   209       AIX1       5 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   300       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   100       AIX1       0 AVAIL
DMADMIN      DMADMIN      DMADM      DOMGRP   300       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   301       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   101       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   302       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   102       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   303       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   103       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   304       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   104       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   305       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   105       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   306       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   106       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   307       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   107       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   308       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   108       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv3  GROUP3   309       AIX1       0 AVAIL
TOUPPER      TOUPPER      simpserv   GROUP1   109       AIX1       0 AVAIL
TUXDOM1      GWS          GWADM      DOMGRP   310       AIX1       0 AVAIL
TOUPPER      GWS          GWTDOMAIN  DOMGRP   320       AIX1       0 AVAIL
TOLOWER      GWS          GWTDOMAIN  DOMGRP   320       AIX1       0 AVAIL

고객사에서 AP Server process가 계속 죽고 restart 되는 로그를 발견했다.

tmshutdown 으로 내린 후 재기동하니까 정상적으로 되었다고한다.

일단 테스트를 해보기위해 정상적으로 process 되고 있는 놈들을 ps -ef | grep PID 로 찾고

kill -9 하였을 때, server는 죽고 restart 되는 것을 확인했다. 

(UBBCONFIG에 *SERVER단에 default 값으로 RESTART=Y옵션을 주었으니 당연히 restart되는 것이다.)

AIX node 1에서 simpserv4.c의 함수를 TPSUCCESS --> TPEXIT 로 바꿔주었다.

TPEXIT는  TPFAIL와 같은 의미 (서비스 수행이 제대로 되지 않았음을 의미) 지만 Server를 종료한다는 점이 다르다.

따라서 TPEXIT로 해당 APserver(simpserv4) 가 내려지지만 

Server 단에서 restart=y 옵션으로 인해 다시 재기동 된다.

아래를 참고하자

#include <stdio.h>
#include <ctype.h>
#include <atmi.h>       /* TUXEDO Header File */
#include <userlog.h>    /* TUXEDO Header File */


#if defined(__STDC__) || defined(__cplusplus)
tpsvrinit(int argc, char *argv[])
#else
tpsvrinit(argc, argv)
int argc;
char **argv;
#endif
{
        argc = argc;
        argv = argv;

        userlog("Welcome to the simple server");
        return(0);
}


#ifdef __cplusplus
extern "C"
#endif
void
#if defined(__STDC__) || defined(__cplusplus)
TOUPPER(TPSVCINFO *rqst)
#else
TOUPPER(rqst)
TPSVCINFO *rqst;
#endif
{

        int i;

        for(i = 0; i < rqst->len-1; i++)
                rqst->data[i] = toupper(rqst->data[i]);
        /* sleep(45);  */
        tpreturn(TPEXIT, 0, rqst->data, 0L, 0);

}
~

102454.node1!BBL.14090774.1.0: LIBTUX_CAT:541: WARN: Server GROUP4/400 terminated
102454.node1!BBL.14090774.1.0: LIBTUX_CAT:557: INFO: Server GROUP4/400 being restarted
102454.node1!simpserv4.14877312.1.0: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
102454.node1!simpserv4.14877312.1.0: LIBTUX_CAT:260: WARN: Cannot open /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/ as stderr, Uunixerr = Cannot write to a directory.

102454.node1!simpserv4.14877312.1.0: LIBTUX_CAT:262: INFO: Standard main starting
102454.node1!simpserv4.14877312.1.0: Welcome to the simple server
102454.node1!restartsrv.15794824.1.-2: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
102454.node1!restartsrv.15794824.1.-2: server GROUP4/400: CMDTUX_CAT:580: INFO: A server process has restarted: 14877312

134228.node1!simpserv4.21561688.1.0: LIBTUX_CAT:1393: WARN: tpreturn called with TPEXIT
134239.node1!BBL.14090774.1.0: LIBTUX_CAT:541: WARN: Server GROUP4/400 terminated
134239.node1!BBL.14090774.1.0: LIBTUX_CAT:557: INFO: Server GROUP4/400 being restarted
134240.node1!simpserv4.15860432.1.0: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
134240.node1!simpserv4.15860432.1.0: LIBTUX_CAT:260: WARN: Cannot open /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/ as stderr, Uunixerr = Cannot write to a directory.
134240.node1!simpserv4.15860432.1.0: LIBTUX_CAT:262: INFO: Standard main starting
134240.node1!simpserv4.15860432.1.0: Welcome to the simple server
134240.node1!restartsrv.13763080.1.-2: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
134240.node1!restartsrv.13763080.1.-2: server GROUP4/400: CMDTUX_CAT:580: INFO: A server process has restarted: 15860432
134430.node1!WSH.12190422.1.0: WARNING: LLE Configuration discovered! Note that LLE has been deprecated. You should upgrade to SSL to secure network links.

134430.node1!simpserv4.15860432.1.0: LIBTUX_CAT:1393: WARN: tpreturn called with TPEXIT
134432.node1!WSH.55902548.1.0: WARNING: LLE Configuration discovered! Note that LLE has been deprecated. You should upgrade to SSL to secure network links.
134432.node1!WSH.55902548.1.0: WSNAT_CAT:1042: ERROR: tpcall() call failed, tperrno = 6
134439.node1!BBL.14090774.1.0: LIBTUX_CAT:541: WARN: Server GROUP4/400 terminated
134439.node1!BBL.14090774.1.0: LIBTUX_CAT:557: INFO: Server GROUP4/400 being restarted
134440.node1!simpserv4.5308936.1.0: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
134440.node1!simpserv4.5308936.1.0: LIBTUX_CAT:260: WARN: Cannot open /ofm/jwchoi/sw2/tp/tuxedo12.2.2.0.0/samples/atmi/ as stderr, Uunixerr = Cannot write to a directory.
134440.node1!simpserv4.5308936.1.0: LIBTUX_CAT:262: INFO: Standard main starting
134440.node1!simpserv4.5308936.1.0: Welcome to the simple server
134440.node1!restartsrv.16646680.1.-2: 11-16-2022: Tuxedo Version 12.2.2.0.0, 64-bit
134440.node1!restartsrv.16646680.1.-2: server GROUP4/400: CMDTUX_CAT:580: INFO: A server process has restarted: 5308936

이 때, 되살아나는 프로세스의 PID는 보이지만, 죽는 PID는 ULOG 상에서 보이지않기 때문에

PID가 죽지 않는데 왜 restart를 하지? 라고 오해를 할 수 있다. 

알아두자. Kill 되는 process의 PID는 보이지 않고, 새롭게 갱신되며 restart되는 것이다.

그런데 프로세스가 스스로 죽고, 다시 restart 되는 테스트를 해보아야한다.