톰캣 아파치 연동 겨우 성공....ㅡ.ㅡ

x2nine의 이미지

한 3일을 헤매이던가??
아파치 톰캣을 연동시킬려고 이것저것 해보다 결국 성공햇습니다.
연동은 되는거 같은데... 예제 파일들이 실행이 안됩니다. ㅡ.ㅡ
jsp 파일은 제대로나오구요.
별일이..
apxs로 mod_jk2 마무리 할때 dlname 경고 나온게 걸리지만 그래도 성공했네요.
힘든 기간이었습니다.
apaceh 2.0.53 + tomcat 4.1.1 + connector-current + apr 1.1.6 + apr util 입니다.
이제 다시 한가해 지네요 ^^

File attachments: 
첨부파일 크기
Image icon xterm.png12.15 KB
purple의 이미지

아파치와 톰캣을 연동하지 않고도 웬만한 일은 다 처리할 수 있다고 생각하는데.... 아파치와 톰캣을 연동하는 문제에 집착(?)하시는 분들이 의외로 많은 듯 합니다. 무엇 때문에 연동하려 하는지야 모르니까 더이상 할 말은 없지만요.

bluefury의 이미지

purple wrote:
아파치와 톰캣을 연동하지 않고도 웬만한 일은 다 처리할 수 있다고 생각하는데.... 아파치와 톰캣을 연동하는 문제에 집착(?)하시는 분들이 의외로 많은 듯 합니다. 무엇 때문에 연동하려 하는지야 모르니까 더이상 할 말은 없지만요.

글세요 JUST FOR FUN 아닐까요? 8)

Why be The Nomal?

amakusa의 이미지

쿠...쿨럭...;;

저의 경우에도 특별한 이유 없이 연동시키는 걸 즐깁니다.... resin, tomcat 등등..;;

정태영의 이미지

purple wrote:
아파치와 톰캣을 연동하지 않고도 웬만한 일은 다 처리할 수 있다고 생각하는데.... 아파치와 톰캣을 연동하는 문제에 집착(?)하시는 분들이 의외로 많은 듯 합니다. 무엇 때문에 연동하려 하는지야 모르니까 더이상 할 말은 없지만요.

정적 텍스트/이미지 등의 자료에 대한 성능은.. 아파치가 톰캣보다.. 좋은 것으로 나오고 있습니다 :)

또한.. mod_jk 등을 사용할 경우.. 여러개의 탐캣 서버를 두고.. 로드밸런싱이 가능해집니다..

그리고.. 아파치의 다양하고 유용한 모듈들과 (mod_autoindex/rewrite/env/php/cgi/fastcgi) 함께.. jsp/servlet 까지 사용할 수 있는 장점도 가지고 있지요...

물론 저런게 필요한 사람이 있고 필요하지 않은 사람도 있겠으니.. 스스로 판단할 문제이기는 하지만.. 그냥 무의미하게 연동하는건 아닙니다 :)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

purple의 이미지

정태영 wrote:
정적 텍스트/이미지 등의 자료에 대한 성능은.. 아파치가 톰캣보다.. 좋은 것으로 나오고 있습니다 :)

또한.. mod_jk 등을 사용할 경우.. 여러개의 탐캣 서버를 두고.. 로드밸런싱이 가능해집니다..

그리고.. 아파치의 다양하고 유용한 모듈들과 (mod_autoindex/rewrite/env/php/cgi/fastcgi) 함께.. jsp/servlet 까지 사용할 수 있는 장점도 가지고 있지요...

물론 저런게 필요한 사람이 있고 필요하지 않은 사람도 있겠으니.. 스스로 판단할 문제이기는 하지만.. 그냥 무의미하게 연동하는건 아닙니다 :)

그냥 무의미하게(?) 연동하는 경우가 좀 많은 듯 해서요. 톰캣 설치에 대한 한글 문서가 대부분 아파치와의 연동을 다루고 있는지라 톰캣은 무조건 아파치와 연동해서 설치해야만 하는 줄로 아는 경우도 많은 듯 하더군요.

