'분류 전체보기'에 해당되는 글 418건

  1. 2009.07.15 다른 도메인간 부모창과 자식창 제어
  2. 2009.07.13 고미영 사망
  3. 2009.07.13 이요원, 대상포진에도 강행군 "軍 생활 같아" 4
  4. 2009.06.25 조성민 심경고백, 故 최진실 죽음에 자살까지 생각
  5. 2009.06.25 아웃백 축텐더샐러드 따라잡기!
  6. 2009.06.25 [MySQL] Replication 환경 싱크 깨지는것 회피하기
  7. 2009.06.19 XSS(Cross Site Scripting: 크로스 사이트 스크립팅) == CSS
  8. 2009.06.11 mysql show status
  9. 2009.06.04 HTTP 에러코드와 상태 코드 정리
  10. 2009.06.02 JBoss DataSource 설정
2009. 7. 15. 19:58

다른 도메인간 부모창과 자식창 제어





익스플로러 5.5(?) 이후 부터는 스크립트로 server1.abc.com 과 live.abc.com 간의 상호 도메인이 다른 프레임이나 윈도우의 document에 관련된 작업을 시도하면 보안에러가 발생한다.

Cross-Frame Scripting 에 대한 MS의 말..
http://msdn2.microsoft.com/en-us/library/ms533028.aspx

넷스케이프 같은 경우에는 스크립트(Signed scripts)에서 브라우져자체에 포함(?)된 클래스(netscape.security.PrivilegeManager)를 호출하여 이를 해결할 수 있다고 한다.

Signed Scripts 에 대한 Mozilla의 말..
http://www.mozilla.org/projects/security/components/signed-scripts.html

그럼에도 불구하고 다른 도메인에 대한 opener 나 parent 접근이 필요할 경우에는 JavaScript 를 통해 document.domain 을 설정해 주면된다.
<script language="javascript">
    document.domain = "공통도메인명";
</script>
상호 연결 시켜야 하는 웹 페이지에 자신들의 공통된 도메인을 지정해 주면 컨트롤이 가능해진다.

만약, server1.abc.com의 open.htm이 window.open 으로 live.abc.com을 호출하고 live.abe.com 의 child.htm이 opener 로 server1.abc.com 을 접근해야 한다면
다음 스크립트를 두 페이지에 정의해 주면 되고, 스크립트는 페이지 어디에 위치해 있든지 특별한 상관은 없다.

<script language="javascript">
    document.domain = "abc.com";
</script>

※ 주의, 도메인 명을 잘못 입력한 경우에는 "잘못된 인수입니다." 라는 JavaScript 오류가 발생한다.

=========================================================================================
cross frame scripting 을 해결하는 다른 방법으로는 HTA가 있다.
html페이지가 아닌 hta(html application)페이지를 만들어야 한다.

http://msdn.microsoft.com/workshop/author/hta/hta_node_entry.asp

※ 다음은 HTA에서 javascript로 iframe의 document를 참조한 예

확장자를 hta로 저장하시고 브라우저로 실행.

<html>
<head>
  <title>hta cross scripting</title>
  <script>
    function window.onload() {
       alert(myframe.document);
    }
  </script>
</head>
<body scroll="no">
  <iframe id=myframe src="http://kin.naver.com/"></iframe>
</body>
</html>

다음에, 예를 하나 들면..
kin.naver.com을 iframe에 넣고 검색어에 "스크립트"라는 단어를 넣은 후 검색버튼을 누르게 한 HTA소스이다.

<html>
<head>
  <title>hta cross scripting</title>
  <script>
    function window.onload() {
       myframe.document.search.query.value="스크립트";
       myframe.check_query();
    }
  </script>
</head>
<body scroll="no">
  <iframe id=myframe src="http://kin.naver.com/" width=100% height=100%></iframe>
</body>
</html>


2009. 7. 13. 09:52

고미영 사망







여성으로서 세계 최초 14좌 등반이라는 기록과
오은선 대장과의 경쟁이 화를 부르지 않았나 생각해본다.
(특히 블랙야크와 코오롱스포츠의 경쟁)

기록은 프로에게 매우 중요하고, 영원하기때문에 무시할 수 없지만...
안전보다 우선할 수 없는 것인데...
날씨도 안좋은데..오은선 대장과의 경쟁이 붙으면서 더욱 힘든 등반이 되지 않았을까...

이젠 편히 영면 하시길...
2009. 7. 13. 09:50

이요원, 대상포진에도 강행군 "軍 생활 같아"





배우 이요원이 드라마 '선덕여왕'에서의 열연으로 몸살을 앓고 있다.
MBC 인기 드라마 '선덕여왕'의 타이틀롤을 맡고 있는 이요원은 최근 대상 포진 진단을 받는가 하면 온몸에 상처가 없어질 날이 없을 정도로 강도 높은 촬영에 임하고 있다.
행군, 포복, 진흙 구덩이에 빠지기 등 군대 훈련 종합세트 같은 촬영현장에 이요원은 쉬는 시간이면 초콜릿 종류의 단 것을 찾게 된다고. 군인들의 야외 훈련장같은 환경 속에서 남자 연기자들 틈바구니에서 처절하게 촬영 중이다.



