, 2003 2:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
There is no reason to expect that distinct invocations use
distinct threads.
The invocation entry point is responsible for establishing the thread
context. In this case the try{...} finally
Sure there should. For people that want to do thread pooling!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Thursday, January 16, 2003 12:42 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Bill
Burke
Sent: Thursday, January 16, 2003 12:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
Sure there should. For people that want to do thread pooling
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
Why don't we just create on enter and then clear thread locals in the
finally of the run in the threadpool? If there's any thread local
variables in the executing thread, they could then be set in the
executing
:50 AM
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
Sure there should. For people that want to do thread pooling!
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information
, no?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Scott M Stark
Sent: Thursday, January 16, 2003 1:39 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Bull, the threads which have access to a thread local may have nothing
to do
Bull,
lol
marcf
---
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide:
, thread locals are
pointless, no?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
Scott M Stark
Sent: Thursday, January 16, 2003 1:39 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Bull, the threads which
: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
What happens in the case the executing thread doesn't know he's
executing on a thread pool thread - such as that another caller is
calling a method on an object via a thread pool? In this case, you
thread local variables wouldn't work
associated with a thread.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Thursday, January 16, 2003 2:03 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
I have no idea what you are talking
]
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
hmmm
I thought we had cleared the questions of pools of anything long time
ago, meaning that modern VMs take care of that. Also bill, you and I
have been badly burnt in the past by state management in reused
components.
My question
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS has its own limits and imposes them on us.
Starting a new thread for each operation and waiting for garbage
collection will result
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS has its own limits and imposes them on us.
maybe for sockets, but not for threads: a JVM could have (and JRockit does)
an
Title: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
According to what I've read from various sources (http://www.kerneltrap.org, assorted Ingo
Molnar interviews, etc), the cost of thread creation on Linux is comparable to
that of process creation. I am not a big Linux C developer
: Thursday, January 16, 2003 11:17 AM
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
Each thread holds an implicit reference to its copy of a thread-local
variable as long as the thread is alive and the ThreadLocal instance is
accessible; after a thread goes away, all of its copies of thread
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS has its own limits and imposes them on us.
maybe for sockets, but not for threads: a JVM could have (and
JRockit does)
an
It's not especially computation intensive, but it is resource intensive:
it consumes a process table entry. Each user is allowed only a certain
number of process table entries, and the overall system has an upper limit.
Also, more threads will load the OS scheduler more. If they're idle it
danch wrote:
Sacha Labourey wrote:
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS has its own limits and imposes them on us.
maybe for sockets, but not for threads: a JVM
Sacha Labourey wrote:
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS has its own limits and imposes them on us.
maybe for sockets, but not for threads: a JVM could have (and
Sorry I'm getting argumentative here - I've been hammering code and my
social graces shut down.
danch wrote:
Sacha Labourey wrote:
The Object pooling question was definately settled on the side of it's
not worth it, but things like threads and sockets _are_ different in
that the underlying OS
;) Which is why I was staying quite, waiting for the storm to calm down ;)
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
danch
Envoye : jeudi, 16 janvier 2003 23:29
A : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] ThreadPooling in JMX? Its broken
]
To: [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 1:35 PM
Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken
I think his point was that all of the threads in the pool being used
will become polluted with whatever crap this framework put into its
thread local. At least that's what annoys
On Thu, 16 Jan 2003, danch wrote:
It's not especially computation intensive, but it is resource intensive:
it consumes a process table entry. Each user is allowed only a certain
number of process table entries, and the overall system has an upper limit.
This latter point is no longer true, in
Adam Heath wrote:
On Thu, 16 Jan 2003, danch wrote:
It's not especially computation intensive, but it is resource intensive:
it consumes a process table entry. Each user is allowed only a certain
number of process table entries, and the overall system has an upper limit.
This latter point
There is no reason to expect that distinct invocations use distinct threads.
The invocation entry point is responsible for establishing the thread
context. In this case the try{...} finally{...} of the JRMPInvoker has
to clear the thread locals if it wants to limit the context to the invocation
25 matches
Mail list logo
