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 is
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,
t; <[EMAIL PROTECTED]>
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 pu
;) 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]
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 h
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
JRo
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 could
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
isn'
> >>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
> JRoc
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 JRock
: <[EMAIL PROTECTED]>
Sent: 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 t
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 a
> 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 abstrac
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 i
PM
> To: [EMAIL PROTECTED]
> 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
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 about here. Thread
> locals always
;[EMAIL PROTECTED]>
Sent: 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; af
ead locals
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
&g
uary 16, 2003 10:52 AM
Subject: 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 ca
OTECTED]
> Subject: 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 ca
> 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: http://ads.sour
e
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 have access to a thread local may have not
Sent: Thursday, January 16, 2003 9: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 t
January 16, 2003 1:06 PM
> 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
> variable
on exiting?
-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 thre
;
>
> - Original Message -
> From: "Bill Burke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, January 16, 2003 5:35 AM
> Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
>
>
> > I don't t
AIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 16, 2003 5:35 AM
Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken
> I don't think there's any way to clear the thread locals. All those
> variables are package protected and there seems to
; Sent: Thursday, January 16, 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 establish
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
lif
29 matches
Mail list logo