경주-문경-철원-용인-안면도 등 전국을 도는 촬영 일정에 한달 동안 집에 두번 밖에 가지 못했을 정도. 씻지도 못한 채 갑옷을 입고 진흙탕 속에서 전쟁 신을 찍다 대상포진에 걸려 피부 발진으로 고통을 호소하고 있다.
덕만의 젊은 시절 고생을 온몸으로 체험 중인 이요원은 "몸이 고단해도 덕만이 젊은 날 이같은 시련을 통해서 여왕으로 거듭나는 것이 시청자들에게 잘 전달된다면 충분히 할만하다. 실제로 내가 겪는 고생이 결국 시청자들에게는 리얼리티를 살려줄 것"이라고 소감을 밝혔다.
연기 생활 12년을 모두 합친 것보다 더 심한 고생을 하고 있다는 이요원은 "평소 나의 씩씩한 모습을 자연스럽게 보여줄 수 있는 가장 자연스러운 연기 모습이 아마도 덕만일 것"이라며 "지인들이 실제 너 같다고 말한다"고 말했다.
미실과의 본격 대결을 상상하면 벌써부터 흥분된다는 이요원의 열연이 돋보이는 '선덕여왕'은 오는 13일과 14일 방영된다.

출처 : Tong - ♡高句麗渤海♡님의 ♡MBCDRAMA♡통

2009. 6. 25. 09:23

조성민 심경고백, 故 최진실 죽음에 자살까지 생각







 

조성민이 전 부인이자 이제는 고인이 된 탤런트 최진실에 대해 방송에서 처음으로 입을 열었다.

조성민은 25일 방송될 SBS ‘배기완 최영아 조형기의 좋은아침’녹화에서 최진실 죽음 이후, 그녀와 아이들에 관해 조심스럽게 입을 열었다.

“그녀(최진실)의 죽음이 가져 온 엄청난 충격으로 한때 자살까지 생각했다”고 털어놓은 조성민은 최진실 관련 질문에 한동안 말을 잊지 못했다. 또 알려진 것과는 달리 “아이들과 일주일에 한번 집에서 만나는 게 아니라 강남의 모 교회에서 만남을 갖는다. 종종 아이들과 야구를 하며 시간을 보낸다”고 말했다.

조성민은 현재 사회인야구단 훈련을 맡으며 야구관련 사업을 시작했다. “여전히 야구관련 일에 종사할 때 가장 편안하다”고 고백했다. 오는 8월 3일부터 8일까지는 남해에서 유소년 야구캠프도 열 예정이다.

조성민의 솔직한 심경고백은 25일 오전 방송되는 SBS ‘배기완 최영아 조형기의 좋은아침’ 에서 공개될 예정이다.

----------

진실언니가 조성민만 안만났어도 자살까진 안했을듯 남편한테 배신당하고 상처받고 그때부터 우울증생기고 우울증 심해져서... 뭐 이제와서 아무소용없는 말이지만

2009. 6. 25. 01:01

아웃백 축텐더샐러드 따라잡기!





 

 

 

훼밀리 레스토랑에서 꽤 비싼 가격에 팔고 있는 축텐더 샐러드를 집에서 쉽게 만들어보아요.^^

 

생각보다 만드는 방법이 어렵지 않아요.^^특별한 기념일이나 아이들 파티,서양식 상차림에

올려도 좋구요.한끼 식사로도 든든해요.^^

 

자아.그러면 같이 만들어보아요.참고로 ()안의 숫자는 밥수저의 양이예요.

 

 

 

재료: 닭가슴살 1쪽, 샐러드 야채(양상치, 양배추, 비타민, 치커리 등 각각 한줌씩),

방울 토마토 3개

 

밑간 양념: 맛술(2), 소금(0.5),후춧가루 약간, 레몬즙(1)밥숟가락, 튀김기름

 

튀김옷:밀가루 or 튀김가루 반컵, 빵가루 반컵,달걀 1개

 

허니머스터드 드레싱: 마요네즈(5),꿀(2.5),머스터드소스(1.5),레몬즙(0.5)

 

 

 

 

 

 

닭가슴살 1쪽 준비해 가위로 잘게 잘라준 후  맛술(2), 소금(0.5),후춧가루 약간, 레몬즙(1)밥숟가락

넣어 밑간한 후 30분 정도 냉장고에 두세요.

 

참고로 맛술은 미림이나 청주를 사용하시면 되요.

 

 

 

 

 

 

샐러드 야채(양상치, 양배추, 비타민, 치커리 등 샐러드 야채 각각 한줌씩) 준비해 손질한 후

깨끗하게 씻어서 물기를 제거해주세요.샐러드 야채면 어떤 것이든 가능해요.

 

방울 토마토 3개는 칼로 반 잘라 준비해주세요.

 

 

 

 

 

식빵 3개는 커터기에 곱게 갈아 빵가루를 만들어주세요.

 

시중에서 파는 빵가루를 이용해도 되지만 직접 빵가루를 만들어서 튀기면 훨씬 더 맛있는 튀김을

만들 수 있어요.

 

 

 

 

 

 

밀가루 or 튀김가루 반컵, 빵가루 반컵, 풀어 놓은 달걀 1개 준비해주세요.

 

닭을 밀가루-계란-빵가루 순으로 튀김옷을 입혀주세요.

 

밀-계-빵 으로 외워두면 튀김옷을 만드는 순서를 잊어버리지 않아요.참고하세요.^^

 

 

 

 

 

튀김기름을 준비하고 빵가루를 떨어뜨려 밑으로 가라앉았다가 퐁하고 올라오면 그때 닭을 넣어서 노릇노릇

하게 튀겨주세요.

 

더 바삭한 튀김을 원하는 경우 한번 튀긴 후 건지고 기름을 식힌 다음에 다시 한번 튀겨주시면 되요.

 

 

 

 

 

 

키친 타올 위에 튀긴 닭을 올려 기름을 흡수시켜주세요.그래야 바삭바삭한 튀김을 먹을 수 있어요.

 

 

 

 

 

 

마요네즈(5),꿀(2.5),머스터드소스(1.5),레몬즙(0.5)넣어 허니머스터드소스를 만들어주세요.

 

 

 

 

 

 

 

