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 be no way to clear all
threadlocals
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
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 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
lifetime.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL PROTECTED]; Tom Elrod
[EMAIL PROTECTED]; Jeff Haynie [EMAIL PROTECTED];
Scott. Stark@Jboss. Org [EMAIL PROTECTED]; Jboss-Dev
[EMAIL PROTECTED]
Sent: Wednesday, January 15, 2003 8:34 PM
Subject: [JBoss-dev] ThreadPooling in JMX? Its broken
Ok, I was doing some coding and found that my ThreadLocal
variable was the
same even between remote MBean invocations. Is there some ThreadPooling
going on that is not releasing the ThreadLocal variables?
TESTCASE:
1. remotely invoke on method test1 - this sets testit
ThreadLocal variable
to hello
2. return from remote invocation
3. remotey invoke on method test2 - this just prints out value of testit
ThreadLocal variable. It will still be hello!
How the hell can you clear ThreadLocal variables if you are
thread pooling?
I'm using the RMI Connector to invoke on my MBean.
Thanks,
Bill
import javax.management.MBeanRegistration;
import javax.management.MBeanServer;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import org.jboss.logging.Logger;
import org.jboss.system.ServiceMBeanSupport;
public class ThreadLocalTester
extends ServiceMBeanSupport
implements ThreadLocalTesterMBean, MBeanRegistration
{
// Constants
// Attributes ---
static Logger log = Logger.getLogger(AOPTester.class);
MBeanServer m_mbeanServer;
ThreadLocal testit = new ThreadLocal();
// Static ---
// Constructors -
public ThreadLocalTester()
{}
// Public ---
// MBeanRegistration implementation
---
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception
{
m_mbeanServer = server;
return name;
}
public void postRegister(Boolean registrationDone)
{}
public void preDeregister() throws Exception
{}
public void postDeregister()
{}
protected void startService()
throws Exception
{
}
protected void stopService() {}
public void test1()
{
testit.set(hello);
}
public void test2()
{
System.out.println(testit.get());
}
// Inner classes -
}
---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
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 Certainly not and there should not be. The content of the thread local has to be controlled in the scope in which it exists. Scott Stark Chief Technology Officer JBoss Group, LLC - 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 think there's any way to clear the thread locals. All those variables are package protected and there seems to be no way to clear all threadlocals --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 thread pool thread, and then the thread pool thread could remove them upon 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 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 Certainly not and there should not be. The content of the thread local has to be controlled in the scope in which it exists. Scott Stark Chief Technology Officer JBoss Group, LLC - 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 think there's any way to clear the thread locals. All those variables are package protected and there seems to be no way to clear all threadlocals --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
try it. You can't do it. the threadlocal stuff within a thread is package protected. You'd have to create your own kind of ThreadLocal class. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Haynie Sent: Thursday, 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 variables in the executing thread, they could then be set in the executing thread pool thread, and then the thread pool thread could remove them upon 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 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 Certainly not and there should not be. The content of the thread local has to be controlled in the scope in which it exists. Scott Stark Chief Technology Officer JBoss Group, LLC - 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 think there's any way to clear the thread locals. All those variables are package protected and there seems to be no way to clear all threadlocals --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
Bull, the threads which have access to a thread local may have nothing to do with the thread pool. You don't know why a thread local was introduced just because you manage threads. This is a bit like saying you should be able to clear all variables declared in the sceop of package names x.y.threads. Create you own ThreadPoolLocal for the semantics your talking about. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 -- in which case, 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 have access to a thread local may have nothing to do with the thread pool. You don't know why a thread local was introduced just because you manage threads. This is a bit like saying you should be able to clear all variables declared in the sceop of package names x.y.threads. Create you own ThreadPoolLocal for the semantics your talking about. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
This is exactly my point. The point of ThreadLocals is that the data only lives for the life of the thread. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Haynie Sent: Thursday, January 16, 2003 1:52 PM To: [EMAIL PROTECTED] 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 case, you thread local variables wouldn't work -- in which case, 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 have access to a thread local may have nothing to do with the thread pool. You don't know why a thread local was introduced just because you manage threads. This is a bit like saying you should be able to clear all variables declared in the sceop of package names x.y.threads. Create you own ThreadPoolLocal for the semantics your talking about. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
I have no idea what you are talking about here. Thread locals always work. The value of the variable is scoped by the thread. What Bill is wanting is the ability to flush the variables associated with a thread in the scope of a thread pool. This is a different semantic that can be implemented as a map of thread locals accessed through the thread pool. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeff Haynie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 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 case, you thread local variables wouldn't work -- in which case, thread locals are pointless, no? --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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-local instances are subject to garbage collection (unless other references to these copies exist). As a developer you assume the thread will die after run is complete. Or in the case of an RMI invocation, when the invocation returns. The JDK developers were too shortsighted to see that people might implement thread-pools. Otherwise there would be a way to Clear the thread 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 I have no idea what you are talking about here. Thread locals always work. The value of the variable is scoped by the thread. What Bill is wanting is the ability to flush the variables associated with a thread in the scope of a thread pool. This is a different semantic that can be implemented as a map of thread locals accessed through the thread pool. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeff Haynie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 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 case, you thread local variables wouldn't work -- in which case, thread locals are pointless, no? --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
I think thread pools are different. SUN jdks do not have a thread pool. Supposedly thread creation is expensive on linux. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 16, 2003 3:22 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 by state management in reused components. My question would then be 'why would threads be different'?. The usual reason is that people say you want to limit how many threads a process creates, but that can be achieved by just monitoring the number of new threads created by the pool and listening for notifications on thread garbage collection calls. That says that you have pools who just limit the number of threads out there and block for other but associate a new thread for new invocations. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Thursday, January 16, 2003 2:18 PM To: [EMAIL PROTECTED] 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-local instances are subject to garbage collection (unless other references to these copies exist). As a developer you assume the thread will die after run is complete. Or in the case of an RMI invocation, when the invocation returns. The JDK developers were too shortsighted to see that people might implement thread-pools. Otherwise there would be a way to Clear the thread 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 I have no idea what you are talking about here. Thread locals always work. The value of the variable is scoped by the thread. What Bill is wanting is the ability to flush the variables associated with a thread in the scope of a thread pool. This is a different semantic that can be implemented as a map of thread locals accessed through the thread pool. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jeff Haynie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 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 case, you thread local variables wouldn't work -- in which case, thread locals are pointless, no? --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 in an event that will look an awful lot like a process table attack to most sysadmins. 'course my sensitivity here is related to my experience on Linux and Windows, where threads are either limited or expensive to create. -danch marc fleury wrote: 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 would then be 'why would threads be different'?. The usual reason is that people say you want to limit how many threads a process creates, but that can be achieved by just monitoring the number of new threads created by the pool and listening for notifications on thread garbage collection calls. That says that you have pools who just limit the number of threads out there and block for other but associate a new thread for new invocations. 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
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 abstraction layer between OS-threads and JVM-threads and do its own scheduling. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
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 at the moment, but I was under the impression that process creation on Linux wasn't very expensive. -Original Message-From: Bill Burke [mailto:[EMAIL PROTECTED]]Sent: Thursday, January 16, 2003 3:33 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken I think thread pools are different. SUN jdks do not have a thread pool.Supposedly thread creation is expensive on linux. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 16, 2003 3:22 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 by state management in reused components. My question would then be 'why would threads be different'?. The usual reason is that people say "you want to limit how many threads a process creates, but that can be achieved by just monitoring the number of new threads created by the pool and listening for notifications on thread garbage collection calls. That says that you have pools who just limit the number of threads out there and block for other but associate a new thread for new invocations. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Thursday, January 16, 2003 2:18 PM To: [EMAIL PROTECTED] 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-local instances are subject to garbage collection (unless other references to these copies exist). " As a developer you assume the thread will die after run is complete. Or in the case of an RMI invocation, when the invocation returns. The JDK developers were too shortsighted to see that people might implement thread-pools. Otherwise there would be a way to Clear the thread 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 I have no idea what you are talking about here. Thread locals always work. The value of the variable is scoped by the thread. What Bill is wanting is the ability to flush the variables associated with a thread in the scope of a thread pool. This is a different semantic that can be implemented as a map of thread locals accessed through the thread pool. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jeff Haynie" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 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'sexecuting on a thread pool thread - such as that another caller iscalling a method on an object via a thread pool? In this case, you thread local variables wouldn't work -- in which case, thread localsare pointless, no? --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/l
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 me when frameworks use threadlocal stuff (IIRC, ObjectStore did this to me at one point) -danch Scott M Stark wrote: This is such nonsense I can't believe it. A framework has used ThreadLocals for whatever reason. It knows nothing about the context in which it is being used. So just because it happens to be used in the context of an RMI invocation, every thread, including the non-RMI threads that have touched the ThreadLocal should be cleared? Implement your ThreadPoolLocal construct and quit whinning. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [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 thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist). As a developer you assume the thread will die after run is complete. Or in the case of an RMI invocation, when the invocation returns. The JDK developers were too shortsighted to see that people might implement thread-pools. Otherwise there would be a way to Clear the thread locals associated with a thread. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
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 abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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't as bad as if they're active, but it will/may consume time depending on the scheduling algorythm. Even if a 'pool' imposes an upper limit and blocks until GC happens, well, yeah that'd work, but the finalizer call is a non-deterministic event. Non-deterministic software can be entertaining, but it's not something I want to base an enterprise infrastructure on. -danch Rhett Aultman wrote: 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 at the moment, but I was under the impression that process creation on Linux wasn't very expensive. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 have (and JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. I mean, a JVM could also (try to) multiplex sockets under the covers, reusing one 'physical' socket for all communications between our process and any IP:Port pair. If, say, the Kaffe VM had that feature, would you say that we don't have to worry about system limits on sockets? --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not. Sure it is. JRocket just has an abstraction that loosens the limit up considerable, but the limit is still there. JRocket is basically doing your pooling for you - yeah, it's a different mechanism than pooling but the effect is the same: you can program as if you can get a thread anytime you want, even though you might have to wait anyway. To entirely get around the limit, the JVM has to completely take over the OS's scheduling role for the java application, which was what green threads did. I'd rather trust Linus, Ingo, and their hoard of contributors and testers to write a good general scheduling algorythm than anybody writing a proprietary VM. -danch --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 has its own limits and imposes them on us. maybe for sockets, but not for threads: a JVM could have (and JRockit does) an abstraction layer between OS-threads and JVM-threads and do its own scheduling. Yeah, a JVM could have, and one does. That's hardly enough to let us assume that it's pervasive. Sure, but your e-mail did look like you were saying that it is a limit imposed by the OS on Java, while it is not. Sure it is. JRocket just has an abstraction that loosens the limit up considerable, but the limit is still there. JRocket is basically doing your pooling for you - yeah, it's a different mechanism than pooling but the effect is the same: you can program as if you can get a thread anytime you want, even though you might have to wait anyway. To entirely get around the limit, the JVM has to completely take over the OS's scheduling role for the java application, which was what green threads did. I'd rather trust Linus, Ingo, and their hoard of contributors and testers to write a good general scheduling algorythm than anybody writing a proprietary VM. -danch --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
;) 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 Sorry I'm getting argumentative here - I've been hammering code and my social graces shut down. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
The clear point for me is that thread locals must be set and cleared in the context they are used. If you had a mechanism that allowed you to clear all of the thread locals in a given thread, how does this change the fact that the next thread still has to establish the call context? You can't differentiate the cleared state from a left over value from a previous thread if it happens to be the same as the cleared state. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: danch [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 put into its thread local. At least that's what annoys me when frameworks use threadlocal stuff (IIRC, ObjectStore did this to me at one point) -danch --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 2.4. Also, more threads will load the OS scheduler more. If they're idle it isn't as bad as if they're active, but it will/may consume time depending on the scheduling algorythm. More runnable threads. Sleeping threads come for free. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ThreadPooling in JMX? Its broken
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 no longer true, in 2.4. Sure, you can change the parameter. However, at some point you will run out of some resource on the system. OK, maybe not from a practical point of view on the latest uber-box, but this conversation strayed from 'practical' into theoretical long ago...sorry about that. Also, more threads will load the OS scheduler more. If they're idle it isn't as bad as if they're active, but it will/may consume time depending on the scheduling algorythm. More runnable threads. Sleeping threads come for free. --- 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.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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{...} of the JRMPInvoker has
to clear the thread locals if it wants to limit the context to the invocation
lifetime.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Juha Lindfors [EMAIL PROTECTED]; Tom Elrod [EMAIL PROTECTED];
Jeff Haynie [EMAIL PROTECTED];
Scott. Stark@Jboss. Org [EMAIL PROTECTED]; Jboss-Dev
[EMAIL PROTECTED]
Sent: Wednesday, January 15, 2003 8:34 PM
Subject: [JBoss-dev] ThreadPooling in JMX? Its broken
Ok, I was doing some coding and found that my ThreadLocal variable was the
same even between remote MBean invocations. Is there some ThreadPooling
going on that is not releasing the ThreadLocal variables?
TESTCASE:
1. remotely invoke on method test1 - this sets testit ThreadLocal variable
to hello
2. return from remote invocation
3. remotey invoke on method test2 - this just prints out value of testit
ThreadLocal variable. It will still be hello!
How the hell can you clear ThreadLocal variables if you are thread pooling?
I'm using the RMI Connector to invoke on my MBean.
Thanks,
Bill
import javax.management.MBeanRegistration;
import javax.management.MBeanServer;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import org.jboss.logging.Logger;
import org.jboss.system.ServiceMBeanSupport;
public class ThreadLocalTester
extends ServiceMBeanSupport
implements ThreadLocalTesterMBean, MBeanRegistration
{
// Constants
// Attributes ---
static Logger log = Logger.getLogger(AOPTester.class);
MBeanServer m_mbeanServer;
ThreadLocal testit = new ThreadLocal();
// Static ---
// Constructors -
public ThreadLocalTester()
{}
// Public ---
// MBeanRegistration implementation ---
public ObjectName preRegister(MBeanServer server, ObjectName name)
throws Exception
{
m_mbeanServer = server;
return name;
}
public void postRegister(Boolean registrationDone)
{}
public void preDeregister() throws Exception
{}
public void postDeregister()
{}
protected void startService()
throws Exception
{
}
protected void stopService() {}
public void test1()
{
testit.set(hello);
}
public void test2()
{
System.out.println(testit.get());
}
// Inner classes -
}
---
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
