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]
>
>