접시에 샐러드 야채,튀긴 닭 순으로 올리고 허니머스터드 소스를 뿌려주면 완성.

 

 

 

.

 

 

 

 

 

 

 

 

완성되었어요.^^

 

가늘게 썬 치즈를 같이 곁들어서 먹어도 좋아요.^^

 

세희의 쉬운 요리는 계속됩니다.늘 평안하고 행복하세요.^^

2009. 6. 25. 00:51

[MySQL] Replication 환경 싱크 깨지는것 회피하기





MySQL의 리플리케이션 환경을 운영하다 보면 유난히도 싱크가 어긋나는 일이 많이 일어나는 것을 알 수 있습니다.

확실히 MySQL은 아직 엔터프라이즈 환경에서의 도입에 무리가 있는 제품이 아닐까 생각이 드는군요.

하지만 리플리케이션 기능이 추가된지 얼마 되지 않았고 저장프로시저도 생겼고 나날이 발전하는 모습을 보면 더더욱 좋아질것이라고 기대해 봅니다.

그러면 이미 MySQL을 이용한 리플리케이션 상황을 운영중이고 또 관련 오류가 많이 나는 상황이라면 어떻게 해야 할까요?

다음의 방법을 시도해볼만합니다.

MySQL의 경우 리플리케이션 환경 중 에러가 나면 그 Slave 서버는 리플리케이션이 중단됩니다.

갑자기 좀비 서버가 되어 버리는 것이죠. 에러를 확인해 봅시다.

[root@SLAVE ~]# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2060
Server version: 5.0.51

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: MASTER
                Master_User: replicator
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000005
        Read_Master_Log_Pos: 96305365
             Relay_Log_File: slave-relay-bin.000006
              Relay_Log_Pos: 73184178
      Relay_Master_Log_File: mysql-bin.000005
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
            Replicate_Do_DB: THEEYE
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 1062
                 Last_Error: Error 'Duplicate entry '116069-10002826' for key 1' on query. Default database: 'THEEYE'. Query: 'INSERT INTO    THEEYE_INFO_LOG    ( IDX, NAME, REG_DATE    )    VALUES ( 3, "GOOD", NOW() )'
               Skip_Counter: 0
        Exec_Master_Log_Pos: 73184876
            Relay_Log_Space: 96304951
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

mysql> exit



show slave status\G 명령으로 현재 슬레이브의 상태를 확인할 수 있습니다.

상태를 보니 Last_Errno 가 1062이고 Last_Error에는 어떤 에러인지 표시가 됩니다.

근데 에러를 확인해 보니 같은 똑같은 Entry가 존재한다는군요. 위의 디비 설계상 같은 키값을 가진 값이 두개가 들어갈 필요가 없다는것을 알았습니다.

그런데 저런 사소한 문제로 리플리케이션이 중단된다는것도 억울한 일이죠. 위와 같은 사소한 에러는 무시하도록 해보겠습니다.

--slave-skip-errors 라는 옵션이 있는데요. 에러코드값을 지정해 주거나 all로 모든 에러를 무시할 수 있습니다.
--slave-skip-errors=[err_code1,err_code2,...|all]


서버측 에러 코드는 [ 이곳 ] 에서 확인 하실 수 있습니다.

1062번 에러의 경우 사소한 문제이기 때문에 서버 설정에 추가해 보도록 하겠습니다.

저같은 경우에는 /etc/my.cnf 파일에 다음의 내용을 추가하였습니다.
[mysqld]
...
slave-skip-errors = 1062


앞으로는 위의 코드에 해당하는 에러가 발생할 경우 에러를 건너뛰고 Master의 Log Position에 강제적으로 맞춰질 것입니다.
2009. 6. 19. 11:13

XSS(Cross Site Scripting: 크로스 사이트 스크립팅) == CSS





IE 8 ㅡㅡ;; "교차"라는 말도 맞긴 하지만, 은근히  애매한듯...

 

자, 이제 크로스사이트 스크립팅(XSS)에 관하여 정리해보자.

 

날도 뻐근하고, 봄이면.. 잠만 퍼질러 자는 체질이라.. 너무 놀았네..

 

XSS사이트 스크립트의 일반적인 공식에 대해서 알아보겠다..

 

웹 사이트를 들어가보게 되면, 기본적인 게시판, 메일등 사용자가 직접 올릴수 있는 부분이 한개씩은 있기 마련이다.

위의 그림이 XSS의 기본적인 그림을 그린것이다.

 

1. 공격자는 서버에게 타겟(불특정 다수)이 읽을수 있도록, 내용과 악성 스크립트를 포함시킨 코드를 올리게 된다.

 

2. 타겟은 글을 읽음으로서, 공격자에게 자신이 의도치 않은 쿠키값을 전송하게 된다.

 

3. 쿠키 정보를 수집한 공격자는 타겟의 계정과 동일하게 모든 권한을 가지게 된다.

 

[ 쿠키(Cookie) ]

 

 

- 사용자가 어떠한 웹서버의 접속을 요청하게 되면, 로컬 시스템은 쿠키값을 참조하여 접속하게 된다.

   

   기존의 사이트 쿠키값이 없을 경우, 웹 서버에 접속하게 되면 자신의 시스템에 4kbyte이하의 쿠키값이 생성한다.

  

   쿠키값은 사용자의 브라우저의 정보를 쿠키값에 지정하게 되며, Windows_Server에서의 경로를 표시하였다.

 

각각의 포함된 쿠키값은 Web_Server별로 정리되어져 있으며, 사용자 ID와 접속 서버로 이루어져 있다.

 

일반적으로 확인하게 되면, Domain Name Server / 구분 ID(숫자) / 쿠키만기일 등의 구조로 이루어질 것이다.

 