제 생각으론 서블릿/JSP를 공부하기 위해서라면 아파치와의 연동은 확실히 필요없겠고, 둘째로 실제 서비스 상황에서도 아파치와의 연동이 필요한 경우는 별로 많지 않을 것 같다는 생각입니다. 정적 자료야 전담 아파치 서버에서 처리하면 될 것이고, 아파치의 많은 모듈이야 상당 수는 java servlet으로 대체 가능할 것이고, php나 cgi도 따로 전담 서버에서 처리하면 될 꺼 같거든요. 로드 밸런싱은 다른 문제지만 그정도로 서비스가 커지면야 다른 방법도 많을 것이구요.(그 전에 톰캣을 다른 것으로 바꾸게 될까요? :D )

물론 Just For Fun이라면야 상관없겠지요. :wink:

죠커의 이미지

기존 자료가 문제죠.

너무 한가지 솔루션에 집중되어 있어요.

natas999의 이미지

Just For Fun 일 수도 있지만 PHP때문이 아닐까 합니다.
개발은 JSP로 하고 기존 어플리케이션은 PHP로 돌려야 하는 경우죠. (PHPBB, Moniwiki, 제로보드 등등)
저는 JSP만 사용하지만 Moniwiki를 쓸려고 연동했습니다.

# emerge girl-friend
Calculating dependencies
!!! All wemen who could satisfy "girl-friend" have been masked.

galien의 이미지

역시나 php와 jsp를 같이 즐기려면 연동시켜야 하는 겁니까?

정태영의 이미지

김상욱 wrote:
역시나 php와 jsp를 같이 즐기려면 연동시켜야 하는 겁니까?

같은 디렉토리 내에 넣고 즐기지 않으려면 연동하지 않아도 됩니다 :)
또한 같은 포트로 즐기지 않으려면 역시 연동하지 않아도 됩니다.

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

정태영의 이미지

CN wrote:
기존 자료가 문제죠.
너무 한가지 솔루션에 집중되어 있어요.

이건.. 새로운 문서들이 별로 나오지 않아서가 아닌가요 :)

아미보다 300배 훌륭한.. nabi/imhangul/qimhangul 등이 나왔는데도.. 아직까지 질문과 답변 게시판엔.. 아미를 깔았는데 뭐가 안되요!! 식의 질문들이 난무하고 있고..

xterm 에서도 한글 입/출력이 부드럽게 이루어지는데.. 업데이트도 안되는 hanterm 을 깔고 어렵게 한글설정을 하기위해 노력하는거 보면요...

좀 오래되고.. 현재 상황에 맞지 않는 문서들을;;;;;;;;;;;;

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

codebank의 이미지

아~ 원래가 tomcat이 혼자서도 동작하는 거였군요.
apache에 tomcat연결해서 사용하는 무언가를 만들어보려다가 회사에서 짤려서
tomcat은 이후에 접하질 못해서... :)

정태영님 말씀처럼 새로운 문서가 없기 때문에 그런거라고 생각됩니다.
x2nine님이 성공하신 방법을 문서로 정리해 주시면 고맙겠네요. :twisted:
그럼 다른분들이 tomcat만으로도 사용가능한 방법을 또 적어주시겠죠.

------------------------------
좋은 하루 되세요.

bh의 이미지

정태영 wrote:
xterm 에서도 한글 입/출력이 부드럽게 이루어지는데..

움.. xterm 에서도 한글 입/출력이 된다는 말이 사실인가요?
여태껏 hanterm 만 써와서.....

--
이 아이디는 이제 쓰이지 않습니다.

cleol의 이미지

Quote:
둘째로 실제 서비스 상황에서도 아파치와의 연동이 필요한 경우는 별로 많지 않을 것 같다는 생각입니다. 정적 자료야 전담 아파치 서버에서 처리하면 될 것이고

서비스 규모가 제법 크거나, 사용자가 이미지 파일을 많이 올리는 경우처럼 정적 자료 처리가 특히 많은 서비스가 아닌 이상 이미지 같은 정적 자료를 처리하기 위한 용도로 하드웨어를 추가하라고 고객사에게 이야기하기는 어려울 거 같습니다.

