If you're running Windows Server 2008 x86, you should be able to drop msvcr71.dll into your c:\Windows\System32 directory, restart Windows, then be able to start the Apache Tomcat service with no problems.
정보: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: (이하 생략)
Apache Portable Runtime에 관한 내용은 아래를 참고하세요.
Apache Portable Runtime (APR) based Native library for Tomcat
Most Linux distributions will ship packages for APR and OpenSSL. The JNI wrapper (libtcnative) will then have to be compiled. It depends on APR, OpenSSL, and the Java headers.
Requirements:
APR 1.2+ development headers (libapr1-dev package) OpenSSL 0.9.7+ development headers (libssl-dev package) JNI headers from Java compatible JDK 1.4+ GNU development environment (gcc, make) The wrapper library sources are located in the Tomcat binary bundle, in the bin/tomcat-native.tar.gz archive. Once the build environment is installed and the source archive is extracted, the wrapper library can be compiled using (from the folder containing the configure script):
2009. 10. 23 오후 5:05:21 org.apache.catalina.loader.WebappClassLoader loadClass 정보: Illegal access: this web application instance has been stopped already. Could not load org.apache.axis.transport.http.CommonsHTTPSender. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass( WebappClassLoader.java:1273) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1233) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:177) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:160) at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:100) at org.apache.axis.deployment.wsdd.WSDDTargetedChain.makeNewInstance (WSDDTargetedChain.java:157) at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance (WSDDDeployableItem.java:274) at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance (WSDDDeployableItem.java:260) at org.apache.axis.deployment.wsdd.WSDDDeployment.getTransport (WSDDDeployment.java:410) at org.apache.axis.configuration.FileProvider.getTransport(FileProvider.java:257) at org.apache.axis.AxisEngine.getTransport(AxisEngine.java:332) at org.apache.axis.client.AxisClient.invoke(AxisClient.java:163) at org.apache.axis.client.Call.invokeEngine(Call.java:2784) at org.apache.axis.client.Call.invoke(Call.java:2767) at org.apache.axis.client.Call.invoke(Call.java:2443) at org.apache.axis.client.Call.invoke(Call.java:2366) at org.apache.axis.client.Call.invoke(Call.java:1812) at com.avaya.vp.applog.client.VPReport4SoapBindingStub.reportBatch( VPReport4SoapBindingStub.java:177) at com.avaya.vp.applog.client.BatchLogWriter.logBatch(BatchLogWriter.java:230) at com.avaya.vp.applog.client.BatchLogWriter.run(BatchLogWriter.java:129) 2009. 10. 23 오후 5:05:21 org.apache.catalina.loader.WebappClassLoader loadClass
별 문제 없는듯 하군요. ㅎㅎ
It is possible that this is caused by Tomcat unsuccessfully reloading the webapplication.
The app is unloaded, but all threads don't get shut down properly. As a
result, when the threads try to run, they get clobbered by the fact
that Tomcat has shut down its classloader, and an error is logged. The best fix is to turn off automatic webapp reloading for the application: in Tomcat's server.xml, find the <Context> declaration, and ensure it is set to: reloadable="false"
1. 환경 변수에 CATALINA_HOME 추가 (ex. D:\VP5Pack\apache-tomcat-6.0.18 ) 2. %CATALINA_HOME%\conf 디렉토리에 tmax.fdl, webt.properties 복사 3. %CATALINA_HOME%\lib 디렉토리에 webt30.jar 복사 4. webt.properties 파일 내용을 각자의 환경에 맞게 변경한다.
- webt.properties 파일에서 수정해야 할 부분
1. ## set the fdl file. fdl.file=D:\\VP5Pack\\apache-tomcat-6.0.18\\conf\\tmax.fdl
2. ## WebtConnectionGroup name list connectionPool.groups=tmaxPool
간단히 설명 드리면, Apaceh가 받아 들인 요청을 처리하기 위해 'child processes"에게 분배하는 방식입니다.
종류에는 여러가지가 있으나, 대표적인 prefork 방식과 worker 방식만 설명드리겠습니다.
1. Prefork 방식(Default)
prefork [default MPM for Apache 2.0 and 1.3]: * Apache 1.3-based. * Multiple processes, 1 thread per process, processes handle requests. * Used for security and stability. * Has higher memory consumption and lower performance over the newer Apache 2.0-based threaded MPMs.
: 실행중인 프로세스를 복제하여 실행 : 여러 'child process'가 각각 하나의 'thread'를 사용합니다.
2. Worker 방식
* Apache 2.0-based. * Multiple processes, many threads per process, threads handle requests. * Used for lower memory consumption and higher performance. * Does not provide the same level of isolation request-to-request, as a process-based MPM does.
: 여러 'child process'가 여러 'thread'를 사용합니다.
3. winnt 방식
* The only MPM choice under Windows. * 1 parent process, exactly 1 child process with many threads, threads handle requests. * Best solution under Windows, as on this platform, threads are always "cheaper" to use over processes.
Apache 설치시 Default로 Prefork방식으로 설치가 되지만, Apache 설치 시 MPM 방식을 지정하면은 Worker 방식으로도 가능합니다. 최근에는 성능에 좀 더 장점을 가진 Worker 방식이 추세입니다.
1) Worker가 Prefork에 비해 적은 메모리 사용 2) Worker : 통신량이 많은 서버에 적절한 형태 3) Prefork : 안전하지 않은 제 3자가 만든 모듈 사용가능 4) Prefork : 디버깅이 빈약한 플랫폼에서 쉬운 디버깅 가능 5) apache MaxClient : Prefork 방식일 경우 최대 256 까지 변경 가능
2009. 8. 4 오후 4:04:47 org.apache.catalina.startup.HostConfig deployDirectory 심각: Error deploying web application directory ROOT java.lang.SecurityException: Servlet of class org.apache.catalina.servlets.InvokerServlet is privileged and cannot be loaded by this web application at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1145) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4371) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:926) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:889) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
이번에는 ROOT에 뭔가 문제가 생긴듯.
해결 방법.
%TOMCAT_HOME%\conf\context.xml을 수정해줘야 한다. 빨간 부분을 추가한다.
%TOMCAT_HOME%\conf\context.xml의 파일을 수정하면 여기 WAS에 loading된 모든 Web Application에 전부 적용이 된다.
<!-- The contents of this file will be loaded for each web application --> <Context reloadable="true" privileged="true">
흠... 예전부터 알고 싶었던 httpsession에 대한 이해. 예전에 httpsession관련 공부를 나름 인터넷을 검색하면서 했는데... 솔직히 이해하기 힘들었습니다.... 대략의 내용은 이해하겠지만...httpsession관련 코딩을 하려면... 으..... 쉽지 않습니다... 지금도 이해하지 못하고 헤매고 있음 ㅠ_-
회사에서 교육 좀 보내주지 ㅠ_- 고급인력에게 이정도 투자는 해야 하지 않겠어?? 엉?? ㅋㅋㅋㅋ 나 요새 막나가고 있음... 내 입으로 고급인력 이러네 ㅋㅋㅋㅋ
암튼 제가 가장 해보고 싶은 것은 WAS에 존재하고 있는 session의 갯수 체크와 session id등등 간단한 정보 몇개만 얻어오면 되는데;;; Lambda probe같은 유틸 만들고 싶은데 ㅠ_-
HttpSession 클래스에 알아보기 전에 우선 Session이란 개념부터 설명해야 겠다. Session이란 어떤 중요한 동작이 진행중에 있는 상태를 나타낸다 고 생각하면 좋겠다. 그러니까, HTTP에 대한 어떤 연속된 관찰이라고 이해할 수 있다. 그런데, 왜 HTTP에 이런 연속된 관찰같은 개념이 필요한 것일까? 여기에는 이유가 있다. HTTP의 특성상 연속된 연결은 존재할 수 없다. HTTP는 한 번 웹서버에 접속했다가 데이터로딩이 끝나면 곧바로 연결을 끊어버린다. 즉, 연속성이 없는 것이다. 이런 개념은 부족한 network bandwidth를 효율적으로 사용하는 길이지만 웹비비에스등의 서비스에서의 사용자체크같은 문제를 야기시키게 된다.
물론, 앞서 배운 Cookie를 사용하면 사용자인증을 그럴듯하게 만들 수 있지만 Cookie를 이용한 이용자인증은 관리의 책임이 모두 프로그래머에게 떠넘겨진다는 한계 때문에 완벽한 대응책은 되질 못했다. 그래서, Servlet에서는 HttpSession이라는 개념으로 이런 한계를 뛰어넘는데 Servlet에서는 다음과 같은 개념을 사용한다. 즉, 하나의 사용자는 언제나 같은 컴퓨터에서 접속을 해온다는 사실을 이용한 것이다. 사용자는 여러 컴퓨터를 돌아가면서 같은 싸이트에 접속하지는 않기 때문에 서비스를 제공하는 측에서는 접속자의 정보를 체크해서 동일한 접속클라이언트인지 아닌지를 체크할 수 있다. 접속자의 정보로는 Cookie를 사용한다. 이렇게 함으로써 Cookie를 직접 이용하는 것 보다 더 효과적인 Client관리가 이루어질 수 있다.
HttpSession객체를 얻으려면 HttpServletRequest 객체의 getSession(boolean) 메소드를 사용한다는 사실을 알 수 있다. 여기서 인자로 주는 boolean 값은 Session을 새로 만들건지 아닌지를 결정한다. true 일때는 기존에 존재하는 Session을 지우고 새로운 Session을 만들라는 뜻이며, false는 유지되고 있는 Session을 그대로 사용하겠다는 의미이다. 맨 처음 접속했을때는 HttpSession이 없는 상태이므로 보통 true를 넣어서 많이 쓴다. 이미 HttpSession이 존재하는 경우에는 true값을 넣었더라도 기존 HttpSession객체를 돌려준다. 새로 만든 것인지 아닌지는 isNew()메소드를 통해서 확인할 수 있다. 그렇다면 false는 어떨 때 쓰는걸까? 사실, Session은 30분마다 자동으로 갱신된다. 즉, 이미 Session이 만들어져서 관리되고 있다고 하더라도 30분 이내에 다른 접속을 해오지 않으면 또다른 Session이 만들어진다는 뜻이다. 이렇게 되더라도 기존의 Session은 그대로 남게 되는데, 이때 getSession(false)를 이용한다. 자동갱신되는 시간은 자바웹서버에서는 세팅할 수 있지만, JSDK 2.0에서는 세팅을 할 수 없다. 이렇게 얻은 HttpSession객체를 가지고 할 수 있는 일이 많이 있다. 우선 HttpSession이 언제 만들어졌는지도 알 수 있고 HttpSession에 있는 Properties객체를 이용해서 정보를 저장시킬 수도 있다. 예를 들어 어떤 클라이언트가 서버에 접근한 카운터를 알고 싶다면 Client의 접근이 있을때마다 HttpSession 내부에 관리되고 있는 Properties 객체에 저장시키면 일은 간단하다. 이 Properties 객체에는 처음에는 아무것도 저장되어 있지 않다. 프로그래머의 편의를 위해서 만들어 놓은 객체이기 때문이다. 그래서 이 소스에서는 우선 "counter"라는 이름을 먼저 설정해둔다. HttpSession객체를 얻어와서 맨 먼저 "counter"의 값을 조사해보고 값이 없으면 putValue("counter", new Integer(1)) 으로 세팅해둔다. 값이 있으면 이 값을 하나 증가시켜서 사용하면 된다. 이 값은 HttpSession이 유지되는 동안에는 계속 사용할 수 있으므로 다른 용도로 얼마든지 사용가능하다. 그리고, HttpSession객체에는 HttpSessionContext객체가 포함되어 있어서 모든 HttpSession객체가 이 객체를 사용하는데, HttpSessionContext객체를 이용해서 다른 HttpSessoin은 어떤 것들이 있는지도 체크할 수 있다.
HttpSession으로는 접속되어온 클라이언트의 정보를 알 수는 없지만, 이 역시 HttpSession의 Properties객체로 정보를 넣어두면 다른 HttpSession에서 사용할 수 있으므로 가능한 일이다.
1. What is Session Tracking? There are a number of problems that arise from the fact that HTTP is a "stateless" protocol. In particular, when you are doing on-line shopping, it is a real annoyance that the Web server can't easily remember previous transactions. This makes applications like shopping carts very problematic: when you add an entry to your cart, how does the server know what's already in your cart? Even if servers did retain contextual information, you'd still have problems with e-commerce. When you move from the page where you specify what you want to buy (hosted on the regular Web server) to the page that takes your credit card number and shipping address (hosted on the secure server that uses SSL), how does the server remember what you were buying?
There are three typical solutions to this problem. 1. Cookies 2. URL Rewriting 3. Hidden form field
HTTP의 특성인 stateless connection가 가져다 주는 몇가지 문제점을 on-line shopping의 예를 들면서 이야기 하고 있다. 그리고 이를 해결하기 위한 3가지 solutions에 대해 이야기 하고 있음. 자세한 내용은 링크를 통해서 확인해보세요.
계속 읽다가 보면은 아래와 같은 내용이 나옵니다.
Although the data that was explicitly associated with a session is the part you care most about, there are some other pieces of information that are sometimes useful as well.
* getId. This method returns the unique identifier generated for each session. It is sometimes used as the key name when there is only a single value associated with a session, or when logging information about previous sessions. * isNew. This returns true if the client (browser) has never seen the session, usually because it was just created rather than being referenced by an incoming client request. It returns false for preexisting sessions. * getCreationTime. This returns the time, in milliseconds since the epoch, at which the session was made. To get a value useful for printing out, pass the value to the Date constructor or the setTimeInMillis method of GregorianCalendar. * getLastAccessedTime. This returns the time, in milliseconds since the epoch, at which the session was last sent from the client. * getMaxInactiveInterval. This returns the amount of time, in seconds, that a session should go without access before being automatically invalidated. A negative value indicates that the session should never timeout.
메소드의 이름을 보면은 Probe에서 보여주는 내용들과 비슷하군요 :")
3. Example: Showing Session Information Here is a simple example that generates a Web page showing some information about the current session. You can also download the source or try it on-line.
/** Simple example of session tracking. See the shopping * cart example for a more detailed one. * <P> * Part of tutorial on servlets and JSP that appears at * http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ * 1999 Marty Hall; may be freely used or adapted. */
public class ShowSession extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Integer accessCount = new Integer(0); HttpSession session = req.getSession(true); String heading=null; if(session.isNew()){ heading="Welcome, Newcomer"; }else{ heading = "Welcome back"; Integer oldAccessCount = (Integer)session.getAttribute("accessCount"); if (oldAccessCount != null) { accessCount = new Integer(oldAccessCount.intValue() + 1); } } session.setAttribute("accessCount", accessCount); PrintWriter out; res.setContentType("text/html; charset=EUC-KR"); out = res.getWriter (); out.println("<html>"); out.println("<head><title>Request 정보 출력 Servlet</title></head>"); out.println("<body>"); out.println("<h1>요청 정보 출력</h1>"); out.println("<pre>");
out.println("----- Session Information ----------"); out.println("Session ID : " + session.getId()); out.println("Creation Time : " + new Date(session.getCreationTime())); out.println("Time of Last Access : " + new Date(session.getLastAccessedTime())); out.println("Number of Previous Accesses : " + accessCount); out.println("</pre>"); out.println("</body></html>");
http://www.lambdaprobe.org/d/index.htm Apache Tomcat instances를 실시간으로 모니터링하고 관리하는 툴입니다. GPL 라이센스를 따르며, war파일로 제공을 하기 때문에 사용하기 굉장히 편리합니다. 상용 툴에 비하면 뭐 기능이야 많이 부족하지만, 무료 툴 치고는 굉장히 유용합니다.
위 이미지는 lambdaprobe.org에서 제공하는 이미지 입니다. 사용가능한 기능들입니다. lambda probe의 단점은 Apache tomcat에 특화 되어 있다는 것입니다. jconsole에 비하여 GUI는 미려하지만, 범용성이 약간 떨어집니다.
현재 Tomcat에서 동작 중인 Application의 summary를 보여줍니다. Request 수, 현재 session정보, application의 session timeout 등등 위 화면에서 좀 더 디테일한 화면을 보고 싶으면 원하는 application이름을 클릭하면 됩니다.
현재 application이 running중이며, application에 관련된 더 자세한 내용을 볼 수 있습니다. 오른쪽 박스를 보시면은 Summary, Sessions, Attributes, JSP파일들, Resources등등 자세한 정보를 보실 수 있습니다.
Deployment 기능도 제공합니다. 굉장히 편리할 것 같습니다. 저는 아직 테스트를 안 해봤습니다. 저는 이왕이면 직접 deploy를 :")
Logs를 볼 수 있는 기능도 제공합니다. 원격으로 기술 지원등을 할 때 유용할 듯 합니다. :") 고객사에서 보통 원격 데스크탑을 사용하지 않기 때문에 이런 것은 좀 괜찮을 듯하네요.
Traffic Information도 제공합니다. 매 30초 마다 자동 업데이트가 된다고 하네요.
이외에 Threads나 Cluster, system Information, Status 등등을 확인할 수 있습니다. 근데 Lambda probe 마지막 업데이트가 2006년이네요;; 돈을 모아서 좀 보내드려야 할듯 :")
This page requires Java5 with enabled JMX Agent. To enable the JXM Agent please add "-Dcom.sun.management.jmxremote" to java command line or $JAVA_OPTS environment variable. If you are an IBM JDK user please add these properties: -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=29001 -Dcom.sun.management.jmxremote.ssl=false
Tomcat 4.1 부터 지원하는 기능입니다. Tomcat 서버를 재시동하거나 심지어 컴퓨터를 껐다 켜도 기존의 세션이 백업이 되는 기능입니다. 일정시간 사용되지 않는 세션은 하드에 저장되어서 메모리를 차지하지 않게 됩니다. 그러다 다시 그 세션의 요청이 들어오면 복원되어서 사용이 됩니다. 톰캣을 셧다운할 때에 현재 있는 모든 세션이 저장됩니다.
%TOMCAT_HOME%\conf 디렉토리
server.xml 의 <Manager> 엘리먼트를 통해서 이에대한 세팅을 기호에 맞게(?) 변경할 수 있습니다. 좋은 기능입니다.