You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Short, Dave" <da...@pfizer.com> on 2002/07/23 00:56:19 UTC

Apache 2.0.39 and Tomcat 4.1.7b and W2K

Does anyone have Apache 2.0.39 and Tomcat 4.1.7b working on W2K?  Am I the
only one who can't get these two to work together?  It shouldn't be this
hard, should it?  

Mladen Turk was kind enough to post detailed step by step instructions that
he used to get this combination to work in his environment.  But, I can't
get it to work in my environment.  It seems Apache 2.0.39 still doesn't like
Tomcat 4.1.7b...

HELP

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Apache 2.0.39 and Tomcat 4.1.7b and W2K

Posted by Rick Reumann <ma...@reumann.net>.
On Monday, July 22, 2002, 6:56:19 PM, Short, Dave wrote:

SD> Does anyone have Apache 2.0.39 and Tomcat 4.1.7b working on W2K?
SD> Am I the only one who can't get these two to work together?  It
SD> shouldn't be this hard, should it?

    I'm trying all the same but with 4.0.4 of Tomcat and can't seem to
    get it work just right yet either. I have it working fine under
    localhost but that's about it. If anyone could shed light on the
    question below I'd much appreciate it. Also, is anyone as
    frustrated as I am with the poor documentation from jakarta??? I
    just don't get it..you have two great open source products and yet
    nothing explaining how the latest versions fit together. I just
    don't get it. I know the documentation is the last to come from
    open source stuff but this is very frustrating.


    Question:

Thanks if someone can help...

I'm having trouble getting Apache(2.0.39) to recognize Tomcat(4.0.4)
applications using port 7000. In my Apache httpd.conf file I have set:

Listen 7000

and also have the servername set
:
ServerName afs.obs.outback.com

Everything works fine when just dealing on the actual machine that
Apache and Tomcat is on using localhost. In other words

http://localhost:7000/ --- brings up Apache main page

http://localhost:7000/myTomcatAppName/index.jsp  --- serves up the
jsp struts application no problem

However when I try to access
http://afs.obs.outback.com:7000/myTomcatAppName/index.jsp  I get an
Apache 404 url does not exist error
(going straight to  Tomcat does work however
http://afs.obs.outback.com:8080/myTomcatAppName/index.jsp )

Please someone help..this is driving me nuts:) Thanks

For setting up Tomcat to work with Apache I followed the instructions
at this link:
http://mpcon.org/temp/how2install_apache_w_php_jsp_support.doc
    
--

Rick

mailto:maillist@reumann.net


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by Will Hartung <wi...@msoft.com>.
From: "Mark O'Driscoll" <ma...@eircom.net>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Subject: Re: Is there any way to stop exceptions getting logged to log file?


> The performance hit from exceptions occur because exceptions are thrown,
not
> in how they are handled. You cannot programatically avoid exceptions with
> xhaustive checking that would itself hinder performance. Specifically
> potential SQL errors are <pun>exceptionally</pun> difficult to cater for.
> (dropped connections, network problems, constraint violations) .Exceptions
> are only thrown when something goes wrong. The point I was trying to make
> was that exceptions are not only a sign of system failure, but one of
usage
> failure too.

Yes, which means that if you can trivially check your parameters before
calling a routine that will throw an exception because of those parameters,
it is "cheaper" than letting the routine throw the exception and then catch
it.

> Anyway, what I was trying to do was to implement a transaction & logging
> filter that determined if a particular database write operation had
worked.
> The code is simple and checks if a servlet/jsp has thrown an exception to
> check for success/failure. If the servlet/jsp completes without throwing
an
> exception, I commit the transaction, otherwise I roll it back.

To be really blunt, this is exactly the behavior tha the J2EE servers gives
you. The EJBs can be "transaction ignorant" and the overall transaction will
be committed/rolledback as appropriate.

The key here, though, is most of these exceptions shouldn't be "logical"
exceptions (particularly if there are a lot of them), but rather "physical"
exceptions (database full, integrity check error). Exceptions for
circumstances that are basically out of your control.

As a simple example, we have found, at least with a J2EE environment, that
it would be cheaper to, say, check that a user didn't exist in a DB with
simple SQL rather than insert a row dependant on that user and throw the
foreign key exception back. Much better performance.

Regards,

Will Hartung
(willh@msoft.com)




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Bug?

Posted by Jean-francois Arcand <je...@sun.com>.
Hi Craig,

browsing the Tomcat code, I found something strange:

In org.apache.catalina.core.StandardHostDeployer, when method remove() 
get invoked, fireContainerEvent(REMOVE_EVENT) is never executed (does 
not appear in the code). I have also looked at StandardHost (but this 
class delegate the call to StandardHostDeployer). In order to implement 
JACC the way we discuss it yesterday, should 
the fireContainerEvent(REMOVE_EVENT) be invoked?