그렇다면?? 왜 쿠키값이 위험한 것일까??

 

쿠키는 일반적으로 위의 정보를 제외한, 접속자의 개인 정보까지 포함되어 있어 취약점으로 발전해온 것이다.

 

내가 만약 네이버에 접속하였을 경우, 그에 대한 ID와 PW는 쿠키값이 포함되어져 있다.

 

네이버에 처음 접속하였다고 하자. 그렇다면 네이버 서버에 접속하게 되면, 4kbyte이하의 쿠키값이 접속 호스트에 저장이 될것이며,

 

그에 대한 쿠키값은 다음 접속시 접속할 서버는 쿠키값을 가지고, 파악하게 된다.

 

쿠키값은 접속 종료시 즉각, 정보가 사라지는 것이 아니다.

 

간혹가다 사이트 계정으로 접속하여, 브라우저를 끄고, 다시 접속해보면 기존의 ID계정으로 접속해있는 것을 보았을 것이다.

 

[ 쿠키(Cookie)의 중요성 ]

 

1. 사용자의 계정 정보

 

2. 자주 방문하는 서버의 정보

 

3. 장바구니 시스템(물건 구매시 쿠키값에 남는 현상)

    위와 같은 것들이 일반적인 쿠키의 적용 방식이다.

 

[ XSS 공격 특성 ]

- 기본적인 설명은 위에서 하였으므로, XSS에 대해서 더욱더 들어가보자.

 

[ 공격 순서 ]

1. 게시판과 같은 응용 프로그램에 스크립트 작성 언어를 올려놓게 된다.(불특정 다수)

 


2. 파일 열람시 타겟은 자신도 모르게 쿠키값을 가로 채이게 된다.

 

3. 일반적으로, 공격자는 파로스와 같은 툴로서 쿠키값을 확인하게 된다.



 

4. 쿠키값을 이용하여, 계정 도용이 가능하다

 

[ 방어 대책 ]

1. 쿠키 값에 중요한 정보는 응용 프로그램 관리자가 포함되지 않도록 설정.

 

2. 사용자의 입력 값에대한 필터링

    <script></script> / <javascript> / document.cookie

 

3. HTML 태그의 미활성화(동적 웹 특성에 대한 HTML활성화.)

 

4. 스크립트 언어(ASP,PHP,JAVA등)의 문구를 다른 코드로 대체, 혹은 필터링

 

5. 가장 중요한 것은 관리자의 지속적인 점검

2009. 6. 11. 14:55

mysql show status




mysql 에 접속후  mysql> show status; 로도 볼수 있습니다.

 

