AW: HANDLER THREAD PROBLEM when accessing servlet

["Gerteis, Roman" <ge...@emarketag.ch>]

Hay,

yes it's necessary to compile mod_jk.so, but it's really easy. get the
Tomcat ressources and do exactly what is said in:
http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/mod_jk-howto.html#s6
2

The build depends on OS and Apache Version so normally the distributed
binary is matching exactly one environment exapmle. (Probably not yours ;)

If you start the startup.sh (default configuration) TomCat runs standalone
and with the interface for Apache connections. (Port 8080 is standalone
Version, Port 8007 is for mod_jk connections) Therefore you can try both. If
Apache works well with your Tomcat you can remove the:

        <Connector className="org.apache.tomcat.service.PoolTcpConnector">
            <Parameter name="handler" 
 
value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
            <Parameter name="port" 
                value="8080"/>
        </Connector>

Entry form $TOMCATHOME/conf/server.xml to run Tomcat not standalone anymore.

Regards.
roman

-----Ursprüngliche Nachricht-----
Von: Artigas, Ricardo Y. [mailto:rya@easycall.net.ph]
Gesendet: Montag, 7. Mai 2001 12:27
An: tomcat-user@jakarta.apache.org
Betreff: HANDLER THREAD PROBLEM when accessing servlet


is it really necessary to recompile the mod_jk.so just so that Tomcat will
run fine with Apache?
I have Apache web server and jakarta-tomcat-3.2.1 running on  red hat linux
6.
I am running tomcat using the startup.sh script (I guess this means it's
stand-alone).

I get an error while accessing a servlet in my defined context path but the
example was working well. 
Error is: 
HANDLER THREAD PROBLEM: java.io.IOException: Stream broken
java.io.IOException: Stream broken at
org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Ajp1
2ConnectionHandler.java:386) at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection
(Ajp12ConnectionHandler.java:134) at
org.apache.tomcat.service.TcpWorkerThread.run(PoolTcpEndpoint.java:366) at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:411)
at java.lang.Thread.run(Thread.java:484) 


Any ideas? TIA.

:^)
"A chain is only as strong as its weakest link."
Ricky Y. Artigas
Analyst/Programmer
Information Technology Division
Easycall Communications Phils., Inc.
- Easycall Internet -
418 Arayat St., Mandaluyong City 1550, Philippines
Personal WAP Site: http://www.buzzed.co.uk/mobile/?rya
Company Website: http://www.easycall.com.ph
Tel.no: (+632) 5338001 ext.6574
Mobile:(+63) 0917-8951783
Pager:  141-002955
Email: rya@easycall.net.ph


> -------------------------------
> IMPORTANT NOTICE: 
	  
> This message (and any attachment hereto) may contain privileged and/or
> confidential information specific to EasyCall. If you are not the intended
> addressee indicated in this message, you may not copy or disseminate this
> message (or any attachment hereto) to anyone. Instead, please destroy this
> message (and any attachment hereto), and kindly notify the sender by reply
> email. Any information in this message (and any attachment thereto) that
> do not relate to the official business of EasyCall shall be understood as
> neither given nor endorsed by the company.
> 
> 
> -----Original Message-----
> From:	Noel E. Lecaros [SMTP:sponks@mozcom.com]
> Sent:	Monday, May 07, 2001 6:02 PM
> To:	tomcat-user@jakarta.apache.org
> Subject:	Re: wired CLASSPATH behaviour
> 
> Hi, Roman
> 
> Just a thought, but have you tried RENAMING the file db2java.zip to
> db2java.jar?
> 
> Regards,
> Noel Lecaros
> 
> "Gerteis, Roman" wrote:
> > 
> > Hay there,
> > 
> > when I was deploying a application on Tomcat 3.2.1 we had some really
> wired
> > Problems with CLASSPATH issues.
> > 
> > First of all this is the environment:
> > * apache 1.3.14
> > * mod_jk.so
> > * tomcat 3.2.1
> > on Redhat 6.2
> > JVM 1.3 (Sun distribution)
> > 
> > ok. So we were putting JDBC Drivers of IBM (db2java.zip) on various
> places
> > where we should be able to put them.
> > 
> > 1. we put it into the $TOMCAT_HOME/lib/ to be include for whole tomcat.
> (did
> > not work)
> > 2. we put it into the CLASSPATH environment inside the
> > $TOMCAT_HOME/tomcat.sh script (did not work)
> > 3. we put it into $TOMCAT_HOME/webapps/our_app/WEB-INF/lib/ (did not
> work)
> > 4. we unpacked the zip file and put the package tree under
> > $TOMCAT_HOME/webapps/our_app/WEB-INF/classes/ --> YUHEE, it worked.
> > 
> > the depressing part of it was, that db2java.zip and the _right_ Path to
> it
> > was shown in the CLASSPATH variable on every of the setups
> > (System.out.println, or shellscript ECHO). But the JDBC Driver Manager
> > dumped no suitable driver found.
> > 
> > It took me quite a lot of time to make the application run, cause there
> was
> > no reason for the failure (If you have a package in your classpath, then
> you
> > would suggest that it is loaded, right?).
> > 
> > Anyways. The whole adventure brings me to the conclusion that either the
> > CLASSPATH environment of Sun JDK 1.3 for Linux is not working properly
> or ..
> > the dynamic loading of packages of TomCat is not fully reliable (which I
> > honestly do not believe).
> > 
> > Does anyone had similar Problems, and can someone give me a tip for
> where to
> > put JDBC Driver packages inside a Webapp? (WEB-INF/lib/ I thought,
> but....)
> > 
> > thx. and regards
> > roman