Thanks,

-- Jeanfrancois


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by Mark O'Driscoll <ma...@eircom.net>.
You're right. It is too late!


> > I don't want to get involved in a programming practice debate BUT......
> >
>
> Too late ... :-)
>
> > The performance hit from exceptions occur because exceptions are thrown,
not
> > in how they are handled. You cannot programatically avoid exceptions
with
> > xhaustive checking that would itself hinder performance. Specifically
> > potential SQL errors are <pun>exceptionally</pun> difficult to cater
for.
> > (dropped connections, network problems, constraint violations)
.Exceptions
> > are only thrown when something goes wrong. The point I was trying to
make
> > was that exceptions are not only a sign of system failure, but one of
usage
> > failure too.
> >
>
> Because SQLException is a checked exception, you can't throw it directly
> from a servlet anyway, so your database accesses are already encapsulated
> in try/catch blocks.  You've already paid all the cost of checking
> already -- you actually have to deliberately rethrow it (wrapped in a
> ServletException) to allow your filter to see it.  Why go to all that
> extra work?
>
> > Anyway, what I was trying to do was to implement a transaction & logging
> > filter that determined if a particular database write operation had
worked.
> > The code is simple and checks if a servlet/jsp has thrown an exception
to
> > check for success/failure. If the servlet/jsp completes without throwing
an
> > exception, I commit the transaction, otherwise I roll it back.
> >
>
> This is not the way you should program database applications!  It is very
> very dangerous to depend on external logic to commit or roll back
> transactions for you.  If an exception happens, it should be logged and
> dealt with when it happens.
Disagree. That is just micro managing exceptions. Transactions are the
example of where a wrapper try/catch block around a series of SQL statements
is a much better way to do it than try/catching each one.

Also subsequent non database actions can cause a rollback.

>
> Database access logic should always catch its own exceptions, and
> commit or roll back the transaction appropriately.  In a web app, it is
> considered irresponsible programming for a servlet to leave an open
> database transaction after it returns from the service() method, for
> whatever reason that might happen.  To say nothing of returning the
> connection to the connection pool you got it from.
That is exactly what the filter will do for you. The transaction wrapup in
the filter will ALWAYS be called => less scope for errors.
>
> > Is there some recognised way to pass servet/jsp error conditions to
filters?
> > This would prevent me relying on exceptions (altho' exceptions would
have to
> > be catered for too). I suppose I could use the request.getAttribte()?
> >
> > Are exceptions that are trapped in a filter 'seen' and handled by
Tomcat?
> >
>
> Your problem is that Tomcat sees the exception thrown by the servlet
> before it is passed back to the filter.  That's where the logging is
> happening.  And that's not going to change (in the standard Tomcat
> release -- you're perfectly free to modify your own copy), because
> handling exceptions is not what filters are for.
Oh no it doesn't. Otherwise filters could not work. If you put doChain() in
a try catch block, you catch the exception that the jsp/servlet threw.
>
> > TIA
> >
> > - Mark
> >
>
> Craig
>
>
> > > I'll second what Craig has said and add that if your program
"normally"
> > > throws lots of exceptions, then you should look at some of your design
> > > decisions. Exceptions are wonderful when used for "Exceptional"
behavior,
> > > but not for "normal" runs. They are also REALLY slow. Exceptions can
kill
> > > your performance, and if you are getting them regularly, you should
catch
> > > the ones you can "safely" ignore as early as possible and toss them
away
> > as
> > > appropriate, or even better, not throw them at all.
> > >
> > > Regards,
> > >
> > > Will Hartung
> > > (willh@msoft.com)
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Wed, 24 Jul 2002, Mark O'Driscoll wrote:

> Date: Wed, 24 Jul 2002 09:46:18 +0100
> From: Mark O'Driscoll <ma...@eircom.net>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Is there any way to stop exceptions getting logged to log
>     file?
>
> I don't want to get involved in a programming practice debate BUT......
>

Too late ... :-)

> The performance hit from exceptions occur because exceptions are thrown, not
> in how they are handled. You cannot programatically avoid exceptions with
> xhaustive checking that would itself hinder performance. Specifically
> potential SQL errors are <pun>exceptionally</pun> difficult to cater for.
> (dropped connections, network problems, constraint violations) .Exceptions
> are only thrown when something goes wrong. The point I was trying to make
> was that exceptions are not only a sign of system failure, but one of usage
> failure too.
>