궁금해서 여쭤봅니다. 한대의 머신에서 아파치와 톰캣을 사용할 경우 mod_jk 를 사용해 연동하지 않고 정적 자료 처리를 아파치에게 전담시킬 수 있나요? 물론 포트는 정적 자료든 동적 자료든 80 을 사용해야만 합니다. 하나의 포트를 사용하려면 어쩔 수 없이 모든 요청이 아파치를 거쳐서 들어와야 할테고, 동적 자료를 다른 포트를 사용하고 있는 톰캣에게 전달하려면 아파치에서 리다이렉트해주던가 해야할텐데 그러는 것보다는 mod_jk 를 이용해 ajp 프로토콜로 아파치와 톰캣 사이에 통신하는게 효율적이지 않나요? 아니면 뭔가 다른 방법이 있는지..

정태영의 이미지

bh wrote:
정태영 wrote:
xterm 에서도 한글 입/출력이 부드럽게 이루어지는데..

움.. xterm 에서도 한글 입/출력이 된다는 말이 사실인가요?
여태껏 hanterm 만 써와서.....

XIM을 설치해야 한다는 걸 제외하면.. 오히려 오리지널 한텀보다 깔끔합니다

오리지널 한텀의 경우엔.. 유니코드 패치가 되서.. 유니코드 한글 출력에는 문제가 없지만.. 유니코드 한글 입력은 정상적으로 이루어지지 않는 반쪽짜리 패치같더군요 :)

댓글 첨부 파일: 
첨부파일 크기
Image icon 0바이트

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

정태영의 이미지

cleol wrote:
Quote:
둘째로 실제 서비스 상황에서도 아파치와의 연동이 필요한 경우는 별로 많지 않을 것 같다는 생각입니다. 정적 자료야 전담 아파치 서버에서 처리하면 될 것이고

서비스 규모가 제법 크거나, 사용자가 이미지 파일을 많이 올리는 경우처럼 정적 자료 처리가 특히 많은 서비스가 아닌 이상 이미지 같은 정적 자료를 처리하기 위한 용도로 하드웨어를 추가하라고 고객사에게 이야기하기는 어려울 거 같습니다.

궁금해서 여쭤봅니다. 한대의 머신에서 아파치와 톰캣을 사용할 경우 mod_jk 를 사용해 연동하지 않고 정적 자료 처리를 아파치에게 전담시킬 수 있나요? 물론 포트는 정적 자료든 동적 자료든 80 을 사용해야만 합니다. 하나의 포트를 사용하려면 어쩔 수 없이 모든 요청이 아파치를 거쳐서 들어와야 할테고, 동적 자료를 다른 포트를 사용하고 있는 톰캣에게 전달하려면 아파치에서 리다이렉트해주던가 해야할텐데 그러는 것보다는 mod_jk 를 이용해 ajp 프로토콜로 아파치와 톰캣 사이에 통신하는게 효율적이지 않나요? 아니면 뭔가 다른 방법이 있는지..

포트를 무조건 80으로 써야한다는 가정은 좀 억지스럽지 않나요 ;)

80번 포트로 아파치를..
8080 번 포트로 탐켓을 띄우고 (기본설정이죠..)

80번으로 오는 요청중.. servlets 관련이나.. jsp 확장자를 가진 파일이라면..
mod_rewrite 를 이용해 8080포트로 리다이렉션 시키는 방법을 써도 될 듯한데요..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

cleol의 이미지

Quote:
포트를 무조건 80으로 써야한다는 가정은 좀 억지스럽지 않나요 ;)

80번 포트로 아파치를..
8080 번 포트로 탐켓을 띄우고 (기본설정이죠..)

80번으로 오는 요청중.. servlets 관련이나.. jsp 확장자를 가진 파일이라면..
mod_rewrite 를 이용해 8080포트로 리다이렉션 시키는 방법을 써도 될 듯한데요..

