FileCaching & WLTempDir

WEBLOGIC ~ OHS 플러그인 parameter 중 FileCaching과 WLTempDir 관련된 정리글이다. FileCaching : default는 ON 이며, 내용은 다음과 같다.\ - POST data가 2048 이하일 경우 : FileCache를 하지 않는다. - POST data가 2048 초과일 경우 : POST data를 임시 파일에 먼저 cache한 이후, 나중에 8192 chunk 단위로 WLS로 따로 전송한다. FileCaching이 ON일 때 WLS primary server가 다운되면 secondary server로 보내며, OFF일 경우 임시 파일을 거치지 않고 바로 8192 chunk 단위로 WLS로 보냄. WLTempDir : 플러그인 관련 로그 파일 경로(wlprox..

mime types 설정

MIME이란 Multipurpose Internet Mail Extensions의 약자로 파일 변환을 의미한다. 오디오 파일 등을 예시로 들자면, 이전 ASCII 표준을 사용하지 않는 바이너리 파일을 전송해야 하기 때문에, 이를 텍스트 파일로 Encoding 하고 => 바이너리 파일로 Decoding 하는 작업을 해야한다. 이때 MIME으로 인코딩한 파일은 Content-type 정보를 앞부분에 담게 된다. (참조 : https://velog.io/@aerirang647/MIME-type%EC%9D%B4%EB%9E%80) MIME들은 mime.types 파일에서 설정이 가능하며, 위 파일은 httpd.conf와 동일한 경로에 위치한다. 위와 같은 형태: ${Content-Type} ${Extensions..

WTC

테스트 환경 : WebLogic 12cR2, Tuxedo 12c (OS: AIX) WTC(Weblogic Tuxedo Connector)는 WebLogic과 Tuxedo를 연동하여 weblogic 어플리케이션과 Tuxedo 서비스 간에 상호 운용성을 제공해주는 컴포넌트이다. JOLT와의 차이라면, JOLT는 WebLogic에서만 Tuxedo의 서비스를 호출할 수 있지만 WTC는 양방향이 가능하다. ## Tuxedo에서 WebLogic WTC 정보는 다음과 같이 필요하다 - WLS Domain Name (임의 설정) - IP, Port - Connection Policy (default: on demand) ## WebLogic에서 Tuxedo WTC 정보는 다음과 같이 필요하다 -TUX Domain Na..

WebLogic 점검 간소화

가령 30일에 한번씩 쌓이는 로그 분석 (원래는 Server log 기준)을 하려 할때, grep을 사용하는 스크립트를 사용하여 손쉽게 점검을 진행할 수 있다. 위 방법을 위한 테스트 절차이다. 현재 M1 ~ M4 총 4개의 인스턴스가 있고, log home 디렉토리에서 uclick.sh를 돌려서 한번에 각 인스턴스들의 모든 nohup 로그에서 필요한 정보를 log.txt에 담고자 한다. (점검 관리 편의) 해당 경로 (ex> M3/nohup/uclick.sh)의 내용은 다음과 같다. find ./ -type f -mtime -6 -exec egrep -i -s -H "${찾으려는 문자열}" {} \; >> ${리다이렉트 하고자 하는 텍스트 경로/파일이름} # find -type f : 지정한 파일 유형..

WebLogic Multicast cluster debugging

WebLogic에서 multicast cluster를 사용하고 있을 때, 다음과 같은 테스트를 통해 유효성 및 디버깅이 가능하다. 1. JAVA utility 사용 - java utils.MulticastTest -n -a -p - java weblogic.cluster.MulticastMonitor # 단, 해당 address의 multicast가 기동중이라면 IP 충돌로 인해 현재 운영중인 WLS 서비스에 영향르 주기에 반드시! WLS 인스턴스가 기동중이지 않을 때 (Multicast cluster가 사용중이지 않을 떄) 테스트를 진행해야 함. 2. Multicast debugging option -Dweblogic.debug.DebugCluster=true -Dweblogic.debug.DebugC..

OHS plugin debugging

Mod_wl_ohs.so를 확인하면 WEBLOGIC ~ OHS는 default 플러그인 파일인 위의 so 파일을 사용중이다. 위의 대한 debugging 레벨 로그는 다음과 같이 설정 가능하다. 1. odl-text(ODL-Text) 모드 OraLogMode odl-text OraLogSeverity TRACE:16 (default는 WARNING:32) 2. apache 모드 OraLogMode apache LogLevel debug (보통은 Info 권장) ============================================================== 플러그인에 대한 debugging 처리 Debug는 다음과 같이 설정이 가능하다. - ON : 플러그인 정보 및 에러메시지 작성. WL..

Coherence 클러스터 기본

# TCMP => Tangosol Cluster Management Protocol의 줄임말. 클러스터 구성원을 검색/관리 및 서비스 프로비저닝 & 데이터 전송을 위해 사용되는 IP 기반 프로토콜이다. => 기본적으로 UDP/IP MultiCast와 UDP/IP UniCast의 조합이다. 단, 각각을 사용 안하게 설정이 가능함. # Coherence cluster란 => 클러스터는 어플리케이션 확장성, 가용성 및 성능을 높이기 위해 메모리 내 데이터를 배포하는 여러 coherence instance로 구성됨. => WebLogic과 Coherence는 서로 다른 프로토콜을 사용하며 별도로 구성되는 서로 다른 클러스터이다. ex> 여러 WLS 클러스터를 coherence 클러스터에 연결할 수 있다. # C..

OHS proxy balancer를 통한 load balancing

mod_proxy_balancer를 통해 WebLogic ~ OHS가 연동되어 있는 상황에서 WAS 인스턴스들에게 로드 밸런싱을 하고자 한다. 위의 결과로 기대할 수 있는 부분은 OHS가 처음에 session 값을 받은 서버에 sticky session처리가 되어, session이 이후로도 지속적으로 유지가 될 수 있다는 부분이다. 다만 지속적으로 같은 서버를 사용하게 되기 때문에, 로드 밸런싱의 효율이 떨어져 속도 저하가 일어날 수도 있다는 단점 또한 있다. ========================================================================================== => 현재 WebLogic 인스턴스 2개가 연동되어 있는 상황이다. ..