Because SQLException is a checked exception, you can't throw it directly
from a servlet anyway, so your database accesses are already encapsulated
in try/catch blocks.  You've already paid all the cost of checking
already -- you actually have to deliberately rethrow it (wrapped in a
ServletException) to allow your filter to see it.  Why go to all that
extra work?

> Anyway, what I was trying to do was to implement a transaction & logging
> filter that determined if a particular database write operation had worked.
> The code is simple and checks if a servlet/jsp has thrown an exception to
> check for success/failure. If the servlet/jsp completes without throwing an
> exception, I commit the transaction, otherwise I roll it back.
>

This is not the way you should program database applications!  It is very
very dangerous to depend on external logic to commit or roll back
transactions for you.  If an exception happens, it should be logged and
dealt with when it happens.

Database access logic should always catch its own exceptions, and
commit or roll back the transaction appropriately.  In a web app, it is
considered irresponsible programming for a servlet to leave an open
database transaction after it returns from the service() method, for
whatever reason that might happen.  To say nothing of returning the
connection to the connection pool you got it from.

> Is there some recognised way to pass servet/jsp error conditions to filters?
> This would prevent me relying on exceptions (altho' exceptions would have to
> be catered for too). I suppose I could use the request.getAttribte()?
>
> Are exceptions that are trapped in a filter 'seen' and handled by Tomcat?
>

Your problem is that Tomcat sees the exception thrown by the servlet
before it is passed back to the filter.  That's where the logging is
happening.  And that's not going to change (in the standard Tomcat
release -- you're perfectly free to modify your own copy), because
handling exceptions is not what filters are for.

> TIA
>
> - Mark
>

Craig


> > I'll second what Craig has said and add that if your program "normally"
> > throws lots of exceptions, then you should look at some of your design
> > decisions. Exceptions are wonderful when used for "Exceptional" behavior,
> > but not for "normal" runs. They are also REALLY slow. Exceptions can kill
> > your performance, and if you are getting them regularly, you should catch
> > the ones you can "safely" ignore as early as possible and toss them away
> as
> > appropriate, or even better, not throw them at all.
> >
> > Regards,
> >
> > Will Hartung
> > (willh@msoft.com)
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by Mark O'Driscoll <ma...@eircom.net>.
I don't want to get involved in a programming practice debate BUT......

The performance hit from exceptions occur because exceptions are thrown, not
in how they are handled. You cannot programatically avoid exceptions with
xhaustive checking that would itself hinder performance. Specifically
potential SQL errors are <pun>exceptionally</pun> difficult to cater for.
(dropped connections, network problems, constraint violations) .Exceptions
are only thrown when something goes wrong. The point I was trying to make
was that exceptions are not only a sign of system failure, but one of usage
failure too.

Anyway, what I was trying to do was to implement a transaction & logging
filter that determined if a particular database write operation had worked.
The code is simple and checks if a servlet/jsp has thrown an exception to
check for success/failure. If the servlet/jsp completes without throwing an
exception, I commit the transaction, otherwise I roll it back.

Is there some recognised way to pass servet/jsp error conditions to filters?
This would prevent me relying on exceptions (altho' exceptions would have to
be catered for too). I suppose I could use the request.getAttribte()?

Are exceptions that are trapped in a filter 'seen' and handled by Tomcat?

TIA

- Mark

> I'll second what Craig has said and add that if your program "normally"
> throws lots of exceptions, then you should look at some of your design
> decisions. Exceptions are wonderful when used for "Exceptional" behavior,
> but not for "normal" runs. They are also REALLY slow. Exceptions can kill
> your performance, and if you are getting them regularly, you should catch
> the ones you can "safely" ignore as early as possible and toss them away
as
> appropriate, or even better, not throw them at all.
>
> Regards,
>
> Will Hartung
> (willh@msoft.com)
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by Will Hartung <wi...@msoft.com>.
From: "Craig R. McClanahan" <cr...@apache.org>
Sent: Tuesday, July 23, 2002 10:38 AM
Subject: Re: Is there any way to stop exceptions getting logged to log file?


> On Tue, 23 Jul 2002, Mark O'Driscoll wrote:
>
> > I am using a filter to trap exceptions thrown by jsps/servlets. In
normal
> > program operation, lots of these exceptions get thrown.
>
> To avoid the exceptions getting logged, you'll need to catch them in the
> servlet or JSP itself (which is a much better programming practice than
> letting them flow through), so that the servlet container never sees them.
> Exceptions from servlets and JSPs should not be considered "normal" --
> they are an indication of an error condition that the application should
> have taken care of, but did not.

