이 장에서는 Sun Java System Application Server Enterprise Edition 8.1 2005Q2 소프트웨어의 알려진 문제점과 이를 해결하는 방법에 대해 설명합니다. 문제를 설명하는 부분에서 특정 플랫폼을 언급하지 않는 경우에는 해당 문제가 모든 플랫폼에 적용됩니다. 이 정보는 다음 내용으로 구성되어 있습니다.
이 절에서는 관리와 관련된 알려진 문제점과 해결 방법을 설명합니다.
이 절에서는 Apache Web Server 및 로드 균형 조정기 플러그인과 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6306784 |
고가용성 관리 설명서에 Apache에서의 openssl 사용에 대한 지침이 잘못되어 있습니다. 해결 방법 openssl을 컴파일하고 빌드할 때 다음 명령을 실행합니다. cd openssl-0.9.7e config make 또한 Apache 1.3의 경우 mod_ssl 소스의 디렉토리 이름은 사용되는 Apache 릴리스에 따라 달라집니다. 예를 들어 Apache 1.3.33에서 이름은 mod_ssl-2.8.22-1.3.33입니다. |
6307976 |
고가용성 관리 설명서에 Apache 2.0 인증서 사용에 대한 지침이 없습니다. 해결 방법 Apache 보안을 실행하기 위해서는 인증서를 사용해야 합니다. 인증 기관에서 인증서를 얻는 방법은 modssl FAQ에서 인증서에 대한 정보를 참조하십시오. |
6308021 |
Apache Web Server를 루트로 시작해야 합니다. 해결 방법 Application Server가 루트에서 설치되었을 경우 Apache Web Server를 루트로 시작해야 합니다(Solaris만 해당). Java Enterprise System 설치는 루트로 설치됩니다. Apache 2.0의 경우 Apache는 루트로 시작한 후 사용자가 지정하는 다른 사용자로 전환되어 실행됩니다. /conf/httpd.conf 파일에서 해당 사용자를 지정합니다. 루트로 시작하려면 대부분의 시스템에서 httpd.conf 파일을 편집하여 정확한 그룹을 지정해야 합니다. 다음 명령줄을 Group #-1 아래와 같이 바꿉니다. Group nobody 사용자/그룹 사용에 대한 자세한 내용은 httpd.conf 파일에 포함되어 있습니다. |
6308043 |
Solaris에서 Apache Web Server의 openssl 사용에 대한 지침에 추가 사항이 있습니다. Apache 2.0과 로드 균형 조정기 플러그인을 설치한 후에 ssl.conf와 sll-std.conf를 다음과 같이 편집합니다. 다음 명령줄을 <VirtualHost _default_:9191> 아래와 같이 바꿉니다. <VirtualHost machine_name:9191> 여기서, machine_name은 사용하는 시스템의 이름이고 9191은 보안 포트 번호입니다. |
이 절에서는 응용 프로그램 클라이언트와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6193556 |
Application Client Archive에 패키지로 포함된 라이브러리 JAR이 MANIFEST 파일을 덮어씁니다. 클라이언트 JAR 내에 최상위 JAR 파일이 있는 경우(이 경우에는 reporter.jar) 클라이언트 JAR을 배포할 때 해당 JAR의 MANIFEST 파일이 클라이언트 JAR의 MANIFEST 파일을 덮어씁니다. 해결 방법 현재는 해결 방법이 없습니다. |
6373043 |
CGI-bin 및 SHTML과 같은 동적 콘텐츠 기술은 더 이상 지원되지 않습니다. 해결 방법 JSP 및 웹 서비스 기술을 대신 사용하십시오. |
이 절에서는 번들로 제공되는 Sun JDBC 드라이버와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6165970 |
번들로 제공되는 Microsoft SQL Server용 Sun 드라이버와 함께 TRANSACTION_SERIALIZABLE 격리 수준을 사용하는 응용 프로그램은 두 개의 트랜잭션이 병행하여 실행 중이고 그 중 하나가 롤백하면 준비된 명령문을 사용하여 업데이트할 경우 중단됩니다. 연결을 위해 원하는 격리 수준을 설정하려면 같은 격리 수준에 상응하는 연결 풀을 만들어야 합니다. 연결 풀 구성에 대한 자세한 내용은 관리 설명서를 참조하십시오. 해결 방법 현재는 해결 방법이 없습니다. |
6170432 |
PreparedStatement 에러 설명 1 응용 프로그램이 하나의 트랜잭션에서 3000개가 넘는 PreparedStatement 객체를 생성하면 DB2에 다음 오류가 발생할 수 있습니다. [sunm][DB2 JDBC Driver] No more available statements. Please recreate your package with a larger dynamicSections value. 해결 방법 1 연결 풀 정의에 다음 등록 정보를 추가하여 드라이버에서 더 큰 동적 섹션 값으로 DB2 패키지를 다시 바인드하도록 합니다. createDefaultPackage=true replacePackage=true dynamicSections=1000 연결 풀 구성에 대한 자세한 내용은 관리 설명서를 참조하십시오. 설명 2 위의 PrepardStatement 오류와 관련하여 발생할 수 있는 다른 오류 메시지는 다음과 같습니다. [sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available. 해결 방법 2 DB2 서버 구성 매개 변수 APPLHEAPSZ를 증가시킵니다. 권장 값은 4096입니다. 설명 3 TRANSACTION_SERIALIZABLE 격리 수준 응용 프로그램에서 TRANSACTION_SERIALIZABLE 격리 수준을 사용하고 위에 제시한 매개 변수 중 하나를 사용하면 연결하는 동안 응용 프로그램이 중단될 수 있습니다. 해결 방법 3 연결을 위해 바람직한 격리 수준을 설정하려면 상응하는 연결 풀을 같은 격리 수준에 만들어야 합니다. 자세한 내용은 관리 설명서를 참조하십시오. |
6189199 |
번들로 제공된 Sybase Adaptive Server용 Sun 드라이버의 격리 수준을 설정할 때 문제가 발생합니다.
해결 방법 현재는 해결 방법이 없습니다. |
6247468 |
Solaris 10과 Enterprise Linux 3.0에서는 Sun에서 번들로 제공하는 Oracle JDBC 드라이버로 연결을 만들 수 없습니다. 해결 방법 SUN JDBC Oracle 데이터 소스(com.sun)를 사용할 때 JDBC 연결 풀에서 다음 등록 정보를 설정합니다. sql.jdbcx.oracle.OracleDataSource): <property name="serverType" value="dedicated"/> 등록 정보 값은 Oracle 서버의 수신기가 구성된 방식에 따라 달라집니다. "공유" 모드로 구성되어 있으면 위 값을 "전용"으로 변경해야 합니다. |
6554602 |
CLASSPATH에 두 개 이상의 JDBC jar 파일이 있는 JDBC 10.2 드라이버에서 시작하는 경우 java.lang.SecurityException: Sealing violation exception이 발생할 수 있습니다. Oracle의 자세한 설명은 다음 Oracle 문서 ID에 기록되어 있습니다. 주: 405446 주제: DBC Driver 10.2는 Sealed JAR 파일을 사용하며 Security Exception Sealing Violation이 발생할 수 있습니다. 해결 방법 (Oracle 제안) CLASSPATH 는 하나의 JDBC 드라이버 JAR 파일만 포함하는지 확인하십시오. |
이 절에서는 J2EE 커넥터 구조와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6188343 |
DAS 인스턴스를 다시 시작한 후 cascade를 false로 설정하면 커넥터 모듈 배포 해제가 실패하게 됩니다. 이 시나리오에서 독립형 또는 내장형 커넥터 모듈은 DAS와 커넥터 연결 풀에 배포되며 배포된 모듈을 위한 자원이 만들어집니다. DAS 인스턴스를 다시 시작한 후 cascade를 false로 설정하면 다음 예외가 발생하고 커넥터 모듈 배포 해제가 실패하게 됩니다: [#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023:Error while unloading application [foo]|#] 해결 방법 DAS 인스턴스를 다시 시작한 후 독립형 및 내장형 커넥터의 배포를 해제하려면 종속 배포 해제(cascade 옵션을 true로 설정)를 사용합니다. |
이 절에서는 설명서와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
||
---|---|---|---|
여러 ID |
Javadoc 비일관성 문제가 발생합니다. 몇 가지 AMX 인터페이스와 메소드를 위한 Javadoc가 누락되었거나 잘못되어 있습니다.
|
||
6265624 |
번들로 제공되는 ANT는 java.lang.NoClassDefFoundError을 발생시킵니다. 다음 예외는 스레드 "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher에서 발생합니다. 해결 방법 Application Server 외부의 항목에 대해 번들로 제공되는 ANT를 사용하는 것은 좋지 않습니다. |
||
6486123 |
래핑된 연결에서 물리적 연결을 가져오는 방법에 대한 설명이 더 이상 올바르지 않습니다. 다른 결함(6295215일 수 있음)으로 인해 Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide의 Obtaining a Physical Connection from a Wrapped Connection의 11장, Using the JDBC API for Database Access,에서 Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide의 11 장, Using the JDBC API for Database Access의 Obtaining a Physical Connection from a Wrapped Connection절에 제공된 코드가 올바르지 않습니다. 특히,
줄은 다음과 같이 변경되었습니다.
|
이 절에서는 고가용성 데이터베이스(HADB)와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
|||
---|---|---|---|---|
ID 없음 |
이중 네트워크를 사용한 HADB 구성 문제가 발생합니다. Solaris SPARC에서는 두 개의 서브넷에 이중 네트워크와 함께 구성된 HADB가 제대로 작동합니다. 그러나, 운영 체제 또는 일부 하드웨어 플랫폼의 네트워크 드라이버 문제 때문에 Solaris x86과 Linux 플랫폼에서는 이중 네트워크를 제대로 처리할 수 없는 경우가 있는 것으로 확인되었습니다. 이로 인해 HADB에 발생하는 문제는 다음과 같습니다.
|
|||
ID 없음 |
HADB 데이터베이스 생성이 실패합니다. 사용할 수 있는 공유 메모리 세그먼트가 너무 적다는 뜻의 다음 오류로 새 데이터베이스 생성에 실패할 수 있습니다. HADB-E-21054:System resource is unavailable:HADB-S-05512:Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message:Too many open files. 해결 방법 공유 메모리가 구성되었는지와 구성이 작동하는지를 확인합니다. 특히, Solaris 8에서는 파일 /etc/system을 검사하고 변수 shmsys:의 값이 다음과 같은지 확인합니다. shminfo_shmseg는 적어도 호스트당 노드 수의 6배입니다. |
|||
5052548 |
공유 메모리 세그먼트가 잠겨서 페이지 아웃할 수 없습니다. HADB 4.3-0.16 이상은 해당 공유 메모리 세그먼트(SHM_SHARE_MMU 플래그 사용)를 만들어 연결할 때 Intimate Shared Memory를 사용하도록 구성되었습니다. 이 플래그를 사용하면 공유 메모리 세그먼트가 물리적 메모리로 잠기기 때문에 페이지 아웃되지 않습니다. 이 경우 저사양의 시스템에서 설치할 때 문제가 발생하기 쉽습니다. 따라서 개발자가 메모리 용량이 512MB이고 Application Server7.0 EE 사용 시 사용 가능한 스왑 공간이 충분한 시스템에 7.1 EE 이상을 설치한 경우 clsetup 클러스터를 구성하는 데 문제가 발생합니다. 이 클러스트는 HADB 노드 2개를 만들며 각각의 devicesize가 512이므로 2개의 노드에서 필요한 공유 메모리를 지원하기에 물리적 RAM이 충분하지 않습니다 해결 방법 Application Server와 HADB를 함께 배치할 경우 권장량의 메모리를 설치해야 합니다. 자세한 내용은 HADB 요구 사항 및 지원되는 플랫폼을 참조하십시오. |
|||
5091280 |
hadbm set가 자원 가용성(디스크 및 메모리 공간)을 확인하지 않습니다. hadbm set를 사용하여 장치 또는 버퍼 크기를 증가시키면 관리 시스템에서 데이터베이스를 만들거나 노드를 추가할 때 자원 가용성을 확인하지만 장치나 주 메모리 버퍼 크기가 변경될 때는 충분한 자원이 있는지 확인하지 않습니다. 해결 방법 devicesize 또는 buffersize 구성 속성을 증가시키기 전에 모든 호스트에서 사용 가능 디스크와 메모리 공간이 충분한지 확인합니다. |
|||
5091349 |
packagepath를 위한 이기종 경로가 지원되지 않습니다. 같은 이름의 동일한 소프트웨어 패키지를 서로 다른 호스트의 여러 위치에 등록할 수 없습니다. 예를 들면 다음과 같습니다.
해결 방법 HADB는 데이터베이스 클러스터의 여러 노드에 걸친 이기종 경로를 지원하지 않습니다. HADB 서버 설치 디렉토리(--packagepath)가 모든 참여 호스트에서 동일한지 확인합니다. |
|||
6173886, 6253132 |
createdomain이 실패할 수 있습니다. 네트워크 인터페이스가 여러 개인 호스트에 관리 에이전트를 실행하면 createdomain 명령은 모든 네트워크 인터페이스가 동일한 서브넷에 있지 않을 경우 실패하게 됩니다.
관리 에이전트(다르게 구성되지 않은 경우)는 UDP 멀티캐스트에 대해 "첫 번째" 인터페이스를 사용합니다("첫 번째"는 java.net.NetworkInterface.getNetworkInterfaces()의 결과로 정의됨). 해결 방법 최고의 해결 방법은 관리 에이전트에 사용할 서브넷을 요청하는 것입니다(구성 파일에서 ma.server.mainternal.interfaces 설정. 예: ma.server.mainternal.interfaces=10.11.100.0). 서브넷 사이의 라우터를 구성하여 멀티캐스트 패킷을 라우팅할 수도 있습니다(관리 에이전트는 멀티캐스트 주소 228.8.8.8을 사용). 관리 에이전트의 새 구성으로 재시도하기 전에 관리 에이전트 리포지토리를 정리해야 합니다. 도메인의 모든 에이전트를 중단하고 리포지토리 디렉토리에서 모든 파일과 디렉토리를 삭제합니다(관리 에이전트 구성 파일에 repository.dr.path로 표시). 새 구성 파일을 가진 에이전트를 다시 시작하기 전에 모든 호스트에서 이를 수행해야 합니다. |
|||
6190878 |
HADB 인스턴스를 삭제한 후 디렉토리를 정리해야 합니다. HADB 인스턴스를 삭제한 후 configure-ha-cluster 명령으로 새 인스턴스를 만들려고 하면 실패합니다. 문제는 이전 디렉토리가 ha_install_dir/rep/* 및 ha_install_dir/config/hadb/instance_name에 있는 원래 HADB 인스턴스에 남겨진다는 것입니다. 해결 방법 HADB 인스턴스를 삭제한 후 이러한 디렉토리를 수동으로 삭제하십시오. |
|||
6230792, 6230415 |
HADB 시작, 중단, 재구성 등이 실패하거나 중단될 수 있습니다. Solaris 10 Opteron에서 hadbm 명령을 사용하여 HADB를 시작하거나 중단 또는 재구성하면 다음 오류 중 하나로 실패하거나 중단될 수 있습니다.
clu_noman_srv 프로세스에서 사용하는 파일(nomandevice)에 일관되지 않은 읽기/쓰기가 있는 경우 이 문제가 발생할 수 있습니다. HADB 내역 파일에서 다음 메시지를 찾으면 이 문제가 있다는 뜻입니다.
해결 방법 문제가 재현되지는 않았으므로 다음 해결 방법은 검증된 내용이 아닙니다. 그러나 영향을 받은 노드에 대해 이 명령을 실행하면 문제가 해결됩니다.
노드에 대한 모든 장치가 다시 초기화됩니다. 다시 초기화하기 전에 노드를 중단시켜야 할 수도 있습니다. |
|||
6232140 |
관리 에이전트가 "IPV6_MULTICAST_IF failed" 예외로 종료됩니다. NIC 카드가 여러 개 설치된 Solaris 8을 실행 중인 호스트에서 시작할 경우 IPv6과 IPv4가 활성화된 카드가 혼합되어 있다면 관리 에이전트는 "IPV6_MULTICAST_IF failed" 예외로 종료될 수 있습니다." 해결 방법 JAVA_OPTIONS 환경 변수를 -Djava.net.preferIPv4Stack=true로 설정합니다. 예를 들면 다음과 같습니다.
또는 이러한 문제가 없는 Solaris 9 이상을 사용하십시오. |
|||
6249685 |
clu_trans_srv을 중단할 수 없습니다. 비동기 I/O를 수행할 때 Red Hat Enterprise Linux 3.0의 64비트 버전에 clu_trans_srv 프로세스를 무중단 모드로 만드는 버그가 있습니다. 즉, kill -9가 동작하지 않아 운영 체제를 재부팅해야 합니다. 해결 방법 Red Hat Enterprise Linux 3.0의 32비트 버전을 사용합니다. |
|||
6262824 |
hadbm은 대문자로 된 암호를 지원하지 않습니다. 암호가 hadb에 저장될 때 대문자로 된 암호는 소문자로 변환됩니다. 해결 방법 암호에 대문자를 사용하지 마십시오. |
|||
6265419 |
HADB 버전 4.4.2.5에서 HADB 버전 4.4.1.7로 다운그레이드하면 다른 오류 코드가 표시되면서 ma는 실패합니다. 이전 HADB 버전으로 다운그레이드하면 다른 오류 코드가 표시되면서 관리 에이전트는 실패합니다. 해결 방법 HADB 데이터베이스를 다운그레이드할 수 있지만, 리포지토리 객체가 변경되었을 경우 관리 에이전트는 다운그레이드할 수 없습니다. 다운그레이드 후에는 최신 HADB 버전에서 관리 에이전트를 사용해야 합니다. |
|||
6271063 |
설치/제거 및 symlink 유지 HADB c 패키지(Solaris: SUNWhadbc, Linux: sun-hadb-c) 버전 <m.n.u-p>의 설치/제거와 관련하여 symlink /opt/SUNWhadb/<m>는 일단 존재하는 경우 수정되지 않습니다. 따라서 연결이 끊어진 symlink가 있을 수 있습니다. 해결 방법 설치 전이나 제거 후에 사용 중이지 않은 경우 symlink를 삭제합니다. |
|||
6273681 |
전역 및 로컬 영역에서 여러 관리 에이전트가 충돌합니다. Solaris 10에서는, 전역 영역에서 ma-initd 스크립트를 사용하여 관리 에이전트를 중단하면 로컬 영역에서도 관리 에이전트가 중단됩니다. 해결 방법 전역 및 로컬 영역 모두에 관리 에이전트를 설치하지 마십시오. |
|||
6275103 |
hadbm/ma는 세션 객체가 시간 초과되어 MA에서 삭제될 때 더 나은 오류 메시지를 표시해야 합니다. 가끔 서버의 자원 충돌 문제로 인해 관리 클라이언트의 연결이 끊어질 수 있으며, 다시 연결하면 "hadbm:Error 22184:A password is required to connect to the management agent" 오류 메시지가 반환됩니다. 해결 방법 서버에 자원 문제가 있다면 자원을 추가하는 등 적절한 조치를 취한 다음 다시 시도해보십시오. |
|||
6275319 |
루트가 아닌 사용자는 HADB를 관리할 수 없습니다. Java Enterprise System에서 (루트로) 설치하면 루트가 아닌 사용자는 HADB를 관리할 수 없습니다. 해결 방법 항상 루트로 로그인하여 HADB를 관리합니다. |
|||
6293912 |
관리 에이전트는 특수 용도의 인터페이스를 사용해서는 안 됩니다. 0.0.0.0과 같은 IP 주소를 가진 특수 용도의 인터페이스는 관리 에이전트에서 HADB 노드에 사용할 유효한 인터페이스로 등록되지 않아야 합니다. 이러한 인터페이스를 등록하면 IP 주소 대신 호스트 이름을 사용하여 hadbm create 명령을 호출하는 사용자에 의해 HADB 노드가 이런 인터페이스에 설정되었을 경우 문제가 생길 수 있습니다. 그러면 노드가 통신할 수 없게 되어 create 명령이 중단될 수 있습니다. 해결 방법 인터페이스가 여러 개 있는 호스트에서 hadbm create를 사용할 때 항상 DDN 표기 형식을 사용하여 IP 주소를 명확하게 지정해야 합니다. |
|||
6291562 |
Windows에서 리어셈블리 오류 특정 구성과 로드의 Windows 플랫폼에서 운영 체제에 많은 리어셈블리 오류가 있을 수 있습니다. 여러 테이블에 대한 스캔을 동시에 실행할 때(select *) 20개가 넘는 노드로 된 구성에 문제가 있었습니다. 트랜잭션이 자주 중단되거나 복구를 완료하는 데 시간이 오래 걸리는 등의 징후가 있거나 시스템의 여러 부분에서 자주 시간 초과가 일어날 수 있습니다. 해결 방법 이 문제를 해결하기 위해 Windows 레지스트리 변수 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 를 기본값인 100보다 높게 설정할 수 있습니다. 이 값을 0x1000 ( 4096)까지 증가시키는 게 좋습니다. 자세한 내용은 Microsoft 지원 페이지의 811003 기사를 참조하십시오. |
|||
6303581, 6346059, 6307497 |
hadbm start <db_name>을 실행하면 입력된 암호의 일부가 마스크 처리되지 않고 표시됩니다. 시스템이 로드 중인 경우 시스템 마스크 처리가 실패할 수 있으며 입력되는 비밀번호의 일부 문자가 노출될 수 있습니다. 이는 사소한 보안 위험에 해당되며 비밀번호는 항상 마스크 처리되어야 합니다. 해결 방법 비밀번호를 고유 비밀번호 파일에 입력(Application Server 8.1 이후 일반적으로 권장되는 방법)하고 --adminpassword 또는 --dbpasswordfile 옵션과 함께 참조하십시오. |
이 절에서는 설치와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
||
---|---|---|---|
5009728 |
일부 Linux 시스템에서 "마침" 버튼을 누른 후 설치가 중단된 채 종료됩니다. 이 문제는 몇몇 Linux 시스템에서 발견되었습니다. Java Desktop System 2에서는 가장 일반적으로 나타나는 문제이지만 Linux RedHat 배포에서도 발견되었습니다. 설치 프로그램의 마지막 화면에서 "마침" 버튼을 누른 후 설치 프로그램에서 제품 정보 페이지나 제품 등록 페이지가 있는 브라우저 창을 시작하는 데 실패하고 명령 프롬프트를 반환하지 않은 채 중단됩니다. 해결 방법 설치 프로그램을 시작했던 단말기 창에서 Ctrl+C를 눌러 설치 프로그램을 종료합니다. 이렇게 하면 제품 정보 페이지나 등록 페이지가 있는 브라우저 창이 시작됩니다. 그러나 브라우저 창이 나타나지 않는 경우에는 브라우저를 시작하고 다음 URL을 입력하면 정보 페이지를 볼 수 있습니다.
제품을 등록하기 위해 설치 옵션을 선택한 경우에는 제품 정보 페이지에 있는 등록 페이지 링크를 따라 가십시오. |
||
6199697 |
설치 중 imq 디렉토리를 만들어야 합니다(Windows만 해당). Windows에서 Application Server Enterprise Edition을 설치한 직후 Message Queue 브로커가 시작되지 않고 drive:\as\domains\domain1\imq 디렉토리가 없다는 메시지가 표시됩니다. domain1을 시작한 후 브로커가 시작된 경우에는 디렉토리가 Application Server에 의해 만들어지기 때문에 문제가 발생하지 않습니다. 해결 방법
|
||
6297837 |
Application Server 설치 프로그램의 제품 이름에 잘못된 제품 릴리스 날짜("Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q4")가 표시됩니다. 해결 방법 올바른 제품 이름/날짜는 "Sun Java(TM) System Application Server Enterprise Edition 8.1 2005Q2"여야 합니다. |
||
6396045 |
Application Server는 NFS(네트워크 파일 시스템)을 지원하지 않습니다. 해결 방법 없음 |
Sun Java System Application Server Enterprise Edition 8.1 2005Q2에서 J2EE 1.4 Tutorial을 실행하려면 다음 작업을 수행합니다.
파일 예/common/build.properties를 “About this Tutorial” 장의 “About the Examples” 절에 설명된 대로 편집할 때 포트를 4848에서 4849로 변경합니다.
Deploytool 사용 시 예를 배포하기 전에 server localhost:4849를 추가합니다.
관리 콘솔을 사용하여 자원을 만들 때 대상 탭을 사용하여 서버를 대상으로 지정합니다. 명령줄 또는 asant 대상을 사용하는 경우에는 서버가 기본 대상이며 더 이상의 조치가 필요하지 않습니다.
이 절에서는 라이프사이클 관리와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
||
---|---|---|---|
6193449 |
ejb-timer-service 등록 정보 minimum-delivery-interval을 9000으로 설정한 후 ejb-timer-service 등록 정보 redelivery-interval-in-mills를 7000으로 설정하면 set 명령이 다음 오류로 인해 실패합니다.
문제는 재전달 간격 등록 정보를 최소 전달 등록 정보와 관련시키는 로직이 잘못되어 최소 전달 간격이 재전달 간격보다 큰 곳에서 GUI 또는 CLI를 사용하여 값을 설정하지 못한다는 것입니다. minimum-delivery-interval-in-millis는 항상 ejb-timer-service 등록 정보 redelivery-interval-in-millis와 같거나 그보다 크게 설정해야 합니다. 문제는 Application Server에서 redelivery-interval-in-millis 값이 minimum-delivery-interval-in-millis 값보다 크다고 잘못 검증하는 것입니다. 해결 방법 다음과 같이 등록 정보의 기본값을 사용합니다.
기본값 외의 값을 사용하면 오류가 발생합니다. |
이 절에서는 로깅과 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
|
---|---|---|
6180095 |
access,failure에 대한 디버그 문을 설정하면 Application Server 시작이 중단됩니다. JVM에 대해 java.security.debug 옵션을 설정하면 서버 인스턴스 시작이 교착 상태로 중단됩니다. 예를 들어 domain.xml에 다음과 같이 설정하면 이러한 문제가 발생합니다.
현재는 해결 방법이 없습니다. 이 플래그를 설정하는 것을 피하십시오. |
이 절에서는 Java 메시지 대기열과 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6173308, 6189645, 6198481, 6199510, 6208728 |
타이밍 종속인 특정한 경우 JMS 재연결이 성공적으로 완료되지 않습니다. 몇 가지 문제로 인해 타이밍 종속 시나리오에서 재연결에 실패할 수 있습니다. 해결 방법 다음과 같은 방법으로 이 문제를 해결할 수 있습니다.
|
6198465 |
비동기 message listener 동작이 appclient 8.0에서 8.1 Update 2로 변경됩니다. 최근 변경 작업으로 인해 비동기 message listener가 app-client 컨테이너의 유일한 활성 스레드일 때 남은 appclient VM은 데몬으로 존재합니다. 이러한 동작은 ACC에서 비동기 수신을 수행하는 과거 응용 프로그램에 대한 회귀입니다. 이 문제는 JMS message listener를 설정하고 주 스레드를 종료하는 응용 프로그램 클라이언트에 영향을 미칩니다. 해결 방법 주 스레드를 종료하지 마십시오. 주 스레드를 종료하기 전에 message listener에서 주 스레드에 알릴 때까지 기다립니다. |
이 절에서는 모니터링과 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
||||||
---|---|---|---|---|---|---|---|
6174518 |
일부 HTTP 서비스 모니터링 통계는 유용한 정보를 제공하지 않으며 무시해야 합니다. HTTP 서비스의 일부 요소에 대한 모니터링 통계를 보면 제시된 값이 현재 값과 일치하지 않거나 항상 0인 경우가 있습니다. 특히, 다음 HTTP 서비스 통계는 Application Server에 적용할 수 있는 정보를 제공하지 않으며 무시해야 합니다.
해결 방법 이러한 모니터는 이후의 릴리스에서 제거되고 더 적절한 정보로 대체될 예정입니다. |
||||||
6191092 |
배포되지 않은 EJB 모듈의 mbean에 대한 모니터링이 해당 모니터링 이름 하의 모든 통계가 이동되더라도 제거되지 않습니다. 예를 들면 다음과 같습니다.
이러한 현상은 EJB 모듈과 응용 프로그램에 공통적으로 나타납니다. 프로그램(MBean API) 및 asadmin list/get을 통해 비어 있는 모니터링인 MBean이 여전히 존재합니다. 진단
다음과 같은 통계를 볼 수 있습니다.
일단 배포를 해제합니다.
list 명령을 수행해도 여전히 응용 프로그램을 보게 됩니다.
그러나 모니터링 통계는 포함되어 있지 않습니다.
|
||||||
|
문자열로 시작하는 유효한 이름을 얻으려면 와일드카드('*') 문자를 사용합니다. 예를 들어 server로 시작하는 모든 모니터링 가능 항목의 이름 목록을 나열하려면 list "server.*"를 사용합니다. 해결 방법 이 문제는 해가 되지 않습니다. 모듈을 아무 문제 없이 안전하게 재배포할 수 있습니다. 루트 모니터링인 Mbean은 제거되지는 않지만 비어 있습니다. |
이 절에서는 PointBase와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6184797 |
응용 프로그램의 연결 풀에 격리 수준을 설정하면 PointBase에서 예외가 발생됩니다. PointBase 데이터베이스 설치를 가리키는 JDBC 연결 풀의 transaction-isolation-level 풀 속성을 기본값(Connection.TRANSACTION_READ_COMMITTED) 이외의 값으로 설정하면 예외가 발생합니다. 그러나, 동일한 매개 변수를 다른 데이터베이스를 가리키는 풀의 기본값이 아닌 값으로 설정하면 예외가 발생하지 않습니다. 해결 방법 PointBase 데이터베이스 설치를 가리키는 JDBC 연결 풀에 대해 transaction-isolation-level을 설정하려고 시도하지 마십시오. |
6204925 |
네트워크 서버와 내장 드라이버가 함께 사용되는 경우 PointBase에서 예외가 발생합니다. 네트워크 서버 드라이버와 내장 드라이버를 동시에 사용하면 번들로 제공된 PointBase에서 예외가 발생하는 경우가 있습니다. 해결 방법 내장 드라이버나 네트워크 서버 드라이버 중 하나를 사용하고 함께는 사용하지 않습니다. |
6264969, 6275448 |
기본 PointBase 데이터베이스를 덮어쓴 곳에 업그레이드 문제가 있습니다. Application Server Enterprise Edition 8.1 2005Q2 Update 2로 업그레이드하면 업데이트 릴리스 패치는 Pointbase 기본 데이터베이스를 덮어씁니다. 해결 방법 업그레이드 전에 있던 스키마 또는 데이터를 다시 만들거나 다시 입력합니다. 테이블 생성 옵션으로 CMP bean과 함께 응용 프로그램을 배포했으면 해당 응용 프로그램의 배포를 취소하거나 다시 배포하여 테이블을 다시 생성해야 합니다. |
이 절에서는 Application Server 8.1 제품에 포함된 샘플 코드와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
|||||
---|---|---|---|---|---|---|
6195092 |
setup-one-machine-cluster는 Windows에서는 중단되지만 Solaris에서는 작동합니다. mqfailover는 Ctrl+C를 눌러 취소한 다음 다시 실행해야 합니다. install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html에서 다음 명령을 실행합니다.
다른 Enterprise Edition 샘플에 대해 asant setup-one-machine-cluster-without-ha 또는 asant setup-one-machine-cluster-with-ha를 이미 실행한 경우에는 asant configure-mq를 실행하거나 asant setup-one-machine-cluster-and-configure-mq를 실행합니다. 이 경우 명령은 성공적으로 실행된 것처럼 보입니다.
그러나 그런 다음에 시스템이 중단됩니다. 해결 방법 현재는 해결 방법이 없습니다. 이 문제는 Windows에서 이 ant 대상을 사용하는 모든 Enterprise Edition 샘플에 비슷한 영향을 미칩니다. 해결 방법은 중단된 프로세스에서 벗어나 Ctrl+C를 눌러 중단된 프로세스를 끝낸 다음 다시 실행하는 것입니다. |
|||||
6198003 |
asadmin 배포 지침에 따라 MQ 페일오버 샘플 응용 프로그램을 실행하기 전에 JMS 자원을 만들어야 한다는 점이 설명서에 명시적으로 설명되어 있지 않습니다. 다음과 같은 오류가 발생합니다.
asadmin deploy 명령을 사용하여 수동 배포를 수행할 경우 JMS 자원을 직접 만들어야 한다는 점과 샘플 응용 프로그램 배포를 위해 제공된 ant 대상을 사용해야 한다는 점이 명시적으로 설명되어 있지 않습니다. 해결 방법 응용 프로그램을 실행하는 데 필요한 JMS 자원을 만드는 build.xml 스크립트에 asant 배포 대상을 사용합니다. |
|||||
6198239 |
Linux에서 웹 서비스/보안 샘플에서 인증서를 만드는 중 런타임 오류가 표시됩니다. install_dir/samples/webservices/security 샘플(basicSSl)을 Linux에 배포할 때 인증서는 만들어지지 않고 다음과 유사한 오류가 발생합니다.
문제는 Linux 설치에서 NSS 라이브러리가 Solaris 설치와 다른 위치에 있다는 점입니다. Linux에서 배포할 때 LD_LIBRARY_PATH가 올바른 NSS 라이브러리를 가리키는지 확인해야 합니다. LD_LIBRARY_PATH를 사용자 환경 또는 install_dir/bin/asant 쉘 래퍼 스크립트에서 설정합니다. 해결 방법 다음 중 한 가지를 수행합니다.
|
이 절에서는 Application Server 및 웹 응용 프로그램 보안과 인증에 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
---|---|
6183318 |
WebServiceSecurity 응용 프로그램을 Enterprise Edition에서 J2SE 5.0과 함께 실행할 수 없습니다. WebServiceSecurity 응용 프로그램은 다음과 같은 이유 때문에 J2SE 5.0과 함께 실행할 수 없습니다.
J2SE 팀에서는 이 버그를 "CR 6190389: Add support for the RSA-PKCS1 and RSA-OAEP wrap/unwrap mechanisms"로 보고했습니다. 해결 방법 J2SE 1.4.2를 기본적으로 포함된 공급자가 아닌 다른 JCE 공급자와 함께 사용합니다. 하드웨어 가속기는 이 구성에 포함되지 않습니다. |
6269102 |
SSL 종료가 작동하지 않습니다. 로드 균형 조정기(하드웨어)가 SSL 종료에 맞게 구성되었다면 Application Server는 리디렉션 동안 프로토콜을 https 에서 http로 변경합니다. 해결 방법 하드웨어 로드 균형 조정기와 Application Server 사이에 소프트웨어 로드 균형 조정기를 추가합니다. |
이 절에서는 업그레이드 유틸리티와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
||
---|---|---|---|
6165528 |
install_dir /domains 디렉토리가 아닌 사용자 정의 경로에서 생성된 도메인은 Application Server Enterprise Edition 8에서 Application Server Enterprise Edition 8.1로 업그레이드되는 동안 직접 업그레이드되지 않습니다. 업그레이드 유틸리티를 실행하고 install_dir을 소스 설치 디렉토리로 식별하면 install_dir/domains 디렉토리에 생성되는 도메인만 업그레이드됩니다. 다른 위치에 생성된 도메인은 업그레이드되지 않습니다. 해결 방법 업그레이드 프로세스를 시작하기 전에 모든 도메인 디렉토리를 다른 위치에서 install_dir/domains 디렉토리로 복사합니다. |
||
6207337 |
"현재 위치에서 업그레이드"를 실행하는 설치 프로그램에서 "업그레이드 마법사 시작" 버튼을 누른 후 일부 Linux 시스템에서 업그레이드 도구를 시작하는 데 실패합니다. 이 문제는 몇몇 Linux 시스템에서 발견되었으며 Java Desktop System 2에서 가장 일반적으로 나타나지만 RedHat 배포에서도 볼 수 있습니다. 설치 프로그램 화면의 "업그레이드 도구 시작" 버튼을 누른 후 설치 프로그램에서 업그레이드 도구를 시작하여 업그레이드 프로세스를 완료하는 데 실패하고 명령 프롬프트가 반환되지 않은 채 중단됩니다. 해결 방법 이 문제는 명령줄 설치 모드를 사용하여 현재 위치에서 업그레이드를 실행하는 경우에는 발생하지 않습니다.
제품을 등록하기 위해 설치 옵션을 선택한 경우에는 제품 정보 페이지에 있는 등록 페이지 링크를 따라 가십시오. |
||
6296105 |
자체 서명된 인증서는 8.0 Platform Edition(PE)에서 8.1 Enterprise Edition(EE) UR2로 업그레이드 하는 도중 및 후에는 신뢰할 수 없습니다. 해결 방법 (업그레이드 후) 대상 domain.xml에서 다음 항목을 제거하고 서버를 다시 시작합니다. <jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options> |
이 절에서는 웹 컨테이너와 관련된 알려진 문제점과 해결 방법을 설명합니다.
버그 ID |
요약 |
|||
---|---|---|---|---|
5004315 |
--precompilejsp=true를 사용하여 응용 프로그램을 배포하면 응용 프로그램에서 JAR 파일이 잠길 수 있습니다. 이렇게 되면 나중에 배포를 해제하거나 재배포할 때 실패하는 원인이 됩니다(Windows만 해당). Windows에서 응용 프로그램을 배포할 때 JSP의 사전 컴파일을 요청하고 나중에 해당 응용 프로그램의 배포를 해제하거나 해당 응용 프로그램(또는 동일한 모듈 아이디를 가진 응용 프로그램)을 재배포하려고 시도하면 예상한 것처럼 작동하지 않습니다. 문제는 JSP 사전 컴파일을 수행하면 응용 프로그램의 JAR 파일을 열지만 닫지 않고 Windows에서는 배포 해제 시 그러한 파일을 삭제하지 못하거나 재배포 시 덮어쓰지 못합니다. 배포 해제는 응용 프로그램이 Application Server에서 논리적으로 제거된다는 점에서 어느 정도는 성공한 것으로 볼 수 있습니다. 또한 asadmin 유틸리티는 오류 메시지를 반환하지 않지만 응용 프로그램의 디렉토리와 잠긴 jar 파일은 서버에 남아 있습니다. 서버의 로그 파일에는 파일 및 응용 프로그램 디렉토리를 삭제하는 데 실패한 것을 설명하는 메시지가 포함됩니다. 배포 해제에 실패한 후 응용 프로그램을 재배포하려는 시도는 서버에서 기존 파일과 디렉토리를 제거하려고 하기 때문에 역시 실패하게 됩니다. 이러한 문제는 원래 배포한 응용 프로그램과 동일한 모듈 아이디를 사용하는 응용 프로그램을 배포하려고 시도하면 서버가 응용 프로그램 파일을 저장할 디렉토리 이름을 선택할 때 모듈 아이디를 사용하기 때문에 발생할 수 있습니다. 먼저 응용 프로그램의 배포를 해제하지 않고 재배포하려고 시도하는 경우도 같은 이유 때문에 실패합니다. 진단 응용 프로그램의 배포를 해제한 후 재배포하려고 시도하면 asadmin 유틸리티는 아래와 유사한 오류를 반환합니다.
해결 방법 응용 프로그램을 배포할 때 --precompilejsps=false(기본 설정)를 지정한 경우에는 이 문제가 발생하지 않습니다. 응용 프로그램을 처음 사용하면 JSP 컴파일이 트리거되어 첫 번째 요청에 대한 응답 시간은 이후의 요청에 대한 응답 시간보다 더 깁니다. 사전 컴파일을 수행하면 응용 프로그램을 배포 해제 또는 재배포하기 전에 서버를 중단하고 다시 시작해야 합니다. 서버를 종료하면 잠긴 JAR 파일의 잠금이 해제되어 재시작한 후 배포 해제 또는 재배포를 성공적으로 수행할 수 있습니다. |
|||
6172006 |
WAR을 빈 <load-on-startup> 요소가 있는 Servlet 2.4 기반 web.xml과 함께 배포할 수 없습니다. web.xml에서 선택 요소인 load-on-startup 서블릿 요소는 연관된 서블릿이 선언된 웹 응용 프로그램 시작의 일부로 로드되고 초기화된다는 것을 나타냅니다. 이 요소의 옵션 부분은 서블릿이 웹 응용 프로그램의 다른 서블릿과 관련하여 로드되고 초기화되는 순서를 나타내는 정수입니다. <load-on-startup> 요소가 비어 있으면 서블릿이 웹 응용 프로그램을 포함하는 시작 중에 로드되고 초기화되는 한 순서는 상관이 없음을 의미합니다. web.xml을 위한 Servlet 2.4 스키마는 더 이상 빈 <load-on- startup>을 지원하지 않습니다. 즉, Servlet 2.4 기반 web.xml을 사용할 때 정수를 지정해야 합니다. <load-on-startup>과 같이 빈 <load-on-startup/>을 지정하면 web.xml은 web.xml을 위한 Servlet 2.4 스키마에 대한 검증에 실패하며 이로 인해 웹 응용 프로그램 배포에 실패하게 됩니다. 역호환성 문제로 빈 <load-on-startup>을 지정해도 Servlet 2.3 기반의 web.xml과는 아무 문제 없이 작동합니다. 해결 방법 Servlet 2.4 기반 web.xml을 사용하여 서블릿 로드 순서가 중요하지 않다는 것을 나타낼 때 <load-on-startup>0</load-on-startup>을 지정합니다. |
|||
6184122 |
자원이 제한된 서버에서 JSP 페이지를 컴파일할 수 없습니다. JSP 페이지에 액세스하지만 컴파일에 실패하고 서버 로그에는 다음과 같은 스택 추적과 함께 "Unable to execute command"라는 오류 메시지가 포함됩니다.
해결 방법 JSP 컴파일 스위치인 "fork"를 "false"로 설정합니다. 이 작업은 다음 중 한 가지 방법으로 수행할 수 있습니다.
어떤 방법으로 설정하든 ant에서 javac 컴파일을 위한 새로운 프로세스를 생성하지 못하도록 합니다. |
|||
6188932 |
Application Server는 auth-passthrough Web Server 6.1 Add-On을 지원하지 않습니다. Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2는 Sun Java System Application Server Enterprise Edition 7.1.과 함께 사용할 수 있는 auth-passthrough 플러그인 함수에서 제공하는 기능에 대한 지원을 추가합니다. 그러나 Application Server Enterprise Edition 8.1 2005Q2 Update 2에서 auth-passthrough 플러그인 기능은 다르게 구성됩니다. Application Server Enterprise Edition 7.1에서 auth-passthrough 플러그인 함수는 2계층 배포 시나리오에서 사용할 수 있었습니다. 여기서,
이러한 네트워크 아키텍처에서 클라이언트는 프런트엔드 웹 서버에 연결됩니다. 이 웹 서버는 service-passthrough 플러그인 함수로 구성되어 있으며 프록시를 거친 Application Server 인스턴스에 처리하도록 HTTP 요청을 전달합니다. Application Server 인스턴스는 웹 서버 프록시의 요청만을 받을 수 있는데 클라이언트 호스트로부터는 직접 받지 못합니다. 결과적으로, 클라이언트의 IP 주소 같은 클라이언트 정보를 쿼리하는 프록시를 거친 Application Server 인스턴스에 배포된 응용 프로그램은 프록시 호스트 IP를 받습니다. 이것이 전달된 요청의 실질적인 보낸 호스트이기 때문입니다. Application Server Enterprise Edition 7.1에서는, 프록시를 거친 Application Server 인스턴스가 service-passthrough 플러그인이 실행되고 있는 중간 웹 서버를 통하지 않고 직접 요청을 받은 것처럼 프록시를 거친 Application Server 인스턴스에 배포된 모든 응용 프로그램에서 원격 클라이언트 정보를 직접 사용할 수 있도록 해당 인스턴스에서 auth-passthrough 플러그인 함수를 구성할 수 있습니다. Application Server Enterprise Edition 8.1 2005Q2 Update 2에서 auth-passthrough 기능은 다음과 같이 domain.xml의 <http-service> 요소의 authPassthroughEnabled 등록 정보를 TRUE로 설정하여 사용할 수 있습니다.
|
|||
|
Application Server Enterprise Edition 7.1에서 auth-passthrough 플러그인의 동일한 보안 고려사항은 Application Server Enterprise Edition 8.1 2005Q2 Update 2의 authPassthroughEnabled 등록 정보에도 적용됩니다. authPassthroughEnabled를 사용하면 인증 목적으로 사용될 수 있는 정보(예: 요청을 보낸 측의 IP 주소 또는 SSL 클라이언트 인증서)를 무시할 수 있기 때문에 authPassthroughEnabled를 TRUE로 설정하여 Application Server Enterprise Edition 8.1 2005Q2 Update 2 인스턴스에 신뢰할 수 있는 클라이언트나 서버만 연결할 수 있어야 합니다. 더욱 주의하는 의미에서 회사 방화벽 뒤의 서버에서만 authPassthroughEnabled를 TRUE로 설정하여 구성하는 것이 좋습니다. 인터넷을 통해 액세스할 수 있는 서버는 authPassthroughEnabled를 TRUE로 설정하여 구성해서는 안 됩니다. 프록시 웹 서버가 service-passthrough 플러그인으로 구성되어 있고 authPassthroughEnabled가 TRUE로 설정된 Application Server 8.1 Update 2 인스턴스에 요청을 전달하는 시나리오에서 SSL 클라이언트 인증은 웹 서버 프록시에서 활성화될 수 있으며 프록시를 거친 Application Server 8.1 Update 2 인스턴스에서는 비활성화됩니다. 이 경우 프록시를 거친 Application Server 8.1 Update 2 인스턴스는 마치 SSL을 통해 인증된 것처럼 요청을 취급하고 클라이언트의 SSL 인증서를 요청하는 배포된 응용 프로그램에 해당 인증서를 제공합니다. |