설명:
Aborted_clients : 클라이언트가 연결을 적절히 닫지않아서 죽었기때문에 끊어진 연결수.
Aborted_connects : 연결실패된 mysql서버에 연결시도 수.
Bytes_received : 모든 클라이언트로 부터 받은 바이트 수
Bytes_sent : 모든 클라이언트에게 보낸 바이트수
Connections : mysql서버에 연결시도한 수
Created_tmp_disk_tables : sql문을 실행하는 동안 생성된 디스크에 존재하는 임시테이블 수
Created_tmp_tables : sql문을 실행하는 동안 생성된 메모리에 존재하는 임시테이블 수
Created_tmp_files : 얼마나 많은 임시파일을 mysqld가 생성했는가
Delayed_insert_threads : 사용중인 insert handler threads가 지연되고 있는 수
Delayed_writes : INSERT DELAYED로 쓰여진 rows수
Delayed_errors : 어떤 에러(duplicate key로인한 때문에 INSERT DELAYED로 쓰여진 rows수
Flush_commands : 초과 flush명령수
Handler_delete : 테이블로 부터 지워진 rows수
Handler_read_first : 인덱스로 부터 읽혀진 처음 entry수. 이것이 높으면 서버는 많은 full
                         index scans를 하고 있다는 것을 의미. 예를 들어 SELECT col1 FROM
                         foo는 col1은 인덱스되었다는 것을 추정.
Handler_read_key : 키가 존재하는 row를 읽는 요청수. 이것이 높으면 당신의 쿼리와 테이블
                        이 적절히 인덱스화되었다는 좋은 지적이 된다.
Handler_read_next : 키순서대로 다음 row를 읽는 요청수. 이것은 만약 range constraint와 
                         함께 인덱스컬럼을 쿼리할 경우 높아질 것이다. 이것은 또한 인덱스 스캔
                        하면 높아질 것이다.
Handler_read_rnd : 고정된 위치에 존재하는 row를 읽는 요청수. 이것은 결과를 정렬하기를
                           요하는 많은 쿼리를 한다면 높아질 것이다.
Handler_read_rnd_next : 데이타파일에서 다음 row를 읽기를 요청수. 이것은 많은 테이블 스
                            캔을 하면 높아질 것이다.
Handler_update : Number of requests to update a row in a table.
                       한테이블에 한 row를 업데이트를 요청하는 수
Handler_write :  한테이블에 한 row를 insert요청하는 수
Key_blocks_used :  key 캐시에서 블럭을 사용하는 수
Key_read_requests : 캐시에서 키블럭을 읽기를 요청하는 수
Key_reads : 디스크로부터 키블럭을 물리적으로 읽는 수
Key_write_requests : 캐시에서 키블럭을 쓰기위해 요청하는 수
Key_writes :  디스크에 키블럭을 물리적으로 쓰는 수
Max_used_connections : 동시사용 연결 최대수
Not_flushed_key_blocks : 키캐시에서 키블럭이 바뀌지만 디스크에는 아직 flush되지 않는다.
Not_flushed_delayed_rows :  INSERT DELAY queue에서 쓰여지기를 기다리는 row수
Open_tables : 현재 오픈된 테이블수
Open_files : 현재 오픈된 파일수
Open_streams : 주로 logging에 사용되는 현재 오픈된 stream수
Opened_tables : 지금까지 오픈된 테이블 수
Select_full_join : 키없이 조인된 수(0이 되어야만 한다)
Select_full_range_join : reference table에서 range search를 사용한 조인수
Select_range : 첫번째 테이블에 range를 사용했던 조인수. 보통 이것이 크더라도 위험하진 않다.
Select_scan : 첫번째 테이블을 스캔했던 조인수
Select_range_check : 각 row후에 key usage를 체크한 키없이 조인한 수(0이어야만 한다)
Questions : 서버에서 보낸 쿼리수
Slave_open_temp_tables : 현재 slave thread에 의해 오픈된 임시 테이블 수
Slow_launch_threads : 연결된 slow_launch_time보다 더 많은 수를 갖는 쓰레드수
Slow_queries : long_query_time보다 더 많은 시간이 걸리는 쿼리 수. Slow Query Log참고
Sort_merge_passes : 정렬해야만 하는 merge수.
                           이 값이 크면 sort_buffer를 증가하는것에 대해 고려해야 한다.
Sort_range : Number of sorts that where done with ranges.
Sort_rows : 정렬된 row수
Sort_scan : 테이블 스캔에 의해 행해진 정렬수
Table_locks_immediate : 즉시 획득된 테이블 lock 시간 (3.23.33부터 추가된 항목)
Table_locks_waited : 즉시 획득되지 않고 기다림이 필요한 테이블 lock 시간. 이것이 높아지면 성능에 문제가 있으므로, 먼저 쿼리를 최적화 시키고, 테이블을 분산시키거나 복제를 사용해야 한다. (3.23.33부터 추가된 항목)
Threads_cached : 스레드 캐시에서 쓰레드 수
Threads_connected : 현재 오픈된 연결수
Threads_created : 연결을 다루기위해 생성된 쓰레드 수
Threads_running : sleeping하지 않는 쓰레드 수
Uptime : 서버가 스타트된 후로 지금까지의 시간

2009. 6. 4. 15:01

HTTP 에러코드와 상태 코드 정리





상태코드 메세지 설명
100 Continue
클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내 주시오.
101 Switching Protocols
서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임.
200 Ok
모든 것이 정상적임. GET이나 POST 요청 뒤에 문서가 온다. 이것은 서블릿의 기본 상태다. setStatus를 사용하지 않으면 이 상태코드를 얻게 된다.
201 Created
서버에서 문서를 만들었음. Location 헤더는 그 URL을 가리킨다.
202 Accepted
요청이 수행되었지만 처리는 끝나지 않았음.
203 Non-Authoritative Information
문서는 정상적으로 반환되었지만 복사본이 사용되었으므로 응답 헤더중 일부가 정확하지 않을 수 도 있음.
204 No Content
새 문서 없음. 브라우저는 이전 문서를 계속 보여줘야 한다. 이것은 사용자가 페이지를 주기적으로 리로드를 하던 중 이전 페이지가 이미 만료되었을 때 사용할 수 있다. 하지만 Refresh 응답 헤더나 같은 헤더를 사용 해서 페이지를 자동으로 리로드 시켰을 때는 동작하지 않는다. 왜냐하면 이 상태 코드를 반환하면 추후의 리로딩이 멈추기 때문이다. 하지 만 자바 스크립트로 리로드하게 해 주는 것은 작동한다.
205 Reset Content
새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 한다. 브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용 된다.
206 Partial Content
클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음.
300 Multiple Choices
요청된 문서가 여러 군데서 발견되었음. 이 때 서버는 해당하는 모든 문서들을 나열할 것이다. 만약 서버가 선호하는 선택이 있으면 Location 응답 헤더에 나열해야 한다.
301 Moved Permanently
요청된 문서는 어딘가에 있고 그 문서에 대한 URL은 Location 응답 헤더에 주어졌음. 브라우저는 자동적으로 새 URL의 링크를 따라가야 한다.
302 Found
301과 비슷하지만 새 URL은 임시 저장 장소로 해석된다. 이 메시지는 HTTP 1.0에서는 ‘Moved Temporarily'였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 SC_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동적으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메소드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader("Location", url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 (맨 마지막에 ‘/'이 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302 를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보세요.
303 See Other
301/302과 같지만 원래 요청이 POST였을 경우 리다이렉트 되는 문서(Location 헤더에 주어졌다) GET을 통해 받아야 한다.
304 Not Modified
클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨(보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우). 서버는 클라이언트에게 캐시에 저장된 이전 문서를 계속 사용해야 한다고 말할 것이다.
305 Use Proxy
요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함.
307 Temporary Redirect
Temporary Redirect 이것은 302 ("Found" 또는 "Temporarily Moved")와 같다. 많은 브라우저에서 메시지가POST일 때 원래는 303 응답의 POST 요청의 리다이렉션을 따라 가야 함에도 불구하고 302의 응답을 따르기 때문에 HTTP 1.1에서 추가되었다. 303 응답은 모호하지 않도록 의도되었다. 303 응답의 경우에 대해서는 리다이렉트 된 GET과 POST 요청을 따르고 307 응답의 경우에는 GET 요청만 따른다. 몇 가지 이유로 HttpServletResponse에는 이 상태코드에 해당하는 상수가 없다.
400 Bad Request
요청에 문법적으로 잘못된 부분이 있음.
401 Bad Request
클라이언트가 올바른 허가를 받지 않고 허가가 필요한 페이지에 접근하려 함. 여기에 대한 응답으로 브라우저가 대화창을 열어 사용자 이름과 암호를 받아들이도록 하는 WWW-Authenticate 헤더를 포함해야 한다.
403 Forbidden
사용 권한에 관계없이 내용을 볼 수 없음. 종종 파일 이름이 잘못되었거나 서버의 디렉터리 퍼미션이 잘못 되었을 때 나온다.
404 Not Found
이 주소에서는 어떤 내용도 발견할 수 없음. 이것은 표준 ‘no such page'응답이다. 이 상태 코드는 아주 일반적인 응답이다. 그래서 이 상태코드를 위한 HttpServletResponse:sendError(message)라는 특별한 메소드가 있다. sendError는 serStatus에 비해 에러 메시지를 보여주는 에러 페이지를 자동적으로 만들어 준다는 장점이 있다.
405 Method Not Allowed
요청 메소드(GET, POST, HEAD, DELETE, PUT, TRACE 등) 를 특정 자원에 대해서는 쓸 수 없음.
406 Not Acceptable
지정된 자원이 클라이언트의 Accept 헤더에 명시된 것과 호환 되지 않는 MIME content-type을 생성함.
407 Proxy Authentication Required
401과 비슷하지만 서버가 Proxy-Authenticate 헤더를 반환해야 한다.
408 Request Timeout
클라이언트가 요청을 보내는 데 너무 오랜 시간이 걸림.
409 Conflict
보통 PUT 요청과 관계 있다. 보통 틀린 버전의 파일을 업로드할 경우 발생한다.
410 Gone
문서가 사라졌고 포워딩할 주소도 없음. 404와 다른 점은 이 경우 문서가 완전히 사라졌다는 것을 서버가 안다는 점이다. 404는 어떤 이유인지는 모르는데 단지 요청한 것을 사용할 수 없다는 것을 의미한다.
411 Length Required
클라이언트가 Content-Length를 보내지 않으면 서버가 처리할 수 없음.
412 Precondition Failed
요청 헤더에 설정되어 있는 어떤 조건이 맞지 않음.
413 Request Entity Too Large
요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. 만약 서버에서 나중에 다룰 수 있다고 생각되면 Retry-After 헤더를 포함시켜야 한다. (HTTP 1.1에서 새로 등장)
414 Request URI Too Long
URI가 너무 길다.
415 Unsupported Media Type
요청이 알려지지 않은 형태임
416 Requested Range Not Satisfiable
클라이언트가 요청에 적당하지 않은 Range 헤더를 포함시켰음
417 Expectation Failed
Expect 요청 헤더의 값이 맞지 않음.
500 Internal Server Error
일반적인 ‘server is confused' 메시지. 종종 CGI 프로그램이나 서블릿의 결과가 잘못되거나 적절하지 않은 헤더를 만들었을 때 발생한다.
501 Not Implemented
요청한 것을 서버에서 지원하지 않음. 예를 들면 클라이언트가 서버에서 지원하지 않는 PUT과 같은 명령을 내렸을 때 발생한다.
502 Bad Gateway
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 부적절한 응답을 받았음을 나타낸다.
503 Service Unavailable
처리할 수 있는 한계를 벗어나 과도하게 요청이 들어와서 서버가 응답할 수 없음. 예를 들면 스레드나 데이터베이스 연결이 가득 차 있을 때 서블릿에서 이런 헤더를 반환한다. 서버는 Retry-After 헤더를 낼 수 있다.
504 Gateway Timeout
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 응답을 받을 수 없음을 나타낸다.
505 HTTP Version Not Supported
서버가 요청 라인에 지정된 HTTP 버전을 지원하지 않음.


 자세한건 RFC2616 문서를 보세요.

(Request For Comments :

http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=2616&type=ftp&file_format=txt

http://www.w3.org/Protocols/rfc2616/rfc2616.html )

 

1xx : 안내코드

100 : CONTINUE

101 : SWITCHING_PROTOCOLS , 규약을 전환

102 : PROCESSING

 

2xx : SUCCESS에 관한 코드

200 : OK , 성공적으로 요구를 전달하였음.

201 : CREATED , 요구가 충족되어 새로운 자원을 생성하였음

202 : ACCEPTED , 요구가 접수되었으며 아직 처리가 완료되지는 않았음. (단순한 접수여부이며 처리의 성공여부는 아님)

203 : NON_AUTHORITATIVE Information , 인증되지 않은 정보 (서버에서 사용하도록 정의되지 않는 정보세트를 말함)

204 : NO_CONTENT , 클라언트 요구을 처리했으나 전송할 데이터가 없음

       (기존내용의 변화없는 추가적인 정보입력을 실행할 경우에 해당함)

205 : RESET_CONTENT , 내용을 reset

206 : PARTIAL_CONTENT , 부분적으로 요구를 완료하였음.

207 : MULTI_STATUS

 

3xx : REDIRECT에 관한 코드 (처리를 위해 추가적인 동작이 필요함)

300 : MULTIPLE_CHOICES , 복수 선택

301 : MOVED_PERMANENTLY , 요청한 자원이 영구한 URI가 할당되어 이동함.

302 : MOVED_TEMPORARILY , 요청한 자원이 별도의 임시 URI에 할당되어 이동함.

303 : SEE_OTHER , 다시 다른것을 참조함.

304 : NOT_MODIFIED , 별다른 변경이 없이 응답되었음

305 : USE_PROXY , 요청된 자원은 프락시를 통해야만 접근이 됨

306 : TEMPORARY_REDIRECT

 

4xx : CLIENT_ERROR에 관한 코드 (요구 메시지가 처리할 수 없을 때)

400 : BAD_REQUEST , 클라이언트의 요청을 서버가 이해하지 못함.

401 : UNAUTHORIZED , 요청에 대한 응답이 사용자인증을 필요로 할 경우.

402 : PAYMENT_REQUIRED  , 예약되어 있음

403 : FORBIDDEN , 금지됨 (요청은 이해하였으나 금지되어있는 요청임)

404 : NOT_FOUND , Request-URI를 찾을 수 없음

405 : METHOD_NOT_ALLOWED , URI에서 사용되지 않는 method를 요청함.

406 : NOT_ACCEPTABLE , 접수할수없음을 나타냄.

407 : PROXY_AUTHENTICATION_REQUIRED , 프락시에서 먼저 인증을 해야함.

408 : REQUEST_TIME_OUT , 요청한 시간내에 응답을 하지 못함.

409 : CONFLICT , 충돌 (어떠한 부분의 충돌로 응답하지 못함)

410 : GONE , 영구적으로 사용할 수 없는 경우에 해당하며 그렇지 않으면 401로 응답함.

411 : LENGTH_REQUIRED , 유효하지 못한 Content-Length로 요청을 하였음.

412 : PRECONDITION_FAILED , 전체조건 실패 ( 하나이상의 Request-Header에 기재된 내용이 실패됨)

413 : REQUEST_ENTITY_TOO_LARGE , 요구 entity가 너무커서 처리가 거부됨.

414 : REQUEST_URI_TOO_LARGE ,URI길이가 허용보다 커서 처리가 거부됨.

415 : UNSUPPORTED_MEDIA_TYPE ,  지원되지 않는 포맷으로 거부됨.

416 : RANGE_NOT_SATISFIABLE

417 : EXPECTATION_FAILED

422 : UNPROCESSABLE_ENTITY

423 : LOCKED

424 : FAILED_DEPENDENCY

 

5xx : SERVER_ERROR에 관한 코드 (서버가 요청을 처리하는 과정에서 문제발생)

500 : INTERNAL_SERVER_ERROR , 내부서버 오류 (잘못된 스크립트 실행과 같은 예상하지 못한 오류일 경우)

501 : NOT_IMPLEMENTED , 구현되지 않았음 (요청을 처리하는데 필요한 기능이 구현되지 않았음)

502 : BAD_GATEWAY , 나쁜 게이트웨이 (게이트웨이 서버가 올바르지 않은 응답을 수신 할 경우)

503 : SERVICE_UNAVAILABLE , 과부하 또는 여러가지 이유로 현재 요청을 처리하지 못함.

       (임시적이며 일정한 시간뒤에 정상적으로 서비스 가능)

504 : GATEWAY_TIME_OUT , 게이트웨이(또는 프락시)서버가 시간내에 요청의 처리를 완료하는 수신을 받지 못함.

505 : VERSION_NOT_SUPPORTED , 지원되지 않는 HTTP 버젼임.

506 : VARIANT_ALSO_VARIES

507 : INSUFFICIENT_STORAGE

510 : NOT_EXTENDED

 

601 : 접근불가. HTTP CONNECT TIMEOUT

ㅇ 3초내에 CP로 HTTP Connection을 하지 못한 경우

   () Network 이상, CP 과부하로 인해 CP Web서버로 connection 안될 )

2009. 6. 2. 09:14

JBoss DataSource 설정





JBoss에서 DataSource 설정 절차

(1) JDBC 라이브러리 설치

     해당 DB 벤더의 JDBC 라이브러리를 $JBOSS_HOME/server/<instance>/lib 디렉터리에 복사한다.

     절대로 어플리케이션과 함께 패키징해서는 안된다. 예를 들어 ojdbc14.jar를 WEB-INF/lib에 두면 다양한 에러를 경험할 수 있다.

 

(2) xxx-ds.xml 작성 및 디플로이

     JBoss에서 데이터소스 설정은 파일명이 -ds.xml로 끝나는 XML 파일을 작성해 deploy 디렉터리에 두면 된다. $JBOSS_HOME/docs/examples/jca 디렉터리를 보면 벤더별 데이터소스 설정 예제들을 볼 수 있다.

 

이제 예제를 통해 설정항목들을 살펴본다.

 $JBOSS_HOME/server/default/deploy/example-ds.xml

 <?xml version="1.0" encoding="UTF-8"?>
<datasources>
  <local-tx-datasource>
    <jndi-name>jdbc/OracleDS</jndi-name>
    <connection-url>jdbc:oracle:thin:@203.231.14.100:1521:XE</connection-url>
    <driver-class>oracle.jdbc.OracleDriver</driver-class>
    <user-name>scott</user-name>
    <password>tiger</password>
    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>


    <min-pool-size>0</min-pool-size>
    <max-pool-size>20</max-pool-size>


    <blocking-timeout-millis>5000</blocking-timeout-millis>
    <idle-timeout-minutes>15</idle-timeout-minutes>


    <prepared-statement-cache-size>100</prepared-statement-cache-size>
    <track-statements>false</track-statements>


    <valid-connection-checker-class-name>
        org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker
    </valid-connection-checker-class-name>
    <exception-sorter-class-name>
        org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter
    </exception-sorter-class-name>


    <metadata>
         <type-mapping>Oracle9i</type-mapping>
    </metadata>
  </local-tx-datasource>
</datasources>

 

먼저 root element가 <datasources>로 복수형인게 눈에 띄는데 글자 그대로 하나의 -ds.xml 파일 하나에 여러 개의 데이터소스를 설정할 수 있다.

 

그 하위에 <local-tx-datasource>가 선언되어 있는데 JBoss에서는 트랜잭션 유형에 따라 <local-tx-datasource>, <xa-datasource>, <no-tx-datasource>로 element 레벨에서 구분해서 데이터소스를 설정한다. 분산 트랜잭션 처리를 위해 XA를 사용한다면 <xa-datasource>를, 그렇지 않다면 <local-tx-datasource>를 사용하면 된다.

 

그러면 <local-tx-datasource>로 선언할 때의 기본 설정 항목부터 살펴본다.

 

기본 설정 항목

1) <driver-class>

 위의 example-ds.xml에서와 같이 <local-tx-datasource>를 사용할 경우에는 java.sql.Driver 인터페이스를 구현한 드라이버 클래스를 <driver-class>에 설정한다.