말씀드린것처럼 그럴 경우 차라리 mod_jk 를 통한 연동이 낫지 않나 하는 생각입니다. mod_jk 가 사용하는 ajp 프로토콜이 원래 그런 처리를 효율적으로 하기 위해 개발된거구요. 그리고 브라우저의 주소창에 8080 포트가 찍히는 거는 고객사들이 대체로 싫어합니다^^;

hjeeha의 이미지

product 환경에서 톰캣 싱글을 이용한 서비스는 권장하고 싶지 않습니다. mod_jk 등을 사용할 때는 mount 옵션을 사용하여 톰캣이 필요한 서비스만 돌려줄 수 있지만 톰캣으로만 서비스하는 경우 JVM 엔진으로 수많은 이미지와 첨부파일들이 통과하게 되면서 불필요한 자원을 낭비하게 됩니다.
실예로 개발자들이 톰캣을 이용해서 자기 PC에서 개발하여 서버에 올려달라는 것이 있었는데 자그마치 500메가 가까운 사이트 구성물들을 모두 webapp 에 쑤셔박아 놓았더군요. ..살인 날뻔했습니다. 디플로이 자체가 안될 정도였으니까요.
80과 8080으로 나누어놓고 mod_rewrite 로 구분하고 개발 시 소스에 포트 분리하고.. 왜 그런 일을 해야하나요? 개발할 때 포트를 명시하여 URL을 사용했을 경우 포팅에 얼마나 악영향을 미치는지 상상해보셨습니까?
톰캣 HTTP 리스너 성능이 괜찮은 편이고 개인 프로젝트를 진행할 때는 싱글이 당연히 좋습니다. 하지만 규모가 크거나 기존 운영계에 올리려는 개발을 진행중일 때에는 참아주었으면 합니다.

다즐링의 이미지

제시하신 예는 시스템 설계상의 오류라고 생각됩니다.

톰캣이 서비스하는것은 jsp와 servlet만 하고

이미지 , 정적 html 등은 tux , thttpd , zeus 등을 사용하셔셔
서비스하여야합니다. 아파치로 이미지를 서비스한다는것은 엄청난 부하를 견딜 써버가 있어야된다는 이야기지요.
(단순히 fork 와 thread의 소모 리소스를 생각해봐도 그렇습니다.)

그리고 단순 SI가 아닌 프로덕트를 개발하는 상황 혹은
서비스를 개발하는 상황에서는 환경변수나 설정등에
이미지 써버의 url을 두는것이 좀더 product 한 환경에 맞다고 생각됩니다.

hjeeha wrote:
product 환경에서 톰캣 싱글을 이용한 서비스는 권장하고 싶지 않습니다. mod_jk 등을 사용할 때는 mount 옵션을 사용하여 톰캣이 필요한 서비스만 돌려줄 수 있지만 톰캣으로만 서비스하는 경우 JVM 엔진으로 수많은 이미지와 첨부파일들이 통과하게 되면서 불필요한 자원을 낭비하게 됩니다.
실예로 개발자들이 톰캣을 이용해서 자기 PC에서 개발하여 서버에 올려달라는 것이 있었는데 자그마치 500메가 가까운 사이트 구성물들을 모두 webapp 에 쑤셔박아 놓았더군요. ..살인 날뻔했습니다. 디플로이 자체가 안될 정도였으니까요.
80과 8080으로 나누어놓고 mod_rewrite 로 구분하고 개발 시 소스에 포트 분리하고.. 왜 그런 일을 해야하나요? 개발할 때 포트를 명시하여 URL을 사용했을 경우 포팅에 얼마나 악영향을 미치는지 상상해보셨습니까?
톰캣 HTTP 리스너 성능이 괜찮은 편이고 개인 프로젝트를 진행할 때는 싱글이 당연히 좋습니다. 하지만 규모가 크거나 기존 운영계에 올리려는 개발을 진행중일 때에는 참아주었으면 합니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

zepinos의 이미지

그냥 규모에 따라서...

