RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Hi, I come back again with my old trick that hadn't much success in the past. To solve the system class loader problem definitivly, at least with JDK 1.4 and upper, why not use the java.system.class.loader system property (see javadoc of java.lang.Classloader.getSystemClassLoader). This way, we could have a Fake Classloader, let's call it a RedirectorClassLoader (RCL), registered as the system classloader. When a call originates from a UCL, the RCL would do its normal work. But when a call doesn't come from a UCL, the RCL would check what is the current contextual UCL (as we could/can have multiple UCLs) and delegate the loading to this UCL. Not sure if your trick works with Class.forName() in all cases, especially when to go native is some JDK class such as VersionHelper12. Class.forName goes native before calling the classloader, and there it acquires the lock on the classloader; then it delegates to the classloader, which either is a UCL(2) or a child; from the UCL you walk the hierarchy up, arriving to the system classloader (or your RCL), but we already had the chance to intercept the call at UCL level. Maybe I am missing something or I misunderstood your proposal ? A feeling I have is that it is a plain old bug in HierarchyCL, but it's just a feeling (since it does not seem related to the ClassCircularityError we had in the past). Regards, Simon --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I can't believe france is out of the world cup
Hi, so sorry guys (especcialy from turkey), but now it's between us and the German. We talk again after sunday, maybe tuesday, because the party is gonna be long : ) (so i hope)... At least the referee is italian, although I'd preferred Italy was there instead of Germany. Ah well, we will see what Ronaldo can do against Kahn, a great battle. Simon --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I can't believe france is out of the world cup
Hi, man what a cup! Italy out... simone, yeah you can cry on my shoulder I know the feeling, Bwwa We're supposed to be the best players in the world, players paid 500,000 euro *a month* (== 500,000 USD) and is this worth money ? Pah, I'm glad we're out, referees apart, if we scored 5 goals, some canceled goal would not had made any difference. Simon Only Spain is exciting these days, But I really want Senegal to win :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Ignacio Coloma |Sent: Thursday, June 06, 2002 12:15 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] I can't believe france is out of the world cup | | |Maybe. Just promise not to get pissed off when the spanish fury sieges |the fields. | |You have been warned :-))) | |Vesco Claudio wrote: | |Go Italy!!! | |uhmmm, can we change jboss-development in soccer-jboss? :-))) | |Claudio | |-Original Message- |From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] |Sent: Thursday, June 06, 2002 4:30 PM |To:[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] I can't believe france is out of the world |cup | |Come on, Tomasson will kick them out with 3-0 ! | |Ah, justice is made ! Go Italy ! | |Simone, I personnaly don't care much about football: I just give a little |support for French. Today football, this week-end the legislative |elections, |pfhh... what a hard time! ;) | |But I am sure you know what I mean: Italian situation has strong |similarities with France, but a few year earlier! ;) | |This new World-Cup mailing-list is cool! | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | | | |___ | |Don't miss the 2002 Sprint PCS Application Developer's Conference |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development -- -- Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Bringing you mounds of caffeinated joy http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ClassCircularityError is a HotSpot BUG !
Hi all, after investigations, we submitted a bug for the class circularity error problem, it's a bug in HotSpot: http://developer.java.sun.com/developer/bugParade/bugs/4699981.html I did not try, but it seems JRockit does not have this bug. Simon ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I can't believe france is out of the world cup
I'll say we suck... oh well, can't win them all, but to go out that way :( They still have a tiny chance the 11th of June! Come on, Tomasson will kick them out with 3-0 ! Ah, justice is made ! Go Italy ! Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, I just took Simone's patch and applied it to the 3_0 branch. Do you mean what I committed to HEAD 2-3 hrs ago ? it did not work. Here is the stacktrace. ... Cause: java.lang.ClassCircularityError: java/lang/String I catch CCE in the new code, how come you get it back ? Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, Cause: java.lang.ClassCircularityError: java/lang/String I catch CCE in the new code, how come you get it back ? I thought you would know that ;-). Anything I can do to help the debugging? Yes, can you track down from where exactly the CCE comes from ? It seems from your stack trace that you're using JMX to invoke a method in the CCRAPoll thread. CCE is triggered by classloading so the change I made should catch all CCEs, not let them out. Finding this will really help, I suspect there is more than one entry point in the ULR. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, Well after alot of tracking down it looks like it is comming from the JVM itself. Yes, CCE are only thrown from the JVM code. Sorry, I was not clear before. I see you are using JMX to invoke some method, yes ? Let's call it target method, you call it from CCRAAbstract.invokeMethod(...), right ? Check inside the target method if you do: -loadClass() -newInstance() or, recursively, if you call some method that does this (just wrap the whole target method into a try/catch(CCE x)). Do you ever arrive to the target method ? If so, that's good, otherwise, a more difficult. Waiting for news, Thanks Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, Actully does not this part of the JVM spec basically say it all ... 5.3.2 Loading Using a User-defined Class Loader The following steps are used to load and thereby create the nonarray class or interface C denoted by N using a user-defined class loader L. First, the Java virtual machine determines whether L has already been recorded as an initiating loader of a class or interface denoted by N. If so, this class or interface is C, and no class creation is necessary. Otherwise the Java virtual machine invokes loadClass(N ) on L.1 The value returned by the invocation is the created class or interface C. The Java virtual machine then records that L is an initiating loader of C (§5.3.4). The remainder of this section describes this process in more detail. Hehehe, no, it does not say it all. IMHO the algorithm implemented in the JVM code is buggy, since it assumes too much (the details on how much is 'too much' are too long to be explained here). For example, the JVM spec does not specify what happens when 2 threads try to load the same class with the same classloader. Nor what happens if a thread waits because it is expecting some state change while another thread comes in. The JVM spec is a spec, ie it says quite a lot, but not too much ;) Read my previous post, and let's try to figure this out. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, OK. wrapped up the target method in CCE. These are thrid party libs and I believe smoewhere in the bowels they use forName() and newInstance(). What I don't understand is why I do not see it going through the UCL. or at least a classloader. I guess because they're using their own classloader, probably in StreamUtil.java. I see they're obfuscated, so I guess you don't have access to the source code, do you ? Are these 3rd party libs in the classpath, or they're loaded by JBoss ? Simon Here is the bt 11:48:58,960 ERROR [STDERR] java.lang.ClassCircularityError: com/entrust/toolkit/util/ByteArray 11:48:58,990 ERROR [STDERR] at com.entrust.toolkit.credentials.b.a(StreamUtil.java) 11:48:59,000 ERROR [STDERR] at com.entrust.toolkit.credentials.l.b(InternalStreamProfileReader.java) 11:48:59,010 ERROR [STDERR] at com.entrust.toolkit.credentials.Profile.a(Profile.java) 11:48:59,020 ERROR [STDERR] at com.entrust.toolkit.credentials.Profile.init(Profile.java) 11:48:59,029 ERROR [STDERR] at com.entrust.toolkit.User.login(User.java) 11:48:59,050 ERROR [STDERR] at com.candata.gateway.EncryptionService.init(Unknown Source) 11:48:59,059 ERROR [STDERR] at com.candata.gateway.EncryptionService.createMsg(Unknown Source) 11:48:59,070 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 11:48:59,079 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(Reflec tedMBeanDispatcher.java:284) ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi Dave, I have decompilied it before to make some sense of it. I now there is a class.forName and a newInstance but I don't think they use there own classloader. Uhm. All of the classes are in the deploy directory not in the jboss lib dir. The -sevice.xml file that starts this is has them in a classpath def pointing to the current directory. Where it is dieing it is simply reading a file that has the x509 certificate info. Ok, can you do one more test ? Can you please print the classloader for your classes, via for example: com.candata.gateway.EncryptionService.class.getClassLoader() and for the lib classes, via for example: com.entrust.toolkit.User.class.getClassLoader() com.entrust.toolkit.credentials.Profile.class.getClassLoader() I think Class.forName may be the source of the problem, as bypasses a direct call to the classloader, going directly to the JVM class cache. Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] UnifiedLoaderRepository deadlocks
Hi Adrian, 3.0RC4 The testsuite doesn't hang, and it passes a simple test that failed on the previous version (I'll add it to the testsuite this weekend + other more complicated tests). Thanks for applying this. I saw also HEAD passed tonight :) Can I sak you to link to the testsuite also a testcase that Sacha submitted, and that is now under testuite/.../classloader/concurrentload ? I am still not that familiar with the testuite :P I think there is still a problem with the ordering for findClass(String) (and possibly getURLs() - but not very likely) It will lock this before the reentrantLock which is the opposite of loadClass(String, boolean, ClassLoader). Yes, but those 2 methods are called rarely. Also, it is not possible to implement them just calling reentrantLock.acquire/release, as I need also the logic of isThreadAllowed() to set the current thread (and this would mean to call synchronize, but I don't have the classloader to wait on). Not a big deal, but on which object make the thread waiting ? I thought as a first try to leave them as is, to see if tha last changes were working. Also is synchronizing on lock necessary? It is already synchronized on the rentrantLock for these private methods. Is there a reason why these methods can't be inlined to save on stack opertions? No, I guess it can be removed now. I will work on it later this afternoon, or this weekend. Thanks for the feedback ! Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi,
so I dug into the hotspot code for JDK 131, and I found the problem. I am too tired
now to think for a solution, this is for you brave guys :)
The problems arises from a 20 lines of code in
src/share/vm/memory/systemDictionary.cpp (attached), method
resolve_instance_class_or_null(...).
The loading mechanism of the JVM is done in 2 steps:
1- look in a dictionary, if not found, put there a placeholder, then
2- load the class, calling loadClassInternal().
Thread A comes in asking for class cls1 with classloader cl1, the class has never
been loaded, put a placeholder in the dictionary, and call loadClassInternal.
Thread B comes in asking for class cls1 with classloader cl1, there is already a
placeholder, throw CCE.
The key is to ask for the same class with the same classloader.
I think this may happen with the UnifiedClassLoader scheme in several occasions, a
simple example being:
class Base {}
class Derived1 extends Base {}
class Derived2 extends Base {}
If Base is loaded by classloader1, and we have 2 threads trying to load one Derived1
and one Derived2 (and both need Base), we end up with 2 thread using the same
classloader to load the same class, and the JVM code throws CCE.
I wrote a simple testcase (attached), but it does not use JBoss classloaders, however
should be trivial to code it against JBoss codebase. If someone can take care of it...
thanks :P
As I said I did not think enough to find a solution, but at least we all know where to
start.
Cheers
Simon
PS: it seems attachments are not allowed ?
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ClassCircularityError - PROBLEM FOUND !
Hi,
Are you sure?
No, I *think* so.
From your desription it would seem that the reason
loadClassInternal is syncronized is to stop this case from happening.
I think the main assumption of the JVM code is that noone waits during a
loadClassInternal() call on the classloader itself, thus releasing its lock. This is
what happens in JBoss classloaders. If someone does so, then the dictionary has a
placeholder, but the class is not loaded. If some other thread enters and ask for the
same class with the same classloader (and it can because the first one released the
lock on the classloader - it's waiting), then the CCE is thrown.
I have written a small test case that shows this problem without using JBoss'
classloaders.
It's a JDK bug or a feature ? ]:)
Simon
The way you are describing it it would not make any differnce, and the
resolve_instance_class_or_null is not thread safe.
On Fri, 2002-05-31 at 12:13, Bordet, Simone wrote:
Hi,
so I dug into the hotspot code for JDK 131, and I found the
problem. I am too tired now to think for a solution, this is
for you brave guys :)
The problems arises from a 20 lines of code in
src/share/vm/memory/systemDictionary.cpp (attached), method
resolve_instance_class_or_null(...).
The loading mechanism of the JVM is done in 2 steps:
1- look in a dictionary, if not found, put there a placeholder, then
2- load the class, calling loadClassInternal().
Thread A comes in asking for class cls1 with classloader
cl1, the class has never been loaded, put a placeholder in
the dictionary, and call loadClassInternal.
Thread B comes in asking for class cls1 with classloader
cl1, there is already a placeholder, throw CCE.
The key is to ask for the same class with the same classloader.
I think this may happen with the UnifiedClassLoader scheme
in several occasions, a simple example being:
class Base {}
class Derived1 extends Base {}
class Derived2 extends Base {}
If Base is loaded by classloader1, and we have 2 threads
trying to load one Derived1 and one Derived2 (and both need
Base), we end up with 2 thread using the same classloader to
load the same class, and the JVM code throws CCE.
I wrote a simple testcase (attached), but it does not use
JBoss classloaders, however should be trivial to code it
against JBoss codebase. If someone can take care of it... thanks :P
As I said I did not think enough to find a solution, but at
least we all know where to start.
Cheers
Simon
PS: it seems attachments are not allowed ?
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas --
http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement failure
Hi, I think I've found the problems. Problem 1 - A does a normal loadClass() - no lock on UCL it gets past synchronise into the main routine B does a loadClassInternal() - locks the UCL A reaches unsynchronise, aquires the reentrantLock, releases itself as the currentThread and waits on the UCL B runs synchronise which tries to aquire the reentrantLock Result A holds the reentrantLock and is waiting for the UCL B holds the UCL and is waiting for the reentrantLock Problem 2 - A is the current thread in the repository B does a loadClassInternal() - locks the UCL C does a loadClass, synchronise, aquires the reentrantLock, it cannot continue because A is the currentThread, it waits on the UCL B runs synchronise which tries to aquire the reentrantLock Result C holds the reentrantLock and is waiting for the UCL B holds the UCL and is waiting for the reentrantLock A will hit a problem when it tries to unsynchronise Moving the cl.notifyAll() to after the reentrantLock.release() in unsynchronize() fixes problem 1. Moving the reentrantLock.release() before the syncrhonized(cl) in synchronize() fixes problem 2 My testsuite now completes without hanging. :-) But // This release() must be inside the synchronization block on the classloader // to avoid that a notifyAll() will arrive before the wait() below, see unsynchronize() Uhm, I think this constraint can be removed. Adrian, I am incorporating your suggestions as we speak, and I will also make ULR a single threaded class for every method. Thanks for the great catches. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] UnifiedLoaderRepository deadlocks
Hi, I have updated the ULR in HEAD to incorporate latest Adrian Brock's suggestions (thanks Adrian), and made the relevant methods single threaded. Adrian, if you can check if the changes I made correctly implement your suggestions, will be great. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement failure
Hi,
I don't see how we can guarentee that there will not be deadlocks
by focusing on making the ULR single threaded since that is not
the point of locking that we do not have control over.
Yes. Making the ULR single threaded is an orthogonal issue (will make the ULR
simpler), but the real mechanism is to wait on the classloader, releasing its lock.
The potential problem here is the native method defineClass0
which invokes
loadClassInternal(*). In this case it happens to be the same
class loader
that starts the trace at loadClassInternal(+). If however, it was a
different class loader that another thread happened to have called
loadClassInternal, that needs this class loader, there is nothing that
can be done to avoid the deadlock using the instances that the threads
have access to.
Not sure I follow you.
The mechanism used now in ULR will do this:
- ULR.loadClass is single-threaded: only one thread at a time can load classes.
- All other threads that try to load classes concurrently are forced to wait on the
classloader they're asking the class, thus releasing its lock.
This should ensure that all threads have released the lock on the classloaders while
one loads classes. Or am I missing something ?
This is the intent; if it is possible to implement it is another story :)
I think it is, but maybe there are other (simpler) solutions.
One solution is to have the public UCLs be simple facades
over the actual
UCL2s that sit in the ULR and perform the actual class
loading. On entry
into a UCL.loadClass() method, a simple singleton lock can be used to
ensure that only one thread is able to interact with the UCL2s in the
repository. Since we control the thread accessing the UCL2s
there cannot
be but a single thread invoking the syncrhonized
loadClassInternal method
and
it does not matter how many other UCL2s loadClassInternal are
invoked in
the process of resolving the requested class.
That's interesting.
It seems similar to the new mechanism where the ULR is doing the
only-one-thread-at-a-time filtering, but may result simpler.
I don't know if it carries other problems, but is worth a try.
As a side note there is this comment in code that makes up
defineClass0
javavm/runtime/classresolver.c line 2074
if (loader) {
/* Although class loaders are supposed to define loadClass as
* a synchronized method, the VM does not trust the class loader
* to do so. It enters the loader monitor just in case.
*/
monitorEnter2(ee, obj_monitor(loader));
} else {
SYSLOADER_LOCK(self);
}
so it would seem the class loader mutex is going to be acquired by
the VM somewhere other than loadInternalClass.
Which, even in case of fix for Jung's RFE - where one can override loadClass removing
the synchronized modifier - leads to the classloader being locked by JVM code, so it's
the same ol' story...
Cheers
Simon
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] UnifiedLoaderRepository deadlocks
Hi Dave, How about in the 3_0 branch? Scott will decide. Simon On Thu, 2002-05-30 at 12:12, Bordet, Simone wrote: Hi, I have updated the ULR in HEAD to incorporate latest Adrian Brock's suggestions (thanks Adrian), and made the relevant methods single threaded. Adrian, if you can check if the changes I made correctly implement your suggestions, will be great. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] UnifiedLoaderRepository deadlocks
He makes fast decisions :) -Original Message- From: Bordet, Simone Sent: giovedì 30 maggio 2002 18:31 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] UnifiedLoaderRepository deadlocks Hi Dave, How about in the 3_0 branch? Scott will decide. Simon On Thu, 2002-05-30 at 12:12, Bordet, Simone wrote: Hi, I have updated the ULR in HEAD to incorporate latest Adrian Brock's suggestions (thanks Adrian), and made the relevant methods single threaded. Adrian, if you can check if the changes I made correctly implement your suggestions, will be great. Cheers Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-Dev] DeployServiceUnitTestCase.testDependsElement failure
Hi, The hang is not predictable, but it is mostly on the RaTopicUnitTestCase. Trying to dump the threads crashes the VM, but below is the start of one of the dumps. It appears to be a deadlock in the UnifiedLoaderRepository. Looking at the code, there might be an ordering problem between synchronized(this) and becoming the currentThread. e.g. A starts with removeClassLoader and synchronizes on the ULR B starts with loadClassInternal and synchronizes on the ClassLoader B becomes the currentThread B reaches the synchronized(this) in loadClass and waits on the ULR A sends a notification which leads to a loadClassInternal A isn't the currentThread and waits in synchronize(ClassLoader) Result A is waiting to become the currentThread (held by B) B is waiting on the ULR (held by A) with its classloader locked If that's the case, then I think there is no other choice than using the reentrant lock for every method of ULR, so that the code is wrapped into a try/finally (acquire/release). Adrian, can you try the above to see if it works ? Thanks Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Crap! Classloader problems again
Hi, I am using jboss 3.0 rc3. I am seeing a classloader lockup when I am deploying an ear file. The two threads are below. I noticed that Simon updated the classloader code , does this fix it? Is it only on the 3.1 branch? It is supposed to fix it, for now is in 3.1, but unfortunately I'm not yet done. I discovered 1 minute ago that there is still a problem :( Simon ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Workaround for CL stuff
Hi, Where does the loadClassInternal() intervene? It is called by the JVM when it has to resolve class dependencies. Say you have class A that has a data member of class B. When a CL is asked to load A, it inspects the class and see that it needs to load also B. This is done at native level, and while a classloader is loading class A, the JVM calls loadClassInternal() on the *same* thread and on the *same* classloader to load class B; this may trigger another call and so on recursively. If the classloader delegates to some other classloader you can have deadlock. There is a call for loadClass, some more call on java code, then a call to native method, and if the native method decides it has no sufficient information it calls back java code, it's java - native - java. loadClass() ... defineClass() [is this the native one ?] loadClassInternal() loadClass() I experienced the deadlock problem in another project at work, and it happened to me at startup (when not all classes are already loaded and thus loadClassInternal() is called frequently). A typical scenario for me was this one: jar1 with a set of related classes, and jar2 with another set, but the 2 jars interacts and are loaded by different classloaders. When something is started in jar1, not all classes in the jar are loaded; the start triggers loading from jar2 that happens to load some class from jar1 that was not already loaded. I solved this problem in my project using reflection in the small part that had this problem (no data member directly referencing the class). I don't know if this is doable also in JBoss (waaay larger than my project :) Hope helped Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Workaround for CL stuff
Hi Marc,
Simone,
I still don't see the problem clearly, please help me.
Will try to do my best. I used the now old (thanks to you) classloader delegation
model in my project, so you probably have to integrate me with the JBoss stuff
(correct me if I'm wrong) :)
|classloader delegates to some other classloader you can have
deadlock.
this I don't see, you seem to jump to the conclusion, can you
please walk me?
You have 2 threads, both waiting for something, just started, so not classes have been
loaded yet. (see Dave Smith post for stack trace and example).
Thread CCRAPoll (call it Encryption thread) asks the CtxCL to load something. CtxCL
is some JBoss UCL.
Other thread is Thread-20 (call it Login thread) again uses the CtxCL.
Both CLs don't know the class and delegate to the UnifiedRepository which iterates on
the CLs asking.
Same does the other thread. If you are unlucky, deadlock. Can you see it now ?
Say you have only 2 CLs
thread1 does: CL1.load(A) - ULR.load(A), CL1.load(A), can't find it, iterates
on CLs (only CL2) - CL2.load(A);
thread2 does: CL2.load(B) - ULR.load(B), CL2.load(B), can't find it, iterates
on CLs (only CL1) - CL1.load(B);
Imagine the first load is triggered by loadClassInternal() (see Encryption thread,
PKCS7EncodeStream.e() have to load some class, and loadClassInternal is called, this
syncs a JBoss UCL); the second load calls UCL.loadClassLocally() which calls super,
which is sync'ed as well :) Bang ! See it now ?
Thinking loud for a solution:
1- Resource ordering may help ? I mean if you don't iterate on CL in ULR, but first
you order them, then loop ? Not sure it will work in all cases...
2- What if you don't call super() which is sync'ed and you make other 2 UCL, one that
wraps jre/lib/ext and one that wraps the classpath, both with parent the boot CL
(ie null) ? Don't know if the boot classloader is sync'ed somewhere in native code...
Make the flat classloader space in orbit around the boot classloader, not the system
classloader...
3- The more I think the more it seems to me that if you sync all CL in the correct
order you can get out...
Kind of:
sync(cl1) {
sync(cl2) {
sync(cl3) {
..
sync(cln) {
cln.loadClass(..)
}
}
}
}
}
where cl1 cl2 cl3 ... cln and there is a clearly defined operator between
classloaders (hashcode may help, is it unique when we talk of Object.hashCode() ?)
Of course since you don't know a priori the number of classloaders you have to use
some fancy Doug Lea's classes :)
Good coding, I know you like this stuff :)
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Workaround for CL stuff
Hi, The major problem (and the starting point of the whole thing) is that when classes are being loaded the JVM can call loadClassInternal() on multiple class loaders at the same time. This method is synchronized and so immediately two different threads have locked two different class loaders, let us say Thread A has locked ClassLoader A and Thread B has locked ClassLoader B. Also ClassLoader.loadClass(String, boolean) is sync'ed. It's not a problem of loadClassInternal IMHO. Also the UCL at the end calls super.loadClass() (in loadClassLocally()) so... Now loadClassInternal simply calls the loadClass method of the respective class loader and so if you have a class loader (like the JBoss UnifiedClassLoader) which can delegate to other class loaders (via UnifiedLoaderRepository) to load classes you can get a situation where Thread A now wants to access synchronized methods in ClassLoader B and Thread B wants to access synchronized methods in ClassLoader A and neither can because of the earlier locks already gained, hence deadlock. Correct. This bought about by the fact that the private loadClassInternal() method is synchronized and can be called pretty much at any time by the JVM. Not only. It's a startup problem IMHO: until all classes are cached by ULR, you may find that UCL calls super.loadClass() and you have the same problem. The only way you could work around the problem is if you could synchronize on some common object before loadClassInternal is called, but since this is called rather unpredictably directly from the JVM I don't know if there is any way to do this. Why the F*K loadClassInternal() is synchronized is a complete mystery as all it does is call loadClass() which can be synchronized if it needs to be. It is sync'ed, and would lead to the same problem, no ? I *think* (but not sure) that loadClass is sync'ed to ensure correct class initialization. If 2 threads go step-by-step in parallel to load the same class with the same CL, somewhere you have to sync to initialize the class only once... I agree that sync'ing so high it's an implementation mistake, they could have sync'ed around shared data structures, as ULR does. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss-mx Build under WinME?
Hi Trevor, I normally build jboss-mx under Unix or NT but just tried to build.bat under WinME and get loads of errors about command not found (seemingly related to doing a call on a label). Is this supposed to work under WinME? WinME normally barfs when: 1 - long shell commands are executed (has a ridiculous low limit of char for each command) 2 - some NT/W2K shell extension not available in WinME is called HTH Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/monitor BeanCacheMonitor.java BeanCacheMonitorMBean.java
Hi David, Is this in active use? I don't think so. It ages back to early 2.0 times when I coded the cache and wanted to offer some monitoring capabilities to JBoss. It still can be useful though. Is the interface/way it works etc. fixed in stone? No, I mean everyone can change it following the evolution of JBoss, as you explain below. Regards Simon Since everything is turning into mbeans, including (already) the Container, I'd like to see this work in a different way: (Entity and SFSB)Containers implement the cache snapshot as a managed attribute (read-only). Then you can look at any one bean easily. BeanCacheMonitor turns into a mbean query on the mbeans you want to look at + projection onto the snapshot attribute. Along related lines... How about putting the ejb type and ejb-module parent as components of the ejb container object name? This would make finding particular ejb containers much easier using the query facility. For instance, you can do a query to find all entities in an ejb-module. Or should we use the relation service for this? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/monitor BeanCacheMonitor.java BeanCacheMonitorMBean.java
Hey David, Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/monitor BeanCacheMonitor.java BeanCacheMonitorMBean.java User: d_jencks Date: 02/02/22 14:54:25 Modified:src/main/org/jboss/monitor BeanCacheMonitor.java BeanCacheMonitorMBean.java Log: made jndi view and bean cache monitor work again. Thanks for the update :) Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Atlanta java user group tonight JAN 15 2002
Hey Marc, I plan on sticking to a very simple presentation, we are free and don't suck, how about you? Isn't this too complex (maybe) ? ;) Ahh, it's a pity I cannot come... Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: newsite/src/docs xmbean.dtd
Hi David, !ELEMENT attribute (description?, name, type, access?) !ATTLIST attribute persistPolicy CDATA #IMPLIED getMethod CDATA #IMPLIED setMethod CDATA #IMPLIED persistPeriod NMTOKEN #IMPLIED currencyTimeLimit NMTOKEN #IMPLIED It might be a good idea to include the time unit in the duration names. Also currencyTimeLimit sounds a bit like it refers to money. Would a name like instanceTimeOutMinutes work? Well, currencyTimeLimit is what is defined by the spec for modelmbean; changing its name will require a legend that explains that instanceTimeOutMinutes in the XML will map the currencyTimeLimit field in the Descriptor. I would stay with Juha here, even if the name chosen by the spec is really awful. Regards Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] bin/privatekeys bin/BeanCacheMonitor*.jar
Hi Jason, Is there source anywhere in cvs directly? No, the single source file is directly inside the jar; the only presence in CVS is the jar itself, that's the reason why they might be very old: they are not built. It was a simple example of how it is possible to monitor the bean cache, still useful IMHO if JBoss will provide the monitoring capability of the server. Juha was working on a nice gui for monitoring, the admin package under contrib if I remember well... Do they belong in bin/ or in client/? Well, under client/ I normally think of jars required by client to use JBoss; I did not want the users to copy these jars in their clients, thinking that they are necessary to use JBoss :) That's why they're under bin/. Maybe a better place would be examples/monitoring/. Feel free to move them. I was trying to clean up the release tree for the 3.0 release (when ever that might happen). Yes, I guessed so :) Cheers Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
Hi, jumping in late... OpenJMX will soon release an implementation of RMMB with pluggable logging redirection and pluggable persistence mechanism. See http://sourceforge.net/projects/openjmx for details. Cheers Simon -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: domenica 2 dicembre 2001 16:33 To: David Budworth; Juha-P Lindfors Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings So much the better, you get to work on stuff that Juha wrote for the book and will save you some time. You even get to use it in your application if you want, seems like JBoss3.0 is providing a lot of infrastructure for you. Your help will be much appreciated on that base, marcf |-Original Message- |From: David Budworth [mailto:[EMAIL PROTECTED]] |Sent: Sunday, December 02, 2001 4:50 AM |To: Juha-P Lindfors |Cc: David Budworth; [EMAIL PROTECTED]; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Ahh. ok. | |Well, it's obvious to me (as well as everyone else I assume). That you |know a lot more about this stuff than I do. | |So, I'll leave it to the experts. | |Thanks for replying. | |-David | | |On Sun, 02 Dec 2001, Juha-P Lindfors wrote: | | | | Hi, | | Marc / everyone, | | When you asked about this Dynamic mbean thing I'm working on, were you | thinking of me applying it to RequiredModelMBean? | | I wrote a ModelMBean implementation for the book and will commit an | implementation based on it (with some other stuff) in the next couple of | days. | | | If I read correctly, we are required to supply an |implementation of that | class, no? | | Just implementing the ModelMBean interface will be enough. | | | 1) What are the expectations for determining the MBeanInfo? Should we | expect a XYZMBean interface to match the XYZ implementation the user | provides? (similar to regular MBeans) | | This would be easy to add. Since I already have the code that |walks the | methods of any specified interface to compose the operation/attribute | info structures. | | The metadata can be built using introspection on the resource class, read | from a database, read from a file, looked up from the JNDI. The | rules for introspection can follow the standard MBean rules, or you can | create your own naming rules for a specific resource type. | | | 2) What should be the rules for determining the operations/attributes? | I have written and re-written this logic in my own code about 15 times, | never really happy with it. Example, how to handle: | | int getXYZ(); | void setXYZ(float); | | Do you consider the get to be a RO attribute and one to be an |operation? Or | throw an exception for non-compliant naming? I see nothing in the spec | regarding naming standards on dynamic mbean oper/attr | | or | | int getXYZ(); | void setXYZ(int); | void setXYZ(float); | | Do we consider get/set(int) to be a RW attr, and set(float) to be an | operation? Or throw again? | | If you are talking about the Standard MBean behaviour, that would cause a | NotCompliantMBeanException to be thrown. However, for ModelMBeans you | could build your own resource types that allow this kind of interface to | be handled differently. | | As for persistence, have you finished rolling on the floor laughing at | my idea of using EJBs to store? I have noticed that no other |components | use EJBs for their JDBC based persistence. Is there a reason for this? | | The MMBean persistence can be abstracted behind a | simple PersistenceManager interface with load and store operations. The | persistence implementation may then be file based, direct JDBC, JDO or | EJB. | | | -- Juha | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: TestSuite hangs - deadlock in ClassLoader.loadClass() ???
Hi Jules, This is a full stack dump of a reproducible hang-up in the WebIntegration test-suite with Jetty4. Note the two threads which seem to be waiting on the same line of code at java.lang.ClassLoader.loadClass(ClassLoader.java:286) This looks like a deadlock to me - has anyone else had a similar problem ? Do any of those org.jboss.system folks have any ideas - or do I put on my debugging hat ? We talked about this some time ago, I guess you're victim of loadClassInternal... What would be interesting here is to understand which is the classloader couple that hangs, ie what are the monitor objects specified by the sentence waiting for monitor entry, and what is the CL hierarchy at that point. Since I encountered a very similar problem in one of my projects, I wrote a small utility class that uses JDI to inspect those monitor objects, and understand who is blocking on what. Of course the problem should be reproducible (or at least should happen often :). If you think the utility class may help you I can lend it to you, just let me know. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CacheKey copy semantics and speed
Hey, So, if you're going to get rid of the MarshalledObject and all the copying, why not just get rid of CacheKey all together? Hehe... if it is removed I have only one thing to say: told you so... :-) /Rickard eee, man this guy seem to *always* be right. Ah well, pure alien category. Rickard, ehrm, who will win the football league this year ? :-)) Simon :) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] RE: Deployment exception on Clustering
Hey, Hi postRegister() is a callback method issued by the MBeanServer before the MBean gets finally registered. You then can save the MBeanServer you are connected to and change the MBean ObjectName before it is set. This is done in preRegister, not in postRegister. Simon I am still puzzled why you need a 2 stage startup process. The only reason I can assume is that you subclass the ClusterPartition and then overwrite initService(). Wouldn't it be better to add a method call in the startService() method like postInit() which is placed in the middle of startService() ? Andy - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED]; David Jencks [EMAIL PROTECTED] Cc: Sacha Labourey [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 12, 2001 2:04 PM Subject: RE: [JBoss-dev] RE: Deployment exception on Clustering Rickard talked about something called postRegister? -Original Message- From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 4:50 PM To: David Jencks Cc: Sacha Labourey; [EMAIL PROTECTED]; Bill Burke Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering Hi David You hear it. How can be use init() again for Clustering ? Andy - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Andreas Schaefer [EMAIL PROTECTED] Cc: Sacha Labourey [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 12, 2001 1:10 PM Subject: [JBoss-dev] RE: Deployment exception on Clustering Yes this a very serious problem and it wouldn't show up with your Farm stuff. THis is my fault because I didn't document the code very well, but can we please switch this back? In the init phase, all services register with the cluster (HAPartition) for cluster events that want to listen to and also if they require state synchronization. In the start phase, the ClusterPartition mbean does the final Connect to the JavaGroups message Channel. When the Connect happens, state synchronization starts. Services will not have their state synchronized if everything is done in the start phase. Bill -Original Message- From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 3:50 PM To: Bill Burke Cc: Sacha Labourey; [EMAIL PROTECTED] Subject: Re: Deployment exception on Clustering Hi Bill I added all the code from init() into start(). Is this a problem ? At least when I use the Farm it works like a charm. Andy - Original Message - From: Bill Burke [EMAIL PROTECTED] To: David Jencks [EMAIL PROTECTED]; Andreas Schaefer [EMAIL PROTECTED] Cc: Sacha Labourey [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 12, 2001 12:59 PM Subject: RE: Deployment exception on Clustering Guys, The clustering stuff is dependent on init and start both being there. Can we put back the init? Otherwise you break our stuff. Why are you doing this anyways? Bill -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 2:33 PM To: Andreas Schaefer Cc: David Jencks; Bill Burke; Sacha Labourey; [EMAIL PROTECTED] Subject: Re: Deployment exception on Clustering Thanks, must have missed that one. I generally copied the init[Service] code and put it in start[Service] at the beginning, similarly for destroy. As far as I could tell, everything covered by the testsuite works as well after the changes as before. Please let me know of other problems. The Service interface still has init and destroy since these are used heavily in the interceptor chain. I think they are unnecessary, but won't have time to try to change them for a while. This could probably be a part if turning the interceptor chains into mbeans. Thanks! david jencks On 2001.11.12 14:13:41 -0500 Andreas Schaefer wrote: Hi David The ClusterPartition.java class is not started correctly because now init() is not called anymore and therefore the JavaGroups JChannel are not initialized. I will go ahead and fix it but maybe there are other MBeans out there which needs attention, too. Thanx x Andreas Schaefer Senior Consultant JBoss Group, LLC x
R: [JBoss-dev] Quick JMX question
Hey Doug,
Hey,
I was trying to invoke a method on an MBEAN using
server.inoke and it won't
work.
It works fine when I try to inoke no arg methods like start()
or init()
I call server.invoke(myObjectName, start, new Object[0],
new String0]);
But when I try to call sendNotification it screws up.
server.inovke(myObjectName, sendNotification, new Object[]{
myDeploymentNotification }, new
String[]{javax.management.Notification});
Is sendNotification not allowd to be invoke, or did I screw
up the signature
or something?
Is sendNotification in the management interface of your MBean ? If not,
cannot be invoked through MBeanServer.invoke
HTH,
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: AW: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss .system.URLClassLoader
Hey, If the deadlock between these two classes can occur, CL1 must use CL2 to load C2, and CL2 must use CL1 to load C1. But that would mean that CL2 is a parent of CL1, and CL1 is a parent of CL2. I believe that circular class loader parentage is impossible in Java. But that is exactly the central design of the RH-ServiceLibraries! [snip] Since ClassLoader.loadClassInternal(String) and ClassLoader.loadClass(String,boolean) are both synchronized on the instances, we could run into the problem, no matter whether ServiceLibraries does or does not lock anything, right? I agree. I started thinking if there is a chance to use a model similar to the one of Catalina, where they implemented a ClassLoader that does *not* delegate to its parent to search classes (org.apache.catalina.loader.StandardClassLoader). There is no way to set up JBoss' URLClassLoaders in a non-circular tree and use the proposal I outlined 2 days ago ? Regards Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] java.lang.ClassLoader misery. Verify this patch!
Hey,
got some time and thought some more about this, which is exactly the same
problem I got in my project. Just to speak loud to clear things also to
myself.
Problem being resumed this way: 2 classloaders in chain, 2 threads
Boot
|
Ext
|
Sys
|
CL1
|
CL2
When you load something with CL2, this will delegate to its parent,
synchronizing progressively the whole chain until it finds the class. If
every class is loaded always starting from CL2 and up, then there will be no
problems: threads will wait until the one loading classes has finished.
Problem comes when thread T1 loads from CL2 up, but thread T2 loads from CL1
down. This may happen using the MLet classloader (as happens to me) or
ServiceLibraries: both have a flat set of CL on which they iterate to find
classes.
If T1 enters CL2, T2 enters CL1, T1 delegates to CL1 but have to wait for T2
to finish, which is waiting for CL2 to become free, hence deadlock.
To me the problem seems the 2 way lookup of classes; if it is possible
always to lookup in one direction (from bottom to top) deadlock should not
happen.
In my case I have no solution, since I use the MLet classloader; in JBoss'
case is it possible to lookup only in CL that are ancestor of the current
one ?
This would mean that MBeans cannot have circular dependencies. Is this
acceptable for current JBoss codebase or it is a too strict limit ?
I'm saying something like this in ServiceLibraries.loadClass(String,
boolean, ClassLoader)
loadClass(...)
{
// search in the cache
// not found in cache, try using asking classloader
// (should guarantee bottom-top for delegation)
// not local, try other classloaders
while (allLoaders.hasNext() (foundClass != null))
{
cl = (URLClassLoader)allLoaders.next();
// Below the change
if (!scl.equals(cl) cl.isAncestorOf(scl))
{
foundClass = cl.loadClassLocally(...)
}
}
...
}
where org.jboss.system.URLClassLoader can simply re-implement isAncestorOf
that is package private in java.lang.ClassLoader.
Note that it is possible that the JVM or other Java mechanism will enter the
classloader chain in the middle (loadClassInternal, RMI's
loadClassFromClass) and if the classloader hit by these automatic mechanisms
will ask one of its heir to load classes, deadlock is possible.
Unfortunately I'm not familiar with 3.0 codebase, so the above may be plain
wrong or too restrictive for JBoss.
Comments ?
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader
Hey Ole, as I said I have a small tool written with JDI that will tell you who is holding what and who is waiting (so in the wait for monitor entry you'll know who is the monitor) If you wanna play, just tell me ;) Simon -Original Message- From: Ole Husgaard [mailto:[EMAIL PROTECTED]] Sent: martedi 2 ottobre 2001 18:49 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] The rabbit has a bug in its pelt: org.jboss.system.URLClassLoader Hi, I think this bug is the reason for the problems we see with the automated tests. Here the test count sometimes gets very low due to the tests timing out. Looking into this is hard, as it seems to change with every run, but one thing seems to be common: The deployer stops working, and the timeouts happen because all attempts at deploying beans hang with a stack trace like: RMI TCP Connection(3)-127.0.0.1 daemon prio=1 tid=0x82a5a20 nid=0x5876 waiting for monitor entry [0xbc7fe000..0xbc7ff8c4] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:349) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye r.java:473) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.jmx.connector.rmi.RMIConnectorImpl.invoke(RMIConnect orImpl.java:400) at [snip] But I think this monitor is held by another thread that appears hung with a stack trace like: RMI TCP Connection(2)-127.0.0.1 daemon prio=1 tid=0x822fc68 nid=0x5813 waiting for monitor entry [0xbdffe000..0xbdfff8c4] at java.lang.ClassLoader.loadClass(ClassLoader.java:286) at org.jboss.system.URLClassLoader.loadClassLocally(URLClassLoade r.java:163) at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:292) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) at java.lang.ClassLoader.loadClass(ClassLoader.java:290) at java.lang.ClassLoader.loadClass(ClassLoader.java:290) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at java.lang.Class.getMethods0(Native Method) at java.lang.Class.getMethods(Class.java:742) at org.jboss.verifier.strategy.EJBVerifier11.verifyEntityHome(EJB Verifier11.java:762) at org.jboss.verifier.strategy.EJBVerifier11.checkEntity(EJBVerif ier11.java:121) at org.jboss.verifier.BeanVerifier.verify(BeanVerifier.java:135) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:445) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:374) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:305) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:495) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye r.java:473) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) at [snip] In this test run, I started the tests a little early: After server startup was finished, but before the autodeployer was done deploying the default rars. Here the autodeployer seems to hang with the following stack trace: AutoDeployer prio=1 tid=0x48d8c090 nid=0x5816 waiting for monitor entry [0xbc3fe000..0xbc3ff8c4] at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries.java:278) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:145) at org.jboss.system.URLClassLoader.loadClass(URLClassLoader.java:151) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at org.jboss.deployment.DeployerMBeanSupport.recursiveUnpack(Depl oyerMBeanSupport.java:551) at org.jboss.resource.RARDeployer.deploy(RARDeployer.java:166) at org.jboss.deployment.DeployerMBeanSupport.deploy(DeployerMBean Support.java:117) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) at
RE: [JBoss-dev] JINI - JavaGroups - Whatever: real issue?
Hi, A client (whether an application or server) should be able to auto-discover the EJB proxy object anywhere in the network. This seems to be Jini's strength. Regardless of the discovery process, if I am making a call on this proxy and the server is no longer available, the *proxy* should reconnect to another server in the cluster. This should be this transparent to the user. This is possible also in Jini, via the LookupCache. The trick is the transparency for the client that should only do new InitialContext().lookup(foo) and obtain the fail over proxy for the EJB. I'm working on this part for a project (that unfortunately doesn't involve JBoss, but is very similar to it, albeit waaay simpler), and it seems to me there are 2 ways, using Jini: - rewrite JNDI on top of Jini - use Rickard's smartworld proxies (and I'm not sure if this will require the former bullet, still investigating) Don't know JG, but how do you (Bill, Sacha) plan to share the server state among nodes ? Remote events ? JG specific stuff ? Regards Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] JBoss 2.4.0 on Tru64 Unix machine follow up
Hi, David, get a real VM LOL, yeah, now we will have the HP JVM on HP Unix, THOSE sigsevs may be more interesting ;) Do HP have a JVM for its Unix at all ? Someone knows ? Ah, well, life is change (TM) simon @compaq.com (to be read @hp.com) |Here is the segmentation violation error (dump) that I'm getting when |trying to start up Jboss 2.4 on a Unix Tru64 machine. |Any help or suggestions would be appreciated. Thanks. [snip] More seriously, which JVM which version of Tru64 ? It always happen ? If it's reproducible, then you can file a bug for Tru64 engineers, drop me an email if you can't find them Simon ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] NO PROBLEM IN CACHE i tell you READ YOUR CODE (to myself)
Hey Vincent,
glad you solved your problems, and that was not a cache problem ;)
Do you mind to send an email to jboss-user (since I guess many there use
ejbdoclet, have seen the cache has problems and are not subscribed to
jboss-dev) briefly explaining what you have found ?
Many thanks
Simon
This ejbdoclet gives me la puce a l'oreille.
The problem comes from ejbdoclet.
Of course.
Why can I never finish something...
The problem comes from how hashCode is calculated by ejbdoclet :
public int hashCode()
{
int _hashCode = 0;
if (_hashCode == Integer.MIN_VALUE)
{
_hashCode += this.pk.hashCode();
}
return _hashCode;
}
With _hashCode being defined as private :
private int _hashCode = Integer.MIN_VALUE;
If you change that to
transient private int _hashCode = Integer.MIN_VALUE;
The problem disappear. No need toString().
If you follow my thread, you can understand what I am talking about.
It should have been clear from the beginning :
if (problem_in_the_cache == true)
{
while (pk.getClass().getMethod(hashCode).isFuckedUp())
{
pk.getClass().getMethod(hashCode).print(BOLD
ARIAL SIZE=60);
pk.getClass().getMethod(hashCode).debug();
}
}
That was a good one.
Oh yes a good one, believe me two months telling the world
Cache in Jboss is
bad. Shame on me.
jboss-developement.getUser(Vincent Harcq).banish();
Vincent.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Vincent Harcq
Envoyé : vendredi 6 juillet 2001 9:06
À : [EMAIL PROTECTED]
Objet : RE: [JBoss-dev] Any problems vith the cache in 2.4?
Can you try this:
1. Solution 1
Add a toString to your PK (hack entitypk.j).
Also put your Cache size very high.
And your overager periods very high as well.
2. Solution 2.
Set your cache size to 1/1 (min/max)
Let us know please.
Vincent.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De
la part de
Lennart Petersson
Envoyé : jeudi 5 juillet 2001 11:55
À : jBoss Developer
Objet : [JBoss-dev] Any problems vith the cache in 2.4?
Ok, please dont hang me, not now :-) I know that i'm not given
you much details and no clean and short testcase but i still
wanted to trigger your brains to give me some advice of how to
preceed my debugging.
Fact: Using CVS brancs 2.4 from 2001-07-04. CMP entity beans,
commit option A, tuned updates, using isModified() method, using
EJBDoclet code generator (still on 0.95 with some newer patches
incorparated - like ejbPassivate() bug). Alwasy using a stateless
Session Bean in front of the Entity Bean. All session bean
methods that will result in a db update has TX_REQUIRED. All
other session bean methods as TX_SUPPORTS. Oracle database and
standalone clients.
Problem scenario 1:
A) Populates a GUI table with data originating from a findAll().
B) User selects one row and details about that entity is looked
up using a findByPrimaryKey()
C) User change some attribute and this _IS_ stored in database
D) User returns to the GUI table wich is repopulated using a
findAll() --- Old value is seen
E) User selects same row again details about that entity is
looked up using a findByPrimaryKey() --- Correct vallue is seen
F) Restart client, still old value in GUI table using findAll()
but correct value in details frame using findByPrimaryKey.
G) Restarting JBoss, now correcte value in both cases.
When i'm debugging JBoss i can see that the findAll in D) is
getting old values from the cache.
If i change cache sizes to min=1 and max=1 the problem i no more!
Should i take this for a evidence of JBoss bug rather then a bug
i our code?
Please note that if i'm doing a test bean and a short testcase
for this scenario then i can't reproduce the error. Which as
opposed to above makes our app more guilty or?
Problem scenario 2:
A) Viewing details from an entity in a GUI.
B) Waits until the server has been idle from some hour or so.
C) Trying to view details from this same entity again --- Now
incorrect values are seen.
This one i've not debugged att all. Guess that during B) beans
are passivated due to them being out aged. Also please not that
in this case the session bean in front of entity beans is a
stateful bean.
Are there anny know problems with caches/pools in JBoss 2.4?
Are there any mysterios behavior noted by someon but not yet
traced down?
Also a bit off-topic: I'm using Bugseeker to debug my code and
JBoss. Running on a P3 800 with 512 in memory and it is fu...ng
slow!!! What are you using as a debug tool? I'm attaching to
JBoss JVM as a remote process but still on same machine, guess i
will have better performance if Bugseeker is
RE: [JBoss-dev] new Threads.java (cache bug tests) is incomplete.
Hey Bill,
Sorry to chime in so late(we had a launch party for our
service built upon
JBoss!)
Great !
I wasn't saying that you shouldn't protect the cache or the
context, but for
cache.release(ctx), again, why schedule the passivation? Why not just
passivate it.
public void release(ctx)
{
synchronized(getCacheLock())
{
Object id = getKey(ctx);
if (canPassivate(ctx))
{
if (getCache().peek(id) != null)
{
getCache.remove(id);
}
passivate(ctx);
}
}
}
The above code protects the cache, but doesn't add the complication of
another thread to do the passivation. Simpler code. Maybe
I'm missing
something. The above code protects a concurrently accessed
bean from being
passivated, doesn't it?
Well, you're right: simpler code.
For commit C you add the passivation time to every invocation (even if it's
small).
Furthermore, allows setting the passivation thread to a lower priority than
the invocation thread, reducing cache contention due to passivation.
Anyway it's an interesting point to debate, if it's worth removing the
complexity and loose some speed, or not.
I'll think some more on it.
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new Threads.java (cache bug tests) is incomplete.
Hey Bill, Still, for Stateful beans, you're adding complexity for the time between when the Stateful bean gets scheduled for passivation, and when the Passivator Thread actually runs. Which is only a few milliseconds, right? If the Stateful bean is scheduled for passivation, this usually means that it has timed out. It seems with the unscheduledPassivation stuff, what you're really doing is just extending the configured timeout period. So why schedule passivation? Just do it. Am I making any sense here? Say you have a stateful bean, it gets out of the cache (which will happen both in case of timeout and because is kicked out by other instances inserted in the cache) and before being passivated a request for it comes from a client. If I go on with passivation and create another instance, I will end up with a passivated state in the filesystem and a cached state in memory. The client now calls remove() (that removes the new instance from the cache) and then a method: a bug in the client code of course, but since there is a passivated state on the filesystem, it will be activated again... Makes sense ? Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new Threads.java (cache bug tests) is incomplete.
Hi, that needs to be synchronized and simone does it in 2 steps... again I thought that was actually quite all right if not downright elegant with the entity symetry... (he did do somethings right) [snip] Ah, well, thanks ! Marc, since you get rid of the pool, do you use WaitSemaphore to wait/notify or you wait/notify on the context ? That was a pain when I worked on it, but I believed the pool was somehow necessary for performance, didn't want to remove it, and had a lot of troubles with those reused instances, especially in case of exceptions. Beware of: 1-Thread1 gets ctx and enters sync code in EII 2-Thread2 gets the same ctx and waits 3-Thread3 gets the same ctx and waits 4-Thread1 gets an exception, removes the ctx from the cache, must notifyAll instead of notify. And also: 1-Thread1 gets ctx and enters sync code in EII 2-Thread2 enters sync code in EII *before* Thread1 has arrived to the point that the tx is set on the ctx in ContainerInterceptor (set/getTransaction must be really synchronized even if they act on references, otherwise other threads may not see updates, the Java Memory Model sucks). 3-Now you are LOCKING-WAITING (CONTEXT) but should really be LOCKING-WAITING (TRANSACTION), be sure to notify correctly. You probably already saw these, just wanted to help. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Logging Cache Hits
Hey Vinay, There is no way to track cache hits, but there is the possibility to track cache misses (and almost every other cache activity). You have to set the BeanCacheJMSMonitoringEnabled flag to true in the container factory MBean (jboss.jcml), and then write a client that listen for the wanted messages on the beancache topic. See the 2 jars in dist/bin (sources are included) for monitoring the cache using JMX and/or JMS (beware that may be out of date, especially the JMS one, because of topic name changes). See also the code in AbstractInstanceCache and LRUEnterpriseContextCachePolicy for JMS messages sent on cache activity. Hope helped, Simon -Original Message- From: K.V. Vinay Menon [mailto:[EMAIL PROTECTED]] Sent: lunedì 4 giugno 2001 13:07 To: User @ JBoss; Dev @ JBoss Subject: [JBoss-dev] Logging Cache Hits Hi, Does anyone know how to turn on cache hit tracking in JBoss without recompiling the code!? Is this possible? I am trying to stress JBoss to about as far as it can get [it has not yet fallen over!!! ] but the time for queries seem a bit odd. I have large intial retrieval times and then they fall off [as expected I guess dues to cache hits - want to confirm this though]. But I do get spikes in the middle [probably because the number of beans has reached a stage where passivation kicks in]. What I'd like to know is whether successive queries actually hit the database or work [as promised] by hitting the cache even under very high loads. I am testing with about 1 client threads hitting the application server any where between 10milliseconds to about 1000 milliseconds on a huge Tru64 box. The queries could return 1,15,150,1250 records depending on the type of client. The underlying table has about half a million records and is an Oracle 8i database. Regards, Vinay ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Catalina and Jboss2.2.1 InitialContext error
Vincent, Is someone in touch with the Tomcat Mailing List ? Otherwise I'll register and explain the problem. Please, yes. Any other thoughts ? I thought we could tried with another ejb container (wl for example) to be sure the problem does not come from the jnp module, but I don't have wl installed myself. Well, I'm having this problem and I'm not using JBoss, but another application I wrote, so I guess that's a Catalina problem. I keep you informed about. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Option D - Take One !
Hey Vinay, [please plain text email] Hello Folks, Took a wild shot at the Option D, timed cache invalidation. Have put it in a separate interceptor that sits before the EntitySynchronizationInterceptor and invalidates the EntityEnterpriseContext at regular preset intervals. I would have written a simple TimerTask in a LRU cache policy, as I've done for the stateful bean removal. The issues (entity beans invalidation and stateful beans removal) are very similar, aren't they ? 1. There is an invalidation timer task per entity bean [I persum per-EntityEnterpriseContext maps to per bean and not per bean instance] I saw you use java.util.TimerTask. I reimplemented them because in the early days we wanted to be compatible with jdk1.2.2, and these classes were added only in JDK 1.3. I don't know if this constraint is still there (running the server in a 1.2.2 JVM) but... 2. The refersh rate is currently set at 60secs but could be moved elsewhere to the jboss config xml OK 3. The Configuration Metadat now has an entry for option D. OK 4. The interceptor does NOT reload the entity. It just invalidates the cache. The entity reload is managed by the EntitySynchronizationInterceptor. YES Does anyone want to go thru this and get back to me? As I've pointed out I would have written it with a org.jboss.util.TimerTask in a LRUEntityContextCachePolicy subclass. In there I would have locked the cache, walked all the cached context and call setValid(false) on them, more or less like in the LRUStatefulContextCachePolicy. What do you think ? Cheers, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] RE: Option D - Take One !
Marc, Simone, really, this is not a cache decision, AT ALL. The state synchronization is the state synchronization with the DB, it is a different domain. The cache should not, does not, will not take state synchronization decisions with respect to the database. It is a store with passivation policies. It will decide about its passivation policies, i.e. it's memory management, but certainly not how to refresh the state from db and to answer a question you posed earlier, no, the state sync and the LRU algo are not the same. I see your point, agree. I probably jumped into this class exercise without thinking about it too much, it seemed simpler the other way, but at the end semantically wrong. Finally (between us) let's try to focus on that one-thread busy wait problem (the one that gives the LOCKING WAITING) I took privately with you yesterday before we make this piece of code unecessarily complicated ;-) In clear let's fix the problems with the current cache before we touch the other interceptors yeah? sorry to be violent, No problem, why then I nicknamed you grumpy JBoss ;) ? it is just that in *every* interceptor I have looked at there is tons of work to be done, sometimes to make it just work. Cheers, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] TODO List on SourceForge
H, our grumpy JBoss is back, and what a comeback !!! Marc, I'll suggest you to add TODO tasks on the sourceforge site, so that it's easier to keep track of them, I would have added the ones you mentioned here, but probably I don't have the admin privileges to add TODO tasks. See http://sourceforge.net/pm/?group_id=22866 BTW, they are (till now): 1) URL JMX Installation 2) JBoss CMP Fast 3) Deployer 4) Commit option D 5) Transaction Isolation level 6) In memory CMP store 7) jboss.properties 8) General code cleanup, including o TPC importer and MI o Container factory CLs o ServiceControl and Jetty-JMX easy integration (as well as JSR 77 start/stop lifecycle interface) o ConfigurationService and the byte[] bug (solved perhaps ?) o Main.java and URL reading of MLets (related to bullet No 1, yes ?) Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss+Tyrex
Hey Anatoly, Hello, people I have spent the last few days stomping out the bugs from my plugin to get Tyrex DTM to work together with JBoss. I am happy to inform you that it seems to be working just fine. I'll cleanup the code from my debugging messages and it is ready for commit. I've tested this beast with PetStore running in several deployments including a scenario that involves distributed transactions and checked that my mods to Interceptors don't break the current TM. I know that this testing is not exhaustive, so, should I still branch or commit into the main tree? IMHO, would be fine to have it on the main trunk, you can benefit of the testing that all the ones that checkout the latest code will do. Also I think that release 2.3 is somewhat far from now, given also the TODO list that Marc pointed out. Of course you can always commit to a branch and merge later, but even then you cannot be 100% sure that there are no bugs, so... Since now there is a stable branch, people know they can checkout from the main trunk dynamite code that doesn't work; so just tag the current code on the main trunk, then commit your changes. If your code is broken, people can always checkout a freezed 2.3 before your changes. Any other thoughts ? Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] JavaOne T-shirts
Just curious if anyone is going to be going to JavaOne this year? I will. Hey Marc, what about the T-shirt idea that came up some months ago ? Anyone still interested ? I thought that maybe it is possible to arrange few of them and marketize them at J1 (yo, as you may have noticed I'm not a marketeer (- marketing man), as will probably be thousands of people at J1, just brainstorming :). Why not organize a 'JBoss-day' at J1, something on the beach maybe ;) ? Ah well, that's enough for today, here is holiday and I've just woke up, gears grinding in my head, see ya lata... Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] JavaOne
Hey, Party on the beach? what party on the beach? No party ? U !!! try forced marches in the morning, brain excercise for lunch, 120 pushups in the afternoon, endoctrination for dinner, and rifle manipulation at night... Marc, but this is normal life !!! I got bored of marches, pushups, hard coding, etc, etc ;) Let's party !!! or you think we run this revolutionary group on Peace Love and good Code alone ? well, yeah, we do... :) :)) marc BOF: Birds Of a Feather, the technical sessions in the evening. You coming simone? who's coming? I will come to J1. Need to register for this BOF ? Never been to J1, and there no mention of these BOF anywhere (unless I missed them), as I guess yours will not be the only one. If registration is needed, count me in. After it, we'll go party ! Party ! Party ! Party ! LOL ! Simon |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Wednesday, April 25, 2001 8:57 AM |To: '[EMAIL PROTECTED]' |Subject: R: [JBoss-dev] JavaOne | | |Hey, | | We are giving a BOF, mandatory presence for all those on this | list, free | tshirts | |What's BOF ? | |Oh, and the party on the beach ;) ? | |Simon | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] JavaOne
Hey, We are giving a BOF, mandatory presence for all those on this list, free tshirts What's BOF ? Oh, and the party on the beach ;) ? Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Distributed Transaction Manager support (coming up)
Hey, Anatoly Akkerman wrote: Hi, For the past couple of weeks I've been integrating Tyrex DTM (tyrex.exolab.org) into JBoss. Things are coming along and in a few days I'll probably have a basic support for transaction propagation across 2 JBoss instances. I was wondering, how should I make my mods available (the code is really alpha) for the people who want to start working on it. The code also requires changes to the current JBoss implementation (in particular, TxInterceptorCMT and TxInterceptorBMT would rely on javax.transactions.TransactionManager interface to manage transactions, instead of using JBoss extensions to the API for thread association/disassociation. Try to drop an email to Ole Husgaard, I know that he also has a DTM working and well tested, just to avoid that tomorrow also him will commit his changes ending up to have 2 DTM, maybe incompatible WRT the changes to TxInterceptors. If it breaks things, you might want to create a CVS branch. Definitely do create the branch. Something like: cvs rtag Tyrex_BP jboss cvs rtag -b Tyrex_Branch jboss Then: cvs co -rTyrex_Branch jboss Then, put your changes in and commit. Later, when it's all working, you can do: cvs co jboss cd jboss cvs update -jTyrex_Branch and you should get an automated merge (which you'll need to fix manually). Unless I've screwed the whole concept up completely. Perhaps a resident CVS guru would care to comment? Toby, no comments, it's everything OK :) Anatoly, just be sure to know how CVS merge works before updating with -j option. Drop me an email if you're not sure. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] Distributed Transaction Manager support (coming u p)
Hey, I had an e-mail message exchange with Ole about a month ago. He recommended me using org.jboss.tm.plugins.tyrex for my stuff. This is exactly what I did. But, as I mentioned, there are 2 files (the transaction interceptors) that need to be changed to support a generic TransactionManager. Again, this change was discussed with Ole and he felt it was a necessary step. I'll try to sync with him before I commit anything into CVS, especially the interceptors. Another thing, I did have rw access on the old CVS repository but most likely I don't have it on sourceforge. Who should I get in touch with? You should first add yourself as a sourceforge member, then ask Marc, Juha or Sebastien (the administrators) to add your newly created sourceforge account to the JBoss project as developer. Also few documentation to read about CVS and SSH, and about the sourceforge protocol used to commit new changes (basically track them in the changelog and feature request pages). HTH, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] How do i get the source code for jBoss
Hey, Hi , I want to get the source code for jBoss server. To do this I downloaded and installed winCVS - but then what is this tcl and how do I further get to the source coede?? Asking WinCVS question on this list does not help. Try the WinCVS web site, for example. Then follow the clear instructions on the JBoss' SourceForge site. And please, for support post to jboss-user, this is the development list. Simon Cud someone please help?? Thanks and regards harish ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBoss/JBossMX
Title: JBoss/JBossMX [CC'ed to jboss-dev] Hello Mads, quoted from the JavaMail 1.2 FAQ: Q: Is the JavaMail API implementation completely free? Can I ship it along with my product?A: Yes. The current release of the JavaMail API implementation, is completely free and you can include it in your product. This release includes IMAP, POP3, and SMTP providers as well. Please do read the LICENSE and ensure that you understand it. The JavaBeans Activation Framework is also free for use under a similar license. Unless 'JavaMail API implementation' means the class files of the JavaMail interfaces only (ie javax.mail.Session etc), so not including the real implementation (ie the code that opens connections to the mail server), I think we can ship mail.jar along with JBoss, anyway IANAL. I wonder if you'd like to open-source your implementation :) Thanks and best regards, Simon -Original Message-From: BJORNSBO Mads (BMB) [mailto:[EMAIL PROTECTED]]Sent: lunedì 23 aprile 2001 11:32To: Bordet, SimoneSubject: JBoss/JBossMX Hi Simone, I just read about the JBoss/JBossMX implementation, and I can see that you have used the Java Mail API 1.2 implementation from Sun. You probably already know this, but it is a reference implementation which is not meant to run on a 3rd tier. So, just to warn you if you don't already know. We use the same package here, but found that the implementation is insufficient and does not scale when using the IMAP part. Noumerous threads and TCP/IP connections are created not released properly. We contacted Sun to ask if they were aware of this, and they were, and they pointed out that the Java Mail implementation is "only" a reference implementation meant for the client tier. Basically, we re-wrote most of the package to incorporate thread pooling and TCP/IP connectionpooling. I hope this info is usefull. Best regards, Mads Bjoernsbo DISCLAIMER "This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by other persons than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer".Thank you for your cooperation.For further information about Proximus mobile phone services please see our website at http://www.proximus.be or refer to any Proximus agent.
RE: [JBoss-dev] Exception when calling a stateless from a stateful on jBoss2.2
Please, repost on jboss-user, this list will not answer these questions Simon -Original Message- From: Harishankar Nair [mailto:[EMAIL PROTECTED]] Sent: mercoled 18 aprile 2001 12:48 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Exception when calling a stateless from a stateful on jBoss2.2 Hi all , When I try to call a Stateful session Bean , which in turn calls a stateless session bean using jBoss 2.2 on windows 2000 , I get the following exception. Could someone help me out with this ?? My client is an ordinary java class. This exception occurs just when the stateful calls the stateless to get some work done. So could it be some jBoss configuration issue?? C:\jdk1.3\bin\java.exe Test2Client Working Directory - c:\EJBClient\ Class Path - C:\EJBStore\Test1;C:\jBoss\jboss-tomcat-2.2\jboss-2.2\client\e jb.jar;C:\EJBC lient;C:\jBoss\jboss-tomcat-2.2\jboss-2.2\client\jboss-client. jar;C:\jBoss\j boss-tomcat-2.2\jboss-2.2\client\jbosssx-client.jar;C:\jBoss\j boss-tomcat-2. 2\jboss-2.2\client\jnp-client.jar;C:\EJBStore\Test1\financial. jar;.;c:\Kawap ro5.0\kawaclasses.zip;c:\jdk1.3\lib\tools.jar;c:\jdk1.3\jre\li b\rt.jar;c:\jd k1.3\jre\lib\i18n.jar got object reference Home Interface casting done Daniel Step One thru Step Two thru And Step Three thru Step Four thru Step Five thru finished calling getMyName() - FinSt java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: Exception occurred; nested exception is: javax.ejb.EJBException java.rmi.ServerException: Exception occurred; nested exception is: javax.ejb.EJBException javax.ejb.EJBException at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer (StreamRemoteC all.java:245) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCal l.java:220) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.in voke(Unknown Source) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy.inv oke(StatefulSe ssionProxy.java:186) at $Proxy1.getMessage(Unknown Source) at Test2Client.main(Test2Client.java:49) Process Exit... Thanks and regards Harishankar Nair ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help With Exception: java.lang.NoClassDefFoundError: org/jboss/security/SecurityAssociation
Please repost to jboss-user, this list is devoted to development only, nobody will answer you. Simon -Original Message- From: Kevin James Baxter [mailto:[EMAIL PROTECTED]] Sent: mercoledi 18 aprile 2001 13:45 To: jboss Subject: [JBoss-dev] Help With Exception: java.lang.NoClassDefFoundError: org/jboss/security/SecurityAssociation Hello, everyone; Any insight would be greatly appreciated. I'm porting an existing application from jBoss 2.0 FINAL to jBoss 2.2. FINAL. Here's the exception I'm getting: Starting tomcat. Check logs/tomcat.log for error messages No webapps/ directory C:\local\forte4j\temp\tomcat\webapps 2001-04-18 07:36:00 - Ctx( ): Exception in: R( + /public_html/EmployeeViewPage.jsp + null) - javax.servlet.ServletException: org/jboss/security/SecurityAssociation at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:390) at org.netbeans.modules.web.core.execution.JspServlet.service(Jsp Servlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper .java:387) at org.apache.tomcat.core.Handler.service(Handler.java:263) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:749) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:695) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(HttpConnectionHandler.java:207) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoin t.java:403) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPo ol.java:498) at java.lang.Thread.run(Unknown Source) Root cause: java.lang.NoClassDefFoundError: org/jboss/security/SecurityAssociation at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.getPrincipa l(GenericProxy.java:184) at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomePro xy.java:231) at $Proxy0.create(Unknown Source) at gov.ssa.util.JNDIManagerAbstract.getEmployeeManager(JNDIManage rAbstract.java:34) at p_00025blic_0005fhtml._0002fpublic_0005fhtml_0002fEmployeeView Page_0002ejspEmployeeViewPage_jsp_0._jspService(_0002fpublic_0 005fhtml_0002fEmployeeViewPage_0002ejspEmployeeViewPage_jsp_0.java:99) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java:177) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:309) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:382) at org.netbeans.modules.web.core.execution.JspServlet.service(Jsp Servlet.java:75) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper .java:387) at org.apache.tomcat.core.Handler.service(Handler.java:263) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:749) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:695) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(HttpConnectionHandler.java:207) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoin t.java:403) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPo ol.java:498) at java.lang.Thread.run(Unknown Source) ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Nested JMX Service Groups...??!
Jules,
--- Scott M Stark [EMAIL PROTECTED]
wrote:
They can't create a wrapper because mbeans are being
created as a byproduct
of interaction with the Jetty JMX interface. This is
a generic issue with integrating
third party services that happen to be mbeans which
may be using the JMX bus
for whatever purpose. Its trivial to add a filter by
domain
that allows ServiceControl to not even attempt to
manage any mbeans in a given
domain. This does not break the JBoss management
model in any way that I see.
It simply adds the notion of non-service domains.
Yes !
Thanks Scott,
This is it.
How you choose to differentiate between JBoss Service
MBeans and 3rd party ones is what I think the
discussion should hinge upon.
Ehm, maybe I'm missing something but why the Vlada's solution isn't OK ? IE
modify the ServiceControl JBoss' MBean to check if the MBean belongs to the
JBoss lifecycle:
if (registration_notification
registeredMBean instanceof org.jboss.utill.Service)
{
list.add(registeredMBean);
}
Simon
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS client/ssh
Hello, Cool, I'm vindicated! When Simone imparts his knowledge, I'd be happy to update the web page if Marc thinks it a good idea... Thanks for that, would really be useful for developers with CVS write access, but I have very little time this period. I don't have cygwin, the following works with plain win2k and winme. Probably will be useful to remove cygwin's ssh.exe from %PATH% environment variable to avoid some mess. Unfortunately there is no solution yet for being behind a firewall, ssh does not work. If someone has a solution for this, please share it !! The following will only work for jboss' developers that have CVS write access to the CVS jboss repository. Sooo, here it is ;) 1) Go to http://download.sourceforge.net/sfsetup/sfsetup-v1.2.zip and download it. Unzip it. When unzipped, there is another zipped file, called ssh-1.2.14-win32bin.zip. Unzip also this in a well-known directory (mine is D:\Simon\ssh\). In there there should be now 5 files, one of them being ssh.exe. Only these 5 files should be kept, you can delete all the other unzipped files. 2) Create a passwd file under C:\etc as explained in bullet 5 at http://sourceforge.net/docman/display_doc.php?docid=767group_id=1. Follow only instruction at bullet 5. 3) Open a Windows console and go in the directory where you unzipped ssh.exe (I would do 'cd \Simon\ssh'). 4) If you don't have a global HOME environment variable, set it in the console. I would do 'set HOME=D:\Simon'. If you don't do this, ssh will complain (while executing the next step) that it cannot create the directory 'NULL/.ssh' or something like that. 5) Now connect with sourceforge. Type the following: ssh -l sf_user_name jboss.sourceforge.net and enter your password. You should get a unix-like after-login window. Type exit and come back to the Windows console. Then type: ssh -l sf_user_name cvs.jboss.sourceforge.net and enter your password. Again the unix-like after-login window. Type exit and come back to the Windows console. These 2 commands created a .ssh directory (please note the dot before ssh) under %HOME% and 2 files in it. These files are required by WinCVS. 6) Close the console. Open WinCVS. From the menu bar, Admin/Preferences. In the 'General' tab, set the CVSROOT to be :ext:sf_user_name@cvs.jboss.sourceforge.net:/cvsroot/jboss, authentication 'SSH server' 7) In the Preferences dialog, tab 'Ports', select the checkbox 'Chek for an alternate rsh name' and fill the textbox with the full path of ssh.exe (mine is D:\Simon\ssh\ssh.exe). Click OK. 8) From main menu bar, Create/Checkout module, fill the dialog box, then click OK. It will appear a minimized console (so you will only see it in the taskbar or with Alt-Tab): you should un-minimize it, it will appear completely empty. Type in there your sourceforge password and then enter. If you switch back to WinCVS, you'll see that the checkout begins, and the password console stays there until the CVS command is finished. You have to retype your password in an empty console for each CVS command (there is a way to avoid also this but I did not try it). Enjoy ! Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] 2.2 Patch procedure
Hey Scott, Ok, a problem mentioned on the user list turns out to be a bug in the 2.2 release of the JBossSX code. This was not seen because the login module used in the howto was not being convered in the unit tests(my fault). So, what is the procedure for creating a patch and new release on the 2.2 branch? I can tell you what to do in CVS, I'm not expert on how this must be handled in SourceForge using the tracker, anyway: Checkout the 2.2 branch: cvs co -rBranch_2_2 jboss Change what has to be changed (working on the files you just checked out) and commit the changes. Tag the branch with a new tag: the next available is Rel_2_2_1, so: cvs tag Rel_2_2_1 (from the jboss' module root dir) Here if you think that a new JBoss release (2.2.1) is truly needed, you can use the JBoss_2_2_1_Final tag instead of Rel_2_2_1. It really depends on how much important is the bug you fixed, and maybe a word of Marc about shipping a new release. If you have a doubt, use tag Rel_2_2_1, we can later rename it to JBoss_2_2_1_Final. CVS tags are very easy to add, delete, rename, etc, so better tag once more than once less. If a release is needed, you can now package everything again and upload to the web site (Oh, if someone finds the time, update also the main page that still refers to Rickard's 2.1 (beta) release, and maybe moving it in a more visible position, like at the top of the main page) Update also the main trunk: cvs up -A Change again the files (on this new working copy from the main trunk) applying the patch (or if you know well CVS you can merge the changes) and commit the changes. Hope helps, but if you have doubts don't hesitate to contact me. Cheers, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: R: [JBoss-dev] 2.2 Patch procedure
Hey Toby, I can tell you what to do in CVS, I'm not expert on how this must be handled in SourceForge using the tracker, anyway: Checkout the 2.2 branch: cvs co -rBranch_2_2 jboss Change what has to be changed (working on the files you just checked out) and commit the changes. Tag the branch with a new tag: the next available is Rel_2_2_1, so: cvs tag Rel_2_2_1 (from the jboss' module root dir) I'm going to need to do this shortly as well, and I just want to be sure that I understand. What is the purpose of this tag? Its purpose is to allow easy merge of the patches commited to the branch with the code on the main trunk. Also, later on, when the branch and the main trunk have developed several new revisions, it will be easier to check if all the patches went to the main trunk. I'm finishing a detailed document about merging, when I'm done I'll post it, few days more :P Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] 2.2 Patch procedure
Hey Scott, The code that needs to be patched is actually in the jbosssx cvs module. I did add a JBoss_2_2_0_Final to the code in this module at the time of the 2.2 release, but I did not make a branch. Would this work: cvs rtag -b -r JBoss_2_2_0_Final Branch_2_2 jbosssx OK co -rBranch_2_2 jbosssx You just missed the 'cvs' before 'co' but it's OK. Then you can commit the changes to the branch AND the main trunk of jbosssx module. After that I suppose you will have 2 new jars for the jboss module, one for the branch and one for the main trunk, so refer to previous indication on how to commit them. I think that tagging with Rel_2_2_1 at least jboss module would be useful. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JMX in jBoss, Clustering, Monitoring, Failover, better bootstrapp ing via pluggable XMLet
Just one word: IMPRESSIVE ! Simon -Original Message- From: Stacy Curl [mailto:[EMAIL PROTECTED]] Sent: venerd 6 aprile 2001 11:59 To: '[EMAIL PROTECTED]'; 'Andreas Schaefer' Subject: [JBoss-dev] JMX in jBoss, Clustering, Monitoring, Failover, better bootstrapp ing via pluggable XMLet Hello, I'd like to tell you about the code that I've developed and contributed to JBoss. I've developed some code to augment the basic capabilities that JMX gives you. I've written an MBean that will 'mirror' MBeans, that is it will take a subset of MBeans on one JMX agent and create proxies for them on another JMX agent (the idea of proxying is wide place but the inspiration for this instance was taken from the CascadingAgent from JDMK). Secondly I've created a 'Watchdog' MBean that monitors the health of 'Watchable' (*) MBeans and calls restart on the watchable MBeans when they have failed. I've also wrapped the JMX agent in an RMI Activatable object so that the whole JMX agent itself can be restarted (also by the Watchdog) in the event that JVM dies. (*) Actually they are called 'startable' and should be renamed to 'watchable'. I've also rewritten the MLet loading class as a pluggable XMLet loading class, using this method I've been able to specify in the XMLet resource file which MBeans are critical (failure to start means the JMX agent is useless) to optional (failure to start leaves the JMX agent still functional). The stuff I wrote can be found at http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/jbossmx/?cvsroot=jboss I wrote all of this not out of the goodness of my own heart but because my company needed the capability to monitor and restart its Java code, the Java code needed absolutely to create threads and so couldn't be written as EJB, so I had to devise a skeleton failover / high availability system outside of an app server. Fortunately my company doesn't ever plan to go into the failover / monitoring business so they were comfortable with me placing the code in JBoss. This also means that I'll be adding more features to JBoss in the future and getting paid for it :). Of course this point is moot if those features are not interesting to the JBoss group. Since JBoss is based on JMX and will in the near future have a number of JMX Agents to enable clustering of the EJB Containers then monitoring of these Agents and containers seem crucial, there is much work to be done but I think that my code should serve as a reasonable base. Ideas for the future: - Have multiple JMX Agent (got), but specify a single XMLet resource file, let the MBeans be distributed evenly across the Agents, this is called a Single System Image (SSI JMX) - Offer different styles of monitoring, currently it's poll based, could use a 'dead-man's handle', or pure event based monitoring, combinations also possible. - Are there parallels between JMX and RMI, there is an RMIRegistry, does it make sense to have a JMXRegistry and access the MBeans through URL's ? jmx://machineName:agentName/domainName/objectName or jmx://agentName/domainName/objectName, or in conjunction with the SSI JMX: jmx://domainName/objectName - Current system offers emails when corrective action is taken on a failed MBean, future system could monitor performance and email on crossing critical boundaries (90% maximum I/O, memory, etc). - Can only send emails to support staff at present, other possibilities may be useful such as sending pagers. - Can only see (in the HTML view) the current state of the system, it would be useful to be able to run through a movie of previous states and also highlight differences. - The HTML view is quite minimal, I've created a pluggable version which enables MBeans to specify somewhat their display, this can be improved significantly which will aide support staff. --- Brain Dump ENDS -- Regards, Stacy. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
R: [JBoss-dev] To EJB or not to EJB?
Please post again on jboss-user. This list is devoted to JBoss development only. Thanks, Simon -Messaggio originale- Da: David McTavish [mailto:[EMAIL PROTECTED]] Inviato: gioved 5 aprile 2001 19:54 A: [EMAIL PROTECTED] Oggetto: [JBoss-dev] To EJB or not to EJB? That is my humble question. Here is my problem: I have a software component that models our physical hardware. I need to be able to persist this model to maintain its state. I also need to ensure that all transactions are atomic. However, I also need to incorporate JMX-related management. Thus, I need the persistence and transaction models implemented by EJB's, but the management capabilities exposed by JMX. Does JMX support container-managed persistence? Does JMX support the JTA/JTS implemented transaction system? Does JMX support dynamic instantiation? (ie: If I add a new entry to the jboss.jcml file (new MLET tag) and register with the MBeanServer, will the MBeanServer start that new service? Also, will the MBeanServer support multiple instances of the same "service"? Any answers would be greatly appreciated. Regards, David McTavish ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 2.2 FINAL
Hello, it's clear that the board wants to exit with 2.2 FINAL, since every one involved in packaging wants to checkout the most updated code in the branch to package a final 2.2 release. So, I ask to every committer to stop committing to Branch_2_2 starting from 18:00 GMT (13:00 New York). I will then tag the branch with Rel_2_2_FINAL, so that packagers may checkout the 2.2 FINAL code to package the various JBoss distributions (ie JBoss-Jetty, JBoss-Tomcat, etc). I will also post instruction on how to checkout the 2.2 final release. plgc, Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: JBoss 2.2 FINAL. And the tests ?
Hey Ken, What's the test plan for this release? I don't know. AFAIK 2.1 is far better than 2.0, and passes more (if not all) tests of the JBossTest suite, I think also the Peter Braswell's CTS. But it's a good question. Anyone may answer better than me ? Marc ? Simon -- Ken Jenks, http://abiblion.com/ Tools for reading. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: JBoss 2.2 FINAL. And the tests ?
OK. The timeline of 18:00 GMT is confirmed. Simon -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: mercoled 4 aprile 2001 16:09 To: Bordet, Simone; JBoss Development Mailing List (E-mail) Cc: 'Ken Jenks' Subject: RE: [JBoss-dev] RE: JBoss 2.2 FINAL. And the tests ? OK 2.2 is really of FINAL quality. We have been really in a effective BETA for the past 3 month and I don't see people complaining on major stuff. The test situation is a bit more complex. JCTS has come a long way. JBossTest had things that made deep tests (the home.create(objectref)) that do not lend themselves to "UNIT" testing. 2.0 used to pass ALL of the jbosstest stuff and from what I can tell the problems we are seeing now are mostly from configuration of jbosstest. 2.2 is of FINAL quality, put it out already, it is hurting us. We need to move onto 2.3.. marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Wednesday, April 04, 2001 8:48 AM |To: JBoss Development Mailing List (E-mail) |Cc: 'Ken Jenks' |Subject: [JBoss-dev] RE: JBoss 2.2 FINAL. And the tests ? | | |Hey Ken, | | What's the test plan for this release? | |I don't know. AFAIK 2.1 is far better than 2.0, and passes more |(if not all) |tests of the JBossTest suite, I think also the Peter Braswell's CTS. | |But it's a good question. Anyone may answer better than me ? Marc ? | |Simon | | | -- Ken Jenks, http://abiblion.com/ | | Tools for reading. | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Transaction timeout
Hey,
look in jboss.jcml and almost at the top there is the transaction mbean. You
will find there the transaction timeout value, that overrides the one in the
code.
Simon
-Original Message-
From: sujith s.pillai. [mailto:[EMAIL PROTECTED]]
Sent: mercoled 4 aprile 2001 21:48
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Transaction timeout
Hi,
I am not sure whether this is the right forum for
posting this doubt. I have already sent this to jboss
users' forum. Sorry for the cross-posting.
I am running JBoss 2.1 alongwith Jetty 3.0.2 / JDK
1.3.
We have a stateful session bean running with bean
managed transaction. It has got the transaction
boundaries set as follows:
getFirstName() is where the transaction is initiated
by UserTransaction.begin(). In getNextName(), the
transaction is committed by UserTransaction.commit().
Now, the two methods are invoked by two different
servlets. When the user calls the first servlet, it
calls the bean's getFirstName() method, and fetches
the values for us. When the user clicks on the "Next"
button on the form, the second servlet is invoked, and
it calls the bean's getNextName() and fetches the
required values; and commits the transaction.
Our problem is, when the user invokes the first
servlet, and then, chooses to remain idle for more
than 5 minutes, the transaction gets timed out, and
then, if we try to invoke the second servlet, it gives
a RollbackException in the getNextName().
This is because the org.jboss.tm.TxManager class has
got the timeout value hard-coded in it as :
START OF JBOSS SOURCE CODE-
/**
* Default timeout in milliseconds.
* Must be = 1000!
*/
long timeOut = 5*60*1000;
END OF JBOSS SOURCE CODE---
Because of this, we cannot let the user remain idle
for more than 5 minutes.
However, our application, which is a conversion
project from AS/400, needs to have the timeout set to
a higher limit as in the earlier AS/400 version of the
application.
Can we change this timeout value in the
org.jboss.tm.TxManager class, without affecting
anything else?
Thanks,
Sujith.
Additional info:
From the org.jboss.tm.TxCapsule class:
JBOSS SOURCE CODE---
/**
* Create a new TxCapsule.
*
* @param tm The transaction manager for this
transaction.
* @param timeout The timeout for this transaction
in milliseconds
* (timeouts are not yet
implemented).
*/
TxCapsule(TxManager tm, long timeout)
{
this(tm);
status = Status.STATUS_ACTIVE;
start = System.currentTimeMillis();
this.timeout =
TimeoutFactory.createTimeout(start+timeout, this);
branchXids = new HashMap();
}
--END OF JBOSS SOURCE CODE
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 2.2.0 FINAL
Hello, I've tagged and updated the version identifier of JBoss on the branch, so that it is possible to checkout the sources to package the distributions, included last minute Scott Stark's changes. Packagers, see the how to below for instructions on how to checkout the 2.2.0 JBoss release. Simon How to: First of all be sure that your CVSROOT is set properly, should be :ext:[EMAIL PROTECTED]:/cvsroot/jboss where 'developer' is your sourceforge account. Command-liners can use the -d option to specify the CVSROOT, such as "cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss checkout jboss". Be very sure that the -d option is between the 'cvs' and any other command (in the case above 'checkout') WinCVS users have to specify it from the menu: Admin/Preferences. Then perform the following command: Command line: cvs export -rJBoss_2_2_0_Final jboss WinCVS 1.2: From the menu: Create/Checkout module Then enter 'jboss' in the editable combobox titled "Enter the module name..." and choose a folder to checkout to. Click on the "Checkout Options" tab. Select the checkbox titled "By revision/tag/branch" and enter 'JBoss_2_2_0_Final' in the editable combobox. Select the checkbox titled "Do not create the CVS directories (export)". Click OK. This command exports all the sources, i.e. it's a regular checkout but *without* the CVS directories. This command is (normally) used for packaging, since there is no interest in CVS directories for releases. This implies also that from that cvs-export you cannot work with CVS, ie commit changes, etc (you should use the regular checkout to work with CVS). Anyway with this command you can build JBoss, do tests, run it, etc: fully functional. So, use this command to cvs-export JBoss, build the distribution, package it, and that's it. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS suggestion
Hey, I don't know who is mantaining CVSROOT/* files (SourceForge or Marc or Sebastien), but would be useful to have email notification on tag operations also, through the CVSROOT/taginfo file. Simon ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: Small NPE annoyance in LRU cache
Marc, fixed in CVS. Simon -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: venerd 23 marzo 2001 18:35 To: Jboss-Development@Lists. Sourceforge. Net Cc: Bordet, Simone Subject: Small NPE annoyance in LRU cache When a bean doesn't pass the verifier it is "undeployed" and in our case the LRU cache barf an NPE. It doesn't look very good and probably has to do with some "non-initialized" field that is supposed to do some work. We can predictably say that people will screw their deployment and the error they get is container NPE which is confusing. Can someone take a look at it? No don't point the fingers back at me, I am running on the training. snip the bean fails (this happens for all failed beans) [J2EE Deployer Default] Starting BookStockBean.jar failed! [Auto deploy] java.lang.NullPointerException [Auto deploy] at org.jboss.util.LRUCachePolicy.flush(LRUCachePolicy.java:175) [Auto deploy] at org.jboss.util.LRUCachePolicy.stop(LRUCachePolicy.java:95) [Auto deploy] at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy.stop(LRU EnterpriseCont extCa chePolicy.java:112) [Auto deploy] at org.jboss.ejb.plugins.AbstractInstanceCache.stop(AbstractInsta nceCache.java: 358) [Auto deploy] at org.jboss.ejb.EntityContainer.stop(EntityContainer.java:260) [Auto deploy] at org.jboss.ejb.Application.stop(Application.java:212) [Auto deploy] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:362) [Auto deploy] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:275) [Auto deploy] at java.lang.reflect.Method.invoke(Native Method) [Auto deploy] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) [Auto deploy] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) [Auto deploy] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeploye r.java:435) [Auto deploy] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:178) [Auto deploy] at java.lang.reflect.Method.invoke(Native Method) [Auto deploy] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1628) [Auto deploy] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. java:1523) [Auto deploy] at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:358) [Auto deploy] at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:221) [Auto deploy] at java.lang.Thread.run(Unknown Source) _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