Oracle 8i

oracle.jdbc.driver.OracleDriver

Oracle 9i/10g

oracle.jdbc.OracleDriver

Informix

com.informix.jdbc.IfxDriver

MS SQL

com.microsoft.jdbc.sqlserver.SQLServerDriver

MySQL

com.mysql.jdbc.Driver

 

2) <connection-url>

 DB접속 URL을 명시한다.

Oracle thin

jdbc:oracle:thin:@host:port:sid

Oracle thin (description)

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host)(PORT=port))(CONNECT_DATA=(SERVICE_NAME=sid)))

Oracle oci

jdbc:oracle:oci:@sid

Informix

jdbc:informix-sqli://host:port/dbname:INFORMIXSERVER=servername

MS SQL

jdbc:microsoft:sqlserver://host:port;DatabaseName=dbname

MySQL

jdbc:mysql://host:port/dbname

 

3) <jndi-name>과 <use-java-context>

 JNDI에서 데이터소스를 찾을 때 사용할 이름으로 jdbc/xxx 형식을 사용하는 것을 권장한다.

주의할 점은 데이터소스는 JNDI에 바인딩될 때 java: 네임스페이스로 바인딩된다는 점이다. 이때문에 Context.lookup()시에 java:/jdbc/xxx와 같이 명시해야 데이터소스를 찾을 수 있다.