개발 혹은 연구 혹은 테스트 용으로는 jakarta-tomcat 만으로...
작은 부하가 예상되는 서비스에는 apache+jakarta-tomcat+mod_jk 정도...
중급 이상의 서비스에는 tux or etc.+jakarta-tomcat 혹은 apache+tux or etc.+jakarta-tomcat 을...

이용하는 쎈쓰~!!! 를 보이면 되겠죠. 결국 엔지니어의 판단에 따라 적당한 것으로 사용하면 됩니다.
단, 처음 제기한 문제를 보건데 그냥 공부할 목적이라면 jakarta-tomcat 만으로도 충분하다는 것이 적절한 조언이 될 것 같습니다. 8)

purple의 이미지

애플리케이션으로 처리되는 페이지들은 80번 포트로 톰캣으로 운영하고 그 페이지 안에서 필요한 이미지 등의 정적 자료들은 8080 포트로 따로 아파치 등을 이용하는 방식을 많이 사용하였습니다. 이미지 url 등이 브라우저 주소창으로 노출되는 경우는 별로 없지요. :)

php까지도 연동해야 한다면 이야기가 달라지겠지만 보통 사이트 구축시에 두 개발 환경을 혼합하는 경우는 적으니까 이 정도가 많은 경우 해당되는 거겠죠.

개발시에는 당연히 톰캣만으로 개발하고 실제 운영 환경으로 배포는 위와 같이 구성하죠. 다즐링님 말씀대로 이미지 등의 url은 따로 설정 등으로 빼놓아야 하구요. 구성과 배포 과정을 잘 정리해 두면 배포시 문제점은 별로 생기지 않습니다.

아파치 톰캣 연동으로 시스템을 구성하는 경우 서비스가 느려면 톰캣을 모니터링해야 할 뿐 아니라 아파치와 톰캣 사이의 통신 문제도 살펴야 되는 등 관리 작업이 복잡해집니다. 그런 것보다는 이 편이 더 운영에 간편하더군요.

처음에는 아파치와 톰캣 연동도 하였지만 성능에 아파치와 톰캣 사이의 통신이 병목이 되기도 하였습니다. 톰캣과 아파치를 분리하여 성능이 훨씬 나아진 경우가 많았지요(톰캣 3.1시절 이야기니까 지금은 어떨지 모르겠군요). 그 뒤론 아예 톰캣과 아파치를 분리해서 구성하기만 하였습니다. php까지 추가해야 하는 경우는 아예 서버를 한대 더 사는 걸로 해결했습니다. :)

PS. 이미지 처리로 아파치와 tux, thttpd, zeus 등의 비교는 어떤지 궁금합니다. 예전에 리눅스 2.4 커널 모드 웹서버를 썼다가 서버가 자주 죽는 바람에 관두었던 적이 있거든요.

다즐링의 이미지

제가 써본 이미지써버는 다음과 같습니다.
측정기준도 본인이 해본 감이므로 별로 신뢰도는 없습니다만;;

apache2 는 아직 상용 서비스 레벨이 아니라 생각됩니다.
prefork 는 apache1 이랑 비슷하고 그외 MPM 은
아직 리눅스에선 불안한듯합니다.

worst
apache1 : 최악입니다.
tomcat 5 : 메모리 캐슁을 켜야합니다.
resin 3 : 상동
tux
thttpd + epoll ( linux 2.6 )
thttpd + kqueue ( freebsd )
best
zeus ( php 등등의 모듈은 제외 but 상용 -_-; )

사실 하위 4개는 별차이가 없습니다;
그리고 양이 적은 경우 tomcat5,resin3 면 최고입니다;;
tux 는 지금은 꽤 안정적입니다.

purple wrote:

PS. 이미지 처리로 아파치와 tux, thttpd, zeus 등의 비교는 어떤지 궁금합니다. 예전에 리눅스 2.4 커널 모드 웹서버를 썼다가 서버가 자주 죽는 바람에 관두었던 적이 있거든요.

------------------------------------------------------------------------------------------------
Life is in 다즐링