I'll second what Craig has said and add that if your program "normally"
throws lots of exceptions, then you should look at some of your design
decisions. Exceptions are wonderful when used for "Exceptional" behavior,
but not for "normal" runs. They are also REALLY slow. Exceptions can kill
your performance, and if you are getting them regularly, you should catch
the ones you can "safely" ignore as early as possible and toss them away as
appropriate, or even better, not throw them at all.

Regards,

Will Hartung
(willh@msoft.com)




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Is there any way to stop exceptions getting logged to log file?

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Tue, 23 Jul 2002, Mark O'Driscoll wrote:

> Date: Tue, 23 Jul 2002 18:18:42 +0100
> From: Mark O'Driscoll <ma...@eircom.net>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Is there any way to stop exceptions getting logged to log file?
>
> I am using a filter to trap exceptions thrown by jsps/servlets. In normal
> program operation, lots of these exceptions get thrown.
> In order to stop 'localhost_log.YYYY-MM-DD.txt' getting clogged, I'd like to
> stop exceptions that are handled by the servlet engine from being logged.
> Or at least ust havethe exception mentioned rather than the full stack
> trace.
>

To avoid the exceptions getting logged, you'll need to catch them in the
servlet or JSP itself (which is a much better programming practice than
letting them flow through), so that the servlet container never sees them.
Exceptions from servlets and JSPs should not be considered "normal" --
they are an indication of an error condition that the application should
have taken care of, but did not.

To change how much gets logged when an exception is caught by Tomcat,
you'll need to modify the Tomcat sources.

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Is there any way to stop exceptions getting logged to log file?

Posted by Mark O'Driscoll <ma...@eircom.net>.
I am using a filter to trap exceptions thrown by jsps/servlets. In normal
program operation, lots of these exceptions get thrown.
In order to stop 'localhost_log.YYYY-MM-DD.txt' getting clogged, I'd like to
stop exceptions that are handled by the servlet engine from being logged.
Or at least ust havethe exception mentioned rather than the full stack
trace.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: I find lots of these messages in my mod_jk.log. Should I worry? I am using tc4.0.4 with apache2

Posted by Hongming Qi <Ho...@noaa.gov>.
Guys,

What's the reason? I also found this problem in mod_jk.log. The Tomcat 4.0.4
couldn't work well. Anybody can help?

Thanks,
Hongming


Luminous Heart wrote:

> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
> Error connecting to the Tomcat process.
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
> In jk_endpoint_t::service, ajp_send_request failed in
> send loop 0
> [Tue Jul 23 12:18:15 2002]  [jk_connect.c (151)]:
> jk_open_socket, connect() failed errno = 111
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (599)]:
> In jk_endpoint_t::ajp_connect_to_endpoint, failed
> errno = 111
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
> Error connecting to the Tomcat process.
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
> In jk_endpoint_t::service, ajp_send_request failed in
> send loop 1
> [Tue Jul 23 12:18:15 2002]  [jk_connect.c (151)]:
> jk_open_socket, connect() failed errno = 111
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (599)]:
> In jk_endpoint_t::ajp_connect_to_endpoint, failed
> errno = 111
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
> Error connecting to the Tomcat process.
> [Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
> In jk_endpoint_t::service, ajp_send_request failed in
> send loop 2
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


I find lots of these messages in my mod_jk.log. Should I worry? I am using tc4.0.4 with apache2

Posted by Luminous Heart <lu...@yahoo.com>.
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
Error connecting to the Tomcat process.
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
In jk_endpoint_t::service, ajp_send_request failed in
send loop 0
[Tue Jul 23 12:18:15 2002]  [jk_connect.c (151)]:
jk_open_socket, connect() failed errno = 111
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (599)]:
In jk_endpoint_t::ajp_connect_to_endpoint, failed
errno = 111
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
Error connecting to the Tomcat process.
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
In jk_endpoint_t::service, ajp_send_request failed in
send loop 1
[Tue Jul 23 12:18:15 2002]  [jk_connect.c (151)]:
jk_open_socket, connect() failed errno = 111
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (599)]:
In jk_endpoint_t::ajp_connect_to_endpoint, failed
errno = 111
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (844)]:
Error connecting to the Tomcat process.
[Tue Jul 23 12:18:15 2002]  [jk_ajp_common.c (1153)]:
In jk_endpoint_t::service, ajp_send_request failed in
send loop 2


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Creating new applications

Posted by Martin <vi...@mindspring.com>.
The documentation is scary so I ordered some tomcat books.
In the meantime, I would like to create new applications that
are in a different directory that belong to a virtual host.

I added

WebAppDeploy servlet warpConnection /servlet/

to httpd.conf

That of course will point to the default CATALINA_HOME/webapps/
which I'd like to change.  What do I add to server.xml to create a new
application pointing somewhere else???


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>