만약 WebLogic에서 처럼 global하게 바인딩하려면 <use-java-context>false</use-java-context>로 설정하면 된다. 이 때는 Context.lookup()시에 jdbc/xxx로 명시한다.

 

4) <user-name>과 <password>

 DB 접속 계정과 패스워드를 명시한다. 패스워드를 따로 암호화할 필요가 있다면 이전 포스트를 참고한다.

 

5) <transaction-isolation>

트랜잭션 격리 레벨을 설정한다. TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ,
TRANSACTION_SERIALIZABLE 중에서 DB에서 지원하는 레벨을 설정할 수 있다.

 

Connection Pool 크기 설정

1) <min-pool-size>

 Pool에 유지할 최소 connection 개수로 기본값은 0. 기본적으로 최초 getConnection() 호출전까지 물리적인 db connection은 만들어지지 않는다. 데이터소스 디플로이시에 <min-pool-size>만큼 connection을 만들고자 한다면 <prefill>true</prefill>을 추가로 설정해준다.

 

2) <max-pool-size>

 최대 connection 개수를 설정한다. 기본값은 20.

 

각종 Timeout 설정

1) <blocking-timeout-millis>

 모든 connection이 사용중일 때 getConnection()에서 connection이 반환될 때까지 기다릴 시간으로 ms 단위이다.

 

