Bugs item #668789, was opened at 2003-01-15 15:15
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668789group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stefan Arentz (sateh)
Assigned to: Scott M
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=62group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to:
Bugs item #668805, was opened at 2003-01-15 15:47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668805group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Scott M
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=62group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Adrian
Bugs item #664459, was opened at 2003-01-08 16:21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=664459group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Harris (rpharris)
Assigned to:
Bugs item #598904, was opened at 2002-08-22 17:45
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=598904group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Eric J Kaplan (ericjkaplan)
Assigned to:
The server module in jboss-head is not currently building:
[javac]
C:\usr\Main\jboss-head\server\output\gen\classes\org\jboss\invocation\trunk\client\ConnectionManagerMBean.java:9:
cannot resolve symbol
[javac] symbol : class ServiceMBean
[javac] location: interface
Bugs item #621973, was opened at 2002-10-11 17:27
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=621973group_id=22866
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: L.G. (lgurevich1)
Assigned to: Scott M Stark
Bugs item #668979, was opened at 2003-01-16 10:17
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668979group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Gofio Code (jgofio)
Assigned to:
Bugs item #668786, was opened at 2003-01-15 15:07
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668786group_id=22866
Category: JBossMX
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Steve Hayward (shayward)
Assigned
Bugs item #668988, was opened at 2003-01-16 10:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668988group_id=22866
Category: JBossCMP
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Barrow (bruce_b)
Assigned to:
Bugs item #648344, was opened at 2002-12-04 11:52
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=648344group_id=22866
Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Bruce Barrow (bruce_b)
Assigned to: Nobody/Anonymous
Hi,
I can't even get the code - I get connection refused:
cvs [update aborted]: connect to
cvs.sourceforge.net(66.35.250.207):2401 failed: Connection refused
Is anyone else seeing this?
Chris
--- Scott M Stark [EMAIL PROTECTED] wrote:
The server module in jboss-head is not currently
Head should compile now.
Looks like xdoclet changed?
Regards,
Adrian
From: Scott M Stark [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Main is not building
Date: Thu, 16 Jan 2003 01:47:09 -0800
The server module in jboss-head is not currently
Bugs item #669043, was opened at 2003-01-16 14:28
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669043group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Kuehnel (skuehnel)
Assigned
Bugs item #569305, was opened at 2002-06-15 07:35
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=569305group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Samuel Terrell (j3110)
Assigned to: Nobody/Anonymous
Bugs item #669043, was opened at 2003-01-16 14:28
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669043group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Kuehnel (skuehnel)
Assigned
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,
The original point was that JMS allows you transact the message put. If the
message put is part of the global unit of work and it has not committed,
then no receiver can pick up the message (the put does not actually occur
till we commit). This really has VERY little to do with the fact the jms
I think you are confusing two things, marc.
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one thread adds 2, the other
thread mulitplies by
Scott,
When the original code was written we did not use JMX notifications because
we were concerned that the number
of notifications would be very high and might cause the server to bottle
neck because of the notification volume.
Is your idea to also populate the statistics using
I think you're talking about giving people something more like
asynchronous method invocations (one-way) than traditional MOM style
messages, right?
I am talking about propagation of TX with async calls, yes.
An asynch. invocation on the other hand, ought to take the
transaction
with
The original point was that JMS allows you transact the
message put. If the message put is part of the global unit
of work and it has not committed, then no receiver can pick
up the message (the put does not actually occur till we
commit). This really has VERY little to do with the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Sacha Labourey
Sent: Thursday, January 16, 2003 9:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Transaction propagation change
1. multiple threads in one tx. This is doable
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one thread adds 2, the other
thread mulitplies
But to do this you need a way to create a thread in a
transaction-friendly way i.e. if you simply create a new
thread (t = new Thread), then new correct transactional
context is associated with this newly started thread. Correct?
inheritableThreadLocal (or something like that)
Yes, but
I think you are confusing two things, marc.
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate results (e.g. one
Dustin,
I am sorry I went on a tangent, it is just a pet peeve of mine for the
longest time (and I still have to hear about OLE, who likes these
discussions ;).
In the 3.x series of JBoss, there isn't a way to have one SSB
with a transaction attribute of Required call another SSB
with a
Bugs item #669112, was opened at 2003-01-16 15:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669112group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Everitt (andieveritt)
Assigned to:
guess it simply comes down to the fact that since the
beginning we hear in specs: threads are bad, bouh! , thus
it has never been standardized and instead we have to use
3000 lines of JMS + MDB to simulate async behaviour in containers.
well what you want is a language level construct a la
Bugs item #669139, was opened at 2003-01-16 17:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669139group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian Steinsiepe (floechen)
Assigned
Bugs item #669140, was opened at 2003-01-16 11:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669140group_id=22866
Category: JBossMQ
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Newcomb (mnewcomb)
Assigned to:
Bugs item #669139, was opened at 2003-01-16 17:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669139group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Florian Steinsiepe (floechen)
Assigned
Bugs item #669112, was opened at 2003-01-16 15:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669112group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Everitt (andieveritt)
Assigned to:
Bugs item #669145, was opened at 2003-01-16 17:27
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669145group_id=22866
Category: JBossCMP
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Nagel (ktnagel)
Assigned to:
In fact we could TOTALLY do that on the new AOP framework. If you
define with an xdoclet tag that a given method is @jboss:one-way then
we put an interceptor that takes fresh thread and returns immediately.
Me likes.
Please check out the metadata stuff I've been doing for the AOP
Bugs item #668988, was opened at 2003-01-16 02:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=668988group_id=22866
Category: JBossCMP
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bruce Barrow (bruce_b)
Assigned to:
Bugs item #666752, was opened at 2003-01-12 14:00
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=666752group_id=22866
Category: JBossServer
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Langelage (lafr)
Assigned to:
Now I really need a jboss-3.2.0RC1-src bundle that compiles.
Matt Cleveland
- Original Message -
From: Hunter Hillegas [EMAIL PROTECTED]
To: JBoss Dev [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 8:19 AM
Subject: Re: [JBoss-dev] Main is not building
Sourceforge has killed anon
how do you know they have KILLED it
wtf!!
marcf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On
Behalf Of Hunter Hillegas
Sent: Thursday, January 16, 2003 11:19 AM
To: JBoss Dev
Subject: Re: [JBoss-dev] Main is not building
Sourceforge has
Bugs item #669161, was opened at 2003-01-16 11:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669161group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned to:
Sacha Labourey wrote:
+
I guess this is the whole point: current JMS transactional behaviour is fine
as long as what you want is *really* to decouple the producer from the
consumer, but when what you want is just transactional multithreaded, then
it is no more (and by far) a good solution because
I think we can and should win the open source project as we have a more
mature code base and more downloads than any of the other projects.
I agree, but possibly for a different reason.
No one else has anything close to a 'Marc' driving their project. ;-)
My answers/comments are inline:
I am sorry I went on a tangent, it is just a pet peeve of mine for the
longest time (and I still have to hear about OLE, who likes these
discussions ;).
No need to apologize at all. I think it's an interesting topic as well.
Plus you're the boss so :)
In
If I understand you right, you're asking to propagate transactions via
JMS messages because they're not propagated via non-local EJB calls. I
think that begs the question, doesn't it?
Meanwhile the conversation has gone on to (basically) asynchronous EJB
(really AOP) calls.
Barlow, Dustin
marc fleury wrote:
The original point was that JMS allows you transact the
message put. If the message put is part of the global unit
of work and it has not committed, then no receiver can pick
up the message (the put does not actually occur till we
commit). This really has VERY little to
Maybe I have something messed up, but Branch_3_0 doesn't build anymore
on my apple. I have an old version of Branch_3_0 that builds fine.
Does anyone have an apple, and can build? What did you setup? Here is
what I get.
bash-2.05a$ which java
/usr/bin/java
bash-2.05a$ ls -l /usr/bin/java
Bugs item #669161, was opened at 2003-01-16 16:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669161group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned to:
Barlow, Dustin wrote:
That is what I contest. Why ? So what if it is persistent/async?
theoretically speaking what is the limitation here?
because if you care about the transaction, JMS is the wrong tool.
There's no theoretical limitation, but if what you want to to execute an
asynchrounous
The status message says:
(2003-01-14 14:04:19) As of 2003-01-14, pserver-based CVS repository access and
ViewCVS (web-based) CVS repository access
have been taken offline as to stabilize CVS server performance for developers. These
services will be re-enabled as soon as
the underlying
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
Dustin,
Please don't take offense here, but you seem to be heading in a couple
of directions where, based on my experience, I think you'll hit some
problems. Apologies in advance if I've misunderstood.
Barlow, Dustin wrote:
My answers/comments are inline:
I am sorry I went on a tangent, it
I guess this is the whole point: current JMS transactional
behaviour
is fine as long as what you want is *really* to decouple
the producer
from the consumer, but when what you want is just transactional
multithreaded, then it is no more (and by far) a good solution
because you
For these service creation events I'm addressing now to decouple JSR-77
from the core I don't see the event volume as an issue. If it is, then we need
to use asynchronous events.
For all of the stats I have read about so far, the corresponding component
should be an mbean with this information
No one else has anything close to a 'Marc' driving their
project. ;-)
I am susceptible to compliments :
thanks a bunch, makes me feel good as usually people bitch more than
give accolades.
I appreciate it :)
marcf
---
This SF.NET
Bugs item #669161, was opened at 2003-01-16 11:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669161group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned to:
I agree that if you take the spec and literally create a MBean
for every management
object there will be an absurd number of MBeans. So what does this super
MBean look like?
Is that really a problem? What if the overhead of an MBean? If that is
really a problem because the routing logic of
Bugs item #669161, was opened at 2003-01-16 11:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669161group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: None
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned
transaction attribute of NEVER on both ejbs). I think this
is exactly what Scott was addressing in his original post,
that at a bare minium, we should have the ability to say, we
don't want and can't have the transaction context pushed to
the node, so don't even try. Of course this does
torsdagen den 16 januari 2003 kl 18.28 skrev Dain Sundstrom:
bash-2.05a$ ./build.sh
Error: JAVA_HOME is not defined correctly.
We cannot execute java
setenv JAVA_HOME
/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home
setenv = export
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?
No the crux of the problem is that JMS was designed to
address the needs
of providers of application integration infrastructure that's
used for
loosely coupled interfaces between systems. If you're loosely coupled
enough to use JMS, you don't want the transaction propagated.
it is a
It is a problem to me as it just compounds startup and shutdown times. If I read the
spec correctly, every jndi ref, url ref, resource ref, etc has a mangement object.
There
is no need to create an explicit MBean for every logic object.
I think there should MBeans for the coarse level objects
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:
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
Are you sure? I don't read the spec like that... As I understand it, you
don't need an MBean for every jndi ref, url ref, etc. but for every JNDI
service, etc. If you take a look at the EJBModule or EntitBean, I don't see
such a thing.
-Message d'origine-
De : [EMAIL PROTECTED]
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?
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:
On Thursday, January 16, 2003, at 09:27 AM, Sacha Labourey wrote:
1. multiple threads in one tx. This is doable technically and may
produce determinate results if all threads access only different
resource managers. If any access the same resource manager, you will
easily get indeterminate
No, I'm not sure.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Sacha Labourey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 10:43 AM
Subject: RE: [JBoss-dev] JSR-77
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:
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
The src bundle is all screwed up. I'll create a new one.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Matt Cleveland [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 6:47 AM
On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote:
Let me simplify the example to demonstrate my real point. (and
hopefully
this is a better example)
In the 3.x series of JBoss, there isn't a way to have one SSB with a
transaction attribute of Required call another SSB with a
the only reason is that no one has previously written a
distributed tx
it is not the ONLY reason, but yes it is the REAL one.
marcf
manager. I wrote the basic stuff we need in jboss 4, it should even
work with the trunk invoker.
david jencks
If you have persistent JMS queues,
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
Bugs item #629145, was opened at 2002-10-26 17:14
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=629145group_id=22866
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Stefan Wachter (stefanwachter)
Assigned to:
Thank you very much :)
Matt Cleveland
- Original Message -
From: Scott M Stark [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 16, 2003 11:04 AM
Subject: Re: [JBoss-dev] 3.2RC1 src - doesn't build
The src bundle is all screwed up. I'll create a new one.
That works perfectly. I didn't see the Home directory in the tree.
Thanks,
-dain
On Thursday, January 16, 2003, at 11:54 AM, Hunter Hillegas wrote:
JAVA_HOME should be set to:
/System/Library/Frameworks/JavaVM.framework/Versions/1.4.1/Home
or
In our testing it seems that the mapping below on Pointbase does not work:
mapping
java-typejava.lang.Boolean/java-type
jdbc-typeBINARY/jdbc-type
sql-typeBOOLEAN/sql-type
/mapping
However, this one does:
mapping
I browsed back through the latest spec and I am still not sure what some of these
objects
represent, but that is not important for my initial focus. What I want is to remove the
dependency on JSR-77 components from the core layer. Right now even the minimal
configuration has to include the
agree.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Scott M Stark
Envoyé : jeudi, 16 janvier 2003 21:38
À : [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] JSR-77 refactoring has begun
I browsed back through the latest spec and I am still not sure
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]
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
Also, any discussion off of this list should be in
Management on JBoss forum. I
posted the last message I sent here there in the Let's
Begin topic.
Scott StarkChief Technology
OfficerJBoss Group, LLC
- Original Message -
From:
That is easy. SPEED. Distributed transaction are pricey and difficult.
By choice we did fastTM as an InVM implementation. Typical case of
90/10. Most applications actually use only invm stuff and so having an
implemetnation that serializes stuff back and forth isn't worth it.
Right now FastTM
A general problem I'm seeing in this code is going through the MBeanServer to create
these
management object MBeans instead of just creating the instance and then registering
it. It
takes about 2-3 times as many lines of code to do this and is just unreadable. Is
there a
reason for this? For
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
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
JBoss daily test results
SUMMARY
Number of tests run: 1010
Successful tests: 1007
Errors:2
Failures: 1
[time of test: 2003-01-16.12-37 GMT]
[java.version:
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
Bugs item #669140, was opened at 2003-01-16 16:18
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=669140group_id=22866
Category: JBossMQ
Group: CVS HEAD
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Michael Newcomb (mnewcomb)
Assigned to:
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
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
1 - 100 of 127 matches
Mail list logo
