if you are on TC 6, you can always use the NIO connector as an alternative.
There is a mem leak in 6.0.10, but fixed in SVN, new release around the
corner
take a look at
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
the "protocol" attribute tells you how to configure the different connectors
Filip
Chris Eldredge wrote:
Well, as I've stated I'm not aware of any resource contention. The
UDP socket is being used in a daemon thread that is executing
asynchronously with the standard Tomcat request processing threads and
I don't see any blocks waiting for monitors etc.
Even worse, I tried removing tc-native from $TOMCAT_HOME/bin so APR is
not being used anymore, and poof, the problem went away. That doesn't
make me comfortable, but I don't have time to dig into the bowels of APR.
Martin Gainty wrote:
Hi Chris-
Possible if the invoker 1)is executing the thread in a synchronized
fashion ..but.. synchronization produces contention (the analogy is 2
boys reach for the same piece of bread at the dinner table at the
same time where neither one wants to give the other his prize..it's
best to avoid synchronization contention scenarios)
2)'Classic Thread' objects although in most scenarios these thread
objects when associated with a key are not necessarily short-lived
and may never be GCed so eventually you may see 'permgen space
errors' happening as the objects which are classic Thread stay in
heap forever..
3)The best solution is to implement your class using ThreadLocal to
quote
"A thread-local variable effectively provides a separate copy of its
value for each thread that uses it. Each thread can see only the
value associated with that thread"
The classic example is acquiring DBConnection objects where you want
a specific DBConnection alloced and init'ed on a per thread basis an
example
public class ConnectionFactory {
private static class ThreadLocalConnection extends ThreadLocal
public Object initialValue() {
return
DriverManager.getConnection(ConfigurationSingleton.getDbUrl());
}
} //ThreadLocalConnection
private static ThreadLocalConnection conn = new
ThreadLocalConnection(); //this will acquire a per-thread singleton
object only for your thread }//ConnectionFactory
This example comes from IBM site located at
http://www-128.ibm.com/developerworks/java/library/j-threads3.html
Does this make sense?
HTH,
Martin--
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for
the use of the individual or entity to which it is addressed and may
contain information that is privileged, proprietary , confidential
and exempt from disclosure. If you are not the intended recipient,
you are notified that any dissemination, distribution or copying of
this communication is strictly prohibited.
---------------------------------------------------------------------------
Le présent message électronique (y compris les pièces qui y sont
annexées, le cas échéant) s'adresse au destinataire indiqué et peut
contenir des renseignements de caractère privé ou confidentiel. Si
vous n'êtes pas le destinataire de ce document, nous vous signalons
qu'il est strictement interdit de le diffuser, de le distribuer ou de
le reproduire.
----- Original Message ----- From: "Chris Eldredge"
<[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Thursday, March 22, 2007 10:10 AM
Subject: Re: request hangs
Martin,
Thanks for the response. The thread accepting UDP packets has a
timeout of 100ms after which it waits again for a packet. Anyway,
this is happening in its own thread, executing asynchronously from
Tomcat's http request processing threads. I'm not aware of any
limitations where accepting UDP packets should prevent another
thread from accepting TCP connections... are you?
Thanks again,
Chris
Martin Gainty wrote:
Hi Chris-
what happens when you log these events?
start of UDP loop
Accepting UDP packets on the loopback address.
log the buffer from UDP accept goto start of UDP loop
start of loop to write to temp file
Reading standard out from a child process log the buffer which is
read from standard out
writing it to a temp file.
go start of loop to write to temp file
Im guessing the UDP packet accept logic *may possibly* be blocking
as it waits for the socket to read
(and hanging the thread)
Martin --
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for
the use of the individual or entity to which it is addressed and
may contain information that is privileged, proprietary ,
confidential and exempt from disclosure. If you are not the
intended recipient, you are notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
---------------------------------------------------------------------------
Le présent message électronique (y compris les pièces qui y sont
annexées, le cas échéant) s'adresse au destinataire indiqué et peut
contenir des renseignements de caractère privé ou confidentiel. Si
vous n'êtes pas le destinataire de ce document, nous vous signalons
qu'il est strictement interdit de le diffuser, de le distribuer ou
de le reproduire.
----- Original Message ----- From: "Chris Eldredge"
<[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Wednesday, March 21, 2007 6:30 PM
Subject: request hangs
I'm working on a web application which sometimes has several
daemon threads doing I/O processing in the background. The
application seems to be fine except when several tasks are
running, sometimes Tomcat gets a request and doesn't seem to
process it. The request seems to time out without ever being
passed into my application for processing.
My index page has an auto-refresh meta tag so I see this problem
frequently. The really strange thing is if I click reload once,
the next request also hangs, but if I click reload a 2nd time,
this request is processed very quickly. This behavior is very
consistent, and doesn't seem to have anything to do with the state
of the background tasks (they are still running).
I mention the background tasks because I only see this hanging
behavior when the background tasks are active. When my
application is idle, I never see the behavior. Beyond that, I
can't figure out what the background tasks might be doing which
would prevent Tomcat from processing incoming requests:
* Accepting UDP packets on the loopback address.
* Reading standard out from a child process and writing it to a
temp file.
Neither of these activities seem like they should interfere with
Tomcat request processing.
I have placed some logging calls on a filter I configured in my
application and for the hung requests, the filter never logs a
request. This seems to indicate that the request is getting stuck
before my application gets a chance to process it.
Has anybody seen anything like this before?
Any advice for troubleshooting?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