2) <idle-timeout-minute>

 pool에서 일정 시간동안 사용되지 않고 있는 connection을 닫도록 설정할 수 있는데 그 시간을 분 단위로 설정한다.

 

3) <query-timeout>

 query에 대한 응답을 기다리며 대기할 수 있는 시간을 초 단위로 설정한다.  트랜잭션 Timeout이 설정되어 있는 경우에는 <set-tx-query-timeout>true</set-tx-query-timeout>을 추가로 설정해 트랜잭션 timeout까지 남아 있는 시간을 query timeout으로 자동으로 설정할 수 있다.

 

Connection 에러 처리 설정

1) <check-valid-connection-sql>

 getConnection()시 pool에서 어플리케이션에 connection을 반환하기 전에 connection 상태를 체크하는데 사용할 SQL을 명시한다.

 ex) SELECT 1 FRORM DUAL

 

2) <valid-connection-checker-class-name>

 getConnection()시 pool에서 어플리케이션에 connection을 반환하기 전에 connection 상태를 체크하는 DB 벤더별 클래스를 명시한다. Oracle, MySQL에 대한 구현체가 제공된다

Oracle

org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker

MySQL

org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker

 

3) <exception-sorter-class-name>

 SQLException 발생시 connection error를 검출하는데 사용할 클래스를 명시한다. 예외가 Connection 문제로 발생한 경우 해당 connection을 close하게 된다.

Oracle

org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter

MySQL

org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter

Sybase

org.jboss.resource.adapter.jdbc.vendor.SybaseExceptionSorter

Informix

org.jboss.resource.adapter.jdbc.vendor.InformixExceptionSorter

 

4) <background-validation>

 connection 상태를 매번 getConnection()시마다 체크하지 않고 일정주기로 백그라운드에서 체크할지 여부를 설정한다. 기본값은 false이다.

 

5) <background-validation-minutes>

 connection 상태를 백그라운드로 체크하도록 설정한 경우 그 주기를 분 단위로 설정한다. 기본값은 10분

 

최적화 관련 설정 항목

1) <prepared-statement-cache-size>

 PreparedStatement를 캐쉬해서 성능 향상을 꾀한다. 기본값은 0이다. 이 값이 Oracle에 설정된 open_cursor 값 보다 크면 ORA-01000 "maximum open cursors exceeded"가 발생할 수 있다.

 

Connection 초기 설정

1) <new-connection-sql>

 새로 물리적인 connection을 생성할 때 마다 수행할 SQL을 설정한다. DB session 설정이 필요한 경우 유용하다.

  ex) <new-connection-sql>ALTER SESSION SET nls_date_format="YYYY-MM-DD HH24:MI:ss"</new-connection-sql>