Re: [JBoss-dev] JMSContainerInvoker.java
We can argue the details, but I agree with Peter about the current configuration being very difficult to manage. If we are going to move to a web based deployment to multiple boxes we won't be able to simply rely on URLClassLoaders pulling down the current config files and expect them to work as many configuration parameters will be specific to box on which the server is being installed. - Original Message - From: "Peter Antman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 11:30 PM Subject: Re: [JBoss-dev] JMSContainerInvoker.java > On 11 Jun, marc fleury wrote: > > what I am hearing is that you want jbossmq/jboss/servlet configuration in > > xml snippets in jboss.jcml, otherwise I don't see what it brings except yet > > another layer of indirection... > > > I guess it depends on you requirements. Mine is that I must be able to > support a lot of installations of JBoss on machines I do not have > complete controll over, such as ports, multihomed and such things. > > My experience from working with JBoss for almost a year now is that the > configuration files changes a lot al the time, and it is quite hard to > diff all these files all the time when a new release arrives, or when I > have to go cutting cvs edge ;-). > > It is much easier to have one central property files wich controlles all > those environment stuff (much like a preprocessor), just try to diff > standardjboss.xml with all those hardcoded > ! > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMSContainerInvoker.java
On 11 Jun, marc fleury wrote:
> what I am hearing is that you want jbossmq/jboss/servlet configuration in
> xml snippets in jboss.jcml, otherwise I don't see what it brings except yet
> another layer of indirection...
I guess it depends on you requirements. Mine is that I must be able to
support a lot of installations of JBoss on machines I do not have
complete controll over, such as ports, multihomed and such things.
My experience from working with JBoss for almost a year now is that the
configuration files changes a lot al the time, and it is quite hard to
diff all these files all the time when a new release arrives, or when I
have to go cutting cvs edge ;-).
It is much easier to have one central property files wich controlles all
those environment stuff (much like a preprocessor), just try to diff
standardjboss.xml with all those hardcoded
!
A local installation is therefore goverend by a template repository
(configuration files and a template propertyfile, where all environment
stuff is gathered). Here is my default for a vanilla JBoss installation.
# Default filter porperties for JBoss
java.rmi.server.hostname=#java.rmi.server.hostname=localhost
java.rmi.server.codebase=#java.rmi.server.codebase=http://localhost:8080/
java.naming.provider.url=#java.naming.provider.url=localhost:1099
jnp.port=1099
java.Xms=-Xms6m
java.Xmx=-Xmx128m
rmi.port=1099
rmi.object.port=
webservice.port=8083
hypersonic.port=1476
htmladapter.port=8082
topics=logging
queues=
mail.user=pra
mail.smtp.host=dagobert.annons.dn.se
[EMAIL PROTECTED]
# Tomcat Stuff
tomcat.http.port=8080
tomcat.Ajp12.port=8007
I need a customized install? I create a new template file and does
sh build.sh -Dtemplate.properties=alternative.file install
Say I have 10 installs with different configuratins. When I uppgrade
JBoss I do a check between the files in the template repository and
upgrade all changed configuration files. Then I just do an re install on
all machines with the local property file.
This was the best I could come up with to make installation and
upgrading of JBoss as smoth as possible.
Maybe its not the best there is, but it shure works better than without
it.
//Peter
ps
I actually think this would be great to have built in to JBoss, so that
all machine dependant parameters where configurable through a
preprosessor when installing JBoss, but that my 2c.
ds
>
> marc
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Peter
> |Antman
> |Sent: Monday, June 11, 2001 3:02 AM
> |To: [EMAIL PROTECTED]
> |Subject: Re: [JBoss-dev] JMSContainerInvoker.java
> |
> |
> |On 10 Jun, marc fleury wrote:
> |> |I do like simplicity of management (that why I redo every JBoss
> |> |distribution so I can configure it with a single property file - Ant,
> |> |copy and filter).
> |>
> |> what do you mean, what do you redo?
> |
> |Short example:
> |
> |>From jboss.jcml:
> |
> | |name="DefaultDomain:service=Naming">
> |@rmi.port@
> |
> | |name="DefaultDomain:service=JNDIView" />
> |
> |You see the @rmi.port@
> |
> |In a propertyfile, for example default.properties ;-)
> |
> |rmi.port=1099
> |
> |
> |Some stuff in build.xml:
> |
> | |value="${jboss.dir.templates}/default.properties"/>
> |
> |This may be reset dynamicaly with -Dtemplates.properties to use other
> |values for an installation.
> |
> |Turn on filtering while copying:
> |
> |
> | |todir="${install.dir}/server/conf/tomcat/">
> | |
> |includes="jboss.properties,jboss.conf,jboss.jcml,jndi.properties,lo
> |g4j.properties,jnp.properties,standardjboss.xml,jbossmq.xml,alertMa
> |il.properties"
> | dir="${jboss.dir.templates}"
> |/>
> |
> |
> |
> |
> |Makes it a snapp to install differently configured JBoss servers, just
> |write a new property file to make your installment from.
> |
> |I particulary like this in jbossmq.xml:
> |
> |bob
> |@topics@
> |
> |This is where I drive my destination configurations ;-)
> |
> |
> |>
> |> |
> |> |# Here some code
> |> |
> |> |set_my_variable(11);
> |> |print get_my_variable;
> |> |
> |> |What do you think one will get, yes 1. Do you get any warnings? NO. Is
> |> |it hard to debug? Oh, yes. Verry hard.
> |> |
> |> |I think automatic creation of destinations for MDB suffers the same of
> |> |problems.
> |>
> |> geez you guys are all banging on this feature... you know what?
> |>
> |> two peas in a bucket
> |>
> |> f*ck it! (as my father in law will say (deep south))...
> |>
> |> we will see if people complain
> |
> |Calm down ;-)
> |
> |>
> |> |What happens when a created destination is suddenly destroyed when the
> |> |MDB is undeployed (perhaps for a redeploy because of code change)? Well,
> |> |all publisher to that destination will bark and be gone (if they was not
> |> |coded to be failsafe). Suddenly we do not have a loosly coupled system
> |> |any more, but the destination becomes just another remote interface
> |> |against the bean (answer: use stateless
Re: [JBoss-dev] FW: Busy wait on one thread
On 2001.06.11 23:57:00 -0400 Georg Rehfeld wrote: > Hi David and Bill, > > David Jencks wrote: > > > I like your idea for optimistic locking, however I think generally you > need > > to check that -no- fields have been changed, not just the ones you > changed. > > These are two different behaviors, sometimes you want one and > sometimes > > the other, but I think as a default you are more likely to want the > -no- > > fields changed option. This is more like what versioning db's such as > > interbase/firebird do. > > May be you are right, the 'no fields changed' option will be > required sometimes or most, but then, my suggestion even allows > several clients to modify concurrently as long as they modify > different fields (and don't deadlock while the DB holds write > locks between update and commit, I said already, this only > 'mimickes', but is no true optimistic locking). > > Besides, the timestamp variant would resemble to the 'no fields > changed' behaviour with a shorter WHERE clause, but requires an > additional field in the DB (and might lead to 'race condition' > problems when 2 clients read and update within the same millisecond, > could be solved by versioning instead of timestamping). I suppose versioning could be done in the db with an update trigger and sequence(oracle)/generator(firebird/interbase). It seems like this is getting complicated... > > > Bill Burke said: > > > Really cool stuff! This can be easily implemented in CMP/JAWS > > since JAWS keeps the old state alive. > > Thanks, but it's not my idea, have seen it elsewhere I can't > remember just now. One place I saw it is in Borland Delphi, in which there are 3 cached update concurrency options, pk only, changed fields only (+ pk) and all fields. If one currently would implement that for > CMP/JAWS it would be of no big use for the average user of JBoss > running only one JBoss instance, since the container does lock > before the SQL is executing. Users of multiple JBoss instances > working on the same DB may benefit from it a little bit, when the > concurrent access is distributed to different JBoss instances. > > But when the 'rabbit' comes back to the surface in a few days > having 'multiple instances' hobbeling after him it might come > in handy to give them some 'food' to eat. > > So I would take the implementation of the mimicked optimistic > locking behaviour in JAWS, respecting both, the 'no fields changed' > and the more concurrent option [ignoring timestamping/versioning for > now] (also to continue my just established write access to CVS :-) > > If the maintainers of JAWS (or any others) think, I shouldn't do > that, please tell me. > > my very best regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > PS: don't expect me to be very quick, I've to look at a lot of > new stuff and my boss asks for some attention too. > > PS2: I'll certainly need some advice with the CVS version to > code/commit against, I think it should make it into the > 'RabbitHole' and the 'Branch_2_2'? Please to my gmx account to > not clutter the list (except you think, the explanation will > help others too). > > > > ___ > 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] FW: Busy wait on one thread
Hi David and Bill, David Jencks wrote: > I like your idea for optimistic locking, however I think generally you need > to check that -no- fields have been changed, not just the ones you changed. > These are two different behaviors, sometimes you want one and sometimes > the other, but I think as a default you are more likely to want the -no- > fields changed option. This is more like what versioning db's such as > interbase/firebird do. May be you are right, the 'no fields changed' option will be required sometimes or most, but then, my suggestion even allows several clients to modify concurrently as long as they modify different fields (and don't deadlock while the DB holds write locks between update and commit, I said already, this only 'mimickes', but is no true optimistic locking). Besides, the timestamp variant would resemble to the 'no fields changed' behaviour with a shorter WHERE clause, but requires an additional field in the DB (and might lead to 'race condition' problems when 2 clients read and update within the same millisecond, could be solved by versioning instead of timestamping). Bill Burke said: > Really cool stuff! This can be easily implemented in CMP/JAWS > since JAWS keeps the old state alive. Thanks, but it's not my idea, have seen it elsewhere I can't remember just now. If one currently would implement that for CMP/JAWS it would be of no big use for the average user of JBoss running only one JBoss instance, since the container does lock before the SQL is executing. Users of multiple JBoss instances working on the same DB may benefit from it a little bit, when the concurrent access is distributed to different JBoss instances. But when the 'rabbit' comes back to the surface in a few days having 'multiple instances' hobbeling after him it might come in handy to give them some 'food' to eat. So I would take the implementation of the mimicked optimistic locking behaviour in JAWS, respecting both, the 'no fields changed' and the more concurrent option [ignoring timestamping/versioning for now] (also to continue my just established write access to CVS :-) If the maintainers of JAWS (or any others) think, I shouldn't do that, please tell me. my very best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: don't expect me to be very quick, I've to look at a lot of new stuff and my boss asks for some attention too. PS2: I'll certainly need some advice with the CVS version to code/commit against, I think it should make it into the 'RabbitHole' and the 'Branch_2_2'? Please to my gmx account to not clutter the list (except you think, the explanation will help others too). ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Reason for abstract methods in jboss-j2ee
>From the Java Language Spec, interfaces and their methods are implicitly abstract, so it doesn't matter whether you mark them as abstract or not (though Sun recommends doing so and most people never do). tim > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Monday, 11 June 2001 22:22 > To: 'Jesper Pedersen '; '[EMAIL PROTECTED] ' > Subject: RE: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > > Not from the point of view of how things work. Interfaces are always > abstract. I am pretty sure that is the way sun declares them > which is why > we did them that way first time. > > Javadoc certainly won't hurt. > > By he way Marc F, Jesper did the first pass of EJB 2.0 support for the > jboss-j2ee project so he's been contributing... > > Cheers > > -Original Message- > From: Jesper Pedersen > To: [EMAIL PROTECTED] > Sent: 6/11/01 2:39 AM > Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > Hi. > > Is there a reason for declaring the interface methods in > jboss-j2ee for > abstract ? > > If not I'll clean it up and add JavaDoc ;) > > Cheers, > > Jesper > > -- > Jesper Pedersen, M.Sc. C.S.E > Open Source Solution Manager > > Sun Certified Java 2 Developer > > IT+ A/S Phone: +45 86 78 21 00 > Brendstrupgårdsvej 7 Fax: +45 86 78 21 02 > 8200 Århus N Direct:+45 87 40 08 49 > Denmark Email: [EMAIL PROTECTED] > > ___ > 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
[JBoss-dev] CVS update: binaries JBoss-2.2.2_Jetty-3.1.RC5-2.tgz
User: jules_gosnell Date: 01/06/11 15:03:27 Added: .JBoss-2.2.2_Jetty-3.1.RC5-2.tgz Log: another shot at the JBoss-2.2.2_Jetty-3.1.RC5 release ! Revision ChangesPath 1.1 binaries/JBoss-2.2.2_Jetty-3.1.RC5-2.tgz <> ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces HomeProxy.java
User: sparre
Date: 01/06/11 14:52:24
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces
HomeProxy.java
Log:
Fixed EJB1.1 sect. 5.3.2 violation:
Invoking the javax.ejb.Home.remove(Object primaryKey) method
on a session home must result in a javax.ejb.RemoveException.
Revision ChangesPath
1.23 +6 -1
jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/HomeProxy.java
Index: HomeProxy.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/HomeProxy.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- HomeProxy.java2001/05/02 03:04:14 1.22
+++ HomeProxy.java2001/06/11 21:52:23 1.23
@@ -20,6 +20,7 @@
import javax.ejb.Handle;
import javax.ejb.HomeHandle;
import javax.ejb.EJBMetaData;
+import javax.ejb.RemoveException;
import org.jboss.ejb.CacheKey;
import org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker;
@@ -30,7 +31,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author Jason Dillon mailto:[EMAIL PROTECTED]";><[EMAIL PROTECTED]>
- * @version $Revision: 1.22 $
+ * @version $Revision: 1.23 $
*/
public class HomeProxy
extends GenericProxy
@@ -166,6 +167,10 @@
return Void.TYPE;
}
else if (m.equals(REMOVE_BY_PRIMARY_KEY)) {
+// Session beans must throw RemoveException (EJB 1.1, 5.3.2)
+if (ejbMetaData.isSession())
+throw new RemoveException("Session beans cannot be removed by
primary key.");
+
// The trick is simple we trick the container in believe it
// is a remove() on the instance
Object id = new CacheKey(args[0]);
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Screwed up: commited into mainline by mistake
I am struggling with my Linux router and I really want to do the URL based install first but this is next so hopefully by the end of the week I will review it :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Monday, June 11, 2001 5:38 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Screwed up: commited into mainline by mistake | | |It should be added to the 2.2.x branch as well. Let Marc review the |current patch and then commit once its blessed. | |- Original Message - |From: "Bill Burke" <[EMAIL PROTECTED]> |To: <[EMAIL PROTECTED]> |Sent: Monday, June 11, 2001 2:13 PM |Subject: RE: [JBoss-dev] Screwed up: commited into mainline by mistake | | |> Just let me know if you feel this is a valid patch for 2.2.2 as |well. We're |> using 2.2.2 right now with the changes I've made. |> |> Bill | | | |___ |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] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Yes, it is checked into the mainline org.jboss.ejb.plugins: EntityInstanceCache.java EntityInstanceInterceptor.java AbstractInstanceCache.java BeanSemaphore.java EntitySynchronizationInterceptor.java Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, June 11, 2001 5:18 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] race condition between > EntityInstanceInterceptor and InstanceSynchronization? > > > OK... > > do you guys have code on this? > > I believe we need to fully rethink the mutex thingy from Simone > in there, it > is broken. > > Is there code I can review? > > marc > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of marc > |fleury > |Sent: Monday, June 11, 2001 4:54 PM > |To: [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] race condition between > |EntityInstanceInterceptor and InstanceSynchronization? > | > | > |no it is the "chinese torture" where the mutex always lets one go through > |and it goes in "busy wait"... we are on it. > | > |marcf > | > | > ||-Original Message- > ||From: [EMAIL PROTECTED] > ||[mailto:[EMAIL PROTECTED]]On Behalf Of > ||Dominik Baranowski > ||Sent: Monday, June 11, 2001 2:37 PM > ||To: [EMAIL PROTECTED] > ||Subject: RE: [JBoss-dev] race condition between > ||EntityInstanceInterceptor and InstanceSynchronization? > || > || > ||Hi Georg, > || > ||I've been running into this problem for quite some time > ||now. Jboss enters > ||LOCKING-WAITING loop, the cpu goes to 100% and then after some time the > ||server goes dead. Is this due to a transaction deadlock? > ||I'm very interested in this fix, if someone is working on it. If no one > ||takes this I'd like to give it a try, but I'm not familiar with > ||the code, so > ||I might need a few orientation pointers. > || > ||-dom > || > ||-Original Message- > ||From: [EMAIL PROTECTED] > ||[mailto:[EMAIL PROTECTED]]On Behalf Of Georg > ||Rehfeld > ||Sent: Thursday, June 07, 2001 10:45 PM > ||To: [EMAIL PROTECTED] > ||Subject: Re: [JBoss-dev] race condition between > ||EntityInstanceInterceptor and InstanceSynchronization? > || > || > ||Dear Bill and Dan, > || > ||> > I'd really like to go in and fix this problem, but I really > ||need another > ||set > ||> > of eyeballs to make sure I'm doing things right. Danch, can you > ||volunteer > ||> > to help? Also, while I'm in this code, maybe I should > consider adding > ||the > ||> > "Missing wait/notify" and remove that buggy do..while loop as well. > ||> > > ||> > ||> I can certainly review. I won't have much time for investigation until > ||> this evening, and then my wife may have other plans for my time. > || > ||I would be really happy, if you both could manage to correct the > ||wait/notify issue while on that code and fixing the race condition. > || > ||Besides, I just answered a message, where someone seemed to have a > ||deadlock, that remained unresolved, though server log messages > ||told, that the transactions timed out (3 TX reported). The guy > ||had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). > || > ||best regards > ||Georg > || ___ ___ > ||| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > || > ||PS: I don't think, I can really help, but I'll follow this thread > ||maybe at least I can document something. > || > || > || > ||___ > ||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 > > > > ___ > 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] Screwed up: commited into mainline by mistake
It should be added to the 2.2.x branch as well. Let Marc review the current patch and then commit once its blessed. - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 2:13 PM Subject: RE: [JBoss-dev] Screwed up: commited into mainline by mistake > Just let me know if you feel this is a valid patch for 2.2.2 as well. We're > using 2.2.2 right now with the changes I've made. > > Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] race condition in EntityInstanceInterceptor FIXED?
The changes are in CVS in the mainline. Please let me know how it goes!!! These problems are hard to reproduce. org.jboss.ejb.plugins: EntityInstanceCache.java EntityInstanceInterceptor.java AbstractInstanceCache.java BeanSemaphore.java EntitySynchronizationInterceptor.java If you're using JBoss 2.2.x you'll need to hand merge EntitySynchronizationInterceptor.java. Just look in EntitySynchronizationInterceptor.InstanceSynchronization.afterCompletion in the if (ROLLBACK) block of code. The mutex locks are what I put in there. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Dominik Baranowski > Sent: Monday, June 11, 2001 3:03 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] race condition in EntityInstanceInterceptor > FIXED? > > > Hi Bill, > > This sounds like the problems that I've been running into. > I would love to > get my hands on your changes. > I'm sure my environment would make a good test case for your code. > > thanks > -dom > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Monday, June 11, 2001 9:09 AM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: [JBoss-dev] race condition in EntityInstanceInterceptor FIXED? > > > (I'm resending this, because it didn't seem to show up on > jboss-dev. If you > want the actually source code I changed, please email me.) > > > All, > I really need another set of eyes to check out some code changes > I've made. > I'll check this in a day or so if I don't get any feedback. We've been > having some problems lately with findBy methods that return references to > the wrong rows in the database. (Please see the dev-threads "Serious Bug? > EntityBean out of synch with database" and "race condition between > EntityInstanceInterceptor"). In examining EntityInstanceInterceptor and > EntitySynchronizationInterceptor.InstanceSynchronization I found a race > condition and one other problem when an EntityInstanceCache.remove() is > called(within a rollback or an exception). Also there are > potential problems > with re-entrant beans not getting a transactional "lock" because > EntityEnterpriseContext.setTransaction is not done in a mutex lock block. > race condition: > - When a rollback happens within a transaction, > InstanceSynchronization.afterCompletion would call > ctx.setTransaction(null) > and would not protect the EntityEnterpriseContext with a mutex lock. There > it was quite possible for another thread waiting for the entity bean to > leave it's transaction to wakeup, do a cache.get(id) before > afterCompletion > did a cache.remove and an InstancePool.free.(I actually wrote a > little test > that did a sleep after ctx.setTransaction(null) to verify this). > Really bad > things can happen like the context being put back into the instance pool > while another thread thinks the context is still valid. > invalid mutexes: > - When an EntityInstanceCache.remove is called, the Entity's mutex is > disassociated with the id of the Entity. Thus, all threads waiting on the > same bean will be locking on an invalid mutex if > EntityInstanceCache.remove > is called. > ctx.setTransaction not synchronized > - setTransaction is called within > EntityContainer.ContainerInterceptor. The > mutex of the Entity is NOT acquire before this is done, therefore, with > re-entrant beans, you can possibly have 2 transaction working on the same > entity instance. > Too many LOCKING-WAITING messages: > - You server.log file can grow to 100 megabytes or more very quickly when > beans are in contention. > FIXES!! > Files changed: > AbstractInstanceCache.java > EntityInstanceCache.java > EntityInstanceInterceptor.java > EntitySynchronizationInterceptor.java > Files added: > BeanSemaphore.java > - Wherever there is an EntityInstanceCache.remove(), I make sure that I > acquire the mutex of the entity before doing this. > - I added the ability to invalidate a mutex. When > AbstractInstanceCache.removeLock is called, the mutex is flagged > as invalid. > EntityInstanceInterceptor checks for this and does a re-lookup of > the mutex. > - I do ctx.setTransaction within the EntityInstanceInterceptor to ensure > that a transactional lock happens. THis will fix the re-entrant > bean problem > I discussed earlier. > - I put in some code in EntityInstanceInterceptor so that LOCKING-WAITING > messages don't happen continuously. > - Put in a Thread.yield() in the infamous EntityInstanceInterceptor > do..while loop. > - Added an extension of org.jboss.util.Semaphore, BeanSemaphore, for > invalidation of mutexes. > - Added an id check in EntityInstanceCache.get to make sure that the key > you're looking up on is equal the the EntityEnterpriseContext.getId() > Thanks in advance for any help with this, > Bill > -- > -- > > DIFFS > ---
RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
OK... do you guys have code on this? I believe we need to fully rethink the mutex thingy from Simone in there, it is broken. Is there code I can review? marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Monday, June 11, 2001 4:54 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] race condition between |EntityInstanceInterceptor and InstanceSynchronization? | | |no it is the "chinese torture" where the mutex always lets one go through |and it goes in "busy wait"... we are on it. | |marcf | | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED]]On Behalf Of ||Dominik Baranowski ||Sent: Monday, June 11, 2001 2:37 PM ||To: [EMAIL PROTECTED] ||Subject: RE: [JBoss-dev] race condition between ||EntityInstanceInterceptor and InstanceSynchronization? || || ||Hi Georg, || || I've been running into this problem for quite some time ||now. Jboss enters ||LOCKING-WAITING loop, the cpu goes to 100% and then after some time the ||server goes dead. Is this due to a transaction deadlock? ||I'm very interested in this fix, if someone is working on it. If no one ||takes this I'd like to give it a try, but I'm not familiar with ||the code, so ||I might need a few orientation pointers. || ||-dom || ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED]]On Behalf Of Georg ||Rehfeld ||Sent: Thursday, June 07, 2001 10:45 PM ||To: [EMAIL PROTECTED] ||Subject: Re: [JBoss-dev] race condition between ||EntityInstanceInterceptor and InstanceSynchronization? || || ||Dear Bill and Dan, || ||> > I'd really like to go in and fix this problem, but I really ||need another ||set ||> > of eyeballs to make sure I'm doing things right. Danch, can you ||volunteer ||> > to help? Also, while I'm in this code, maybe I should consider adding ||the ||> > "Missing wait/notify" and remove that buggy do..while loop as well. ||> > ||> ||> I can certainly review. I won't have much time for investigation until ||> this evening, and then my wife may have other plans for my time. || ||I would be really happy, if you both could manage to correct the ||wait/notify issue while on that code and fixing the race condition. || ||Besides, I just answered a message, where someone seemed to have a ||deadlock, that remained unresolved, though server log messages ||told, that the transactions timed out (3 TX reported). The guy ||had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). || ||best regards ||Georg || ___ ___ ||| + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 || ||PS: I don't think, I can really help, but I'll follow this thread ||maybe at least I can document something. || || || ||___ ||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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/build build.bat
User: starksm Date: 01/06/11 14:13:59 Modified:jetty/src/build build.bat Log: Update build.bat to be in synch with build.sh Revision ChangesPath 1.2 +27 -18contrib/jetty/src/build/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/jetty/src/build/build.bat,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- build.bat 2000/12/20 14:56:03 1.1 +++ build.bat 2001/06/11 21:13:59 1.2 @@ -1,23 +1,32 @@ @echo off -REM $Id: build.bat,v 1.1 2000/12/20 14:56:03 oleg Exp $ +REM $Id: build.bat,v 1.2 2001/06/11 21:13:59 starksm Exp $ -if not "%JBOSS_HOME%" == "" goto jetty_home_check -echo JBOSS_HOME is not set. You need jboss 2.0PR3+ -goto abort +if not exist "%JBOSS_HOME%\bin\run.jar" ( +echo $JBOSS_HOME/bin/run.jar does not exist +echo set JBOSS_HOME to your JBoss dist directory +exit 1 +) +if not exist "%JETTY_HOME%\lib\com.mortbay.jetty.jar" ( +echo %JETTY_HOME%/lib/com.mortbay.jetty.jar does not exist +echo set JETTY_HOME to your Jetty3 directory +exit 1 +) + +if not exist "%JETTY_EXTRA%/jmx/lib/com.mortbay.jetty.jmx.jar" ( +echo %JETTY_EXTRA%/jmx/lib/com.mortbay.jetty.jmx.jar does not exist +echo set JETTY_EXTRA to your Jetty3Extra directory +exit 1 +) -:jetty_home_check -if not "%JETTY_HOME%" == "" goto continue -echo JETTY_HOME is not set. You need jetty 3.0.0-rc5 - -:abort -echo Aborting... -exit - -:continue - -SET CLASSPATH=..\..\..\tomcat\lib\ant.jar -SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\xml.jar -SET CLASSPATH=%CLASSPATH%;..\..\build\classes +SET CLASSPATH=..\..\build\classes +SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\ant.jar SET CLASSPATH=%CLASSPATH%;..\..\..\tomcat\lib\javac.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jaxp.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\crimson.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\jboss-jaas.jar +SET CLASSPATH=%CLASSPATH%;%JBOSS_HOME%\lib\ext\jbosssx.jar +SET CLASSPATH=%CLASSPATH%;%JETTY_EXTRA%\jmx\lib\com.mortbay.jetty.jmx.jar + +SET OPTS= -Djetty.home="%JETTY_HOME%" -Djboss.home="%JBOSS_HOME%" -Djetty.extra="%JETTY_EXTRA%" +java %OPTS% org.apache.tools.ant.Main %* -java -Djetty.home=%JETTY_HOME% -Djboss.home=%JBOSS_HOME% org.apache.tools.ant.Main %* ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Screwed up: commited into mainline by mistake
Just let me know if you feel this is a valid patch for 2.2.2 as well. We're using 2.2.2 right now with the changes I've made. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Monday, June 11, 2001 5:00 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Screwed up: commited into mainline by mistake > > > Since it was going to be commited to main just leave it. > > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: "Jboss-Development@Lists. Sourceforge. Net" > <[EMAIL PROTECTED]> > Sent: Monday, June 11, 2001 1:10 PM > Subject: [JBoss-dev] Screwed up: commited into mainline by mistake > > > > I commited into the mainline by mistake instead of the JBoss 3.0 > > (Rabbithole) branch. I'm sorry I'm such an idiot. I'm > unfamiliar with CVS > > and have been using WinCVS. I thought if I checkedout stuff > from a branch, > > WinCVS would automatically commit to that same branch. > > > > What do you all want me to do about this? I won't make this > mistake again. > > Sorry > > > > Regretful, > > > > Bill > > > > > > > > > ___ > 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] race condition in EntityInstanceInterceptor FIXED?
Hi Bill, This sounds like the problems that I've been running into. I would love to get my hands on your changes. I'm sure my environment would make a good test case for your code. thanks -dom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Monday, June 11, 2001 9:09 AM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] race condition in EntityInstanceInterceptor FIXED? (I'm resending this, because it didn't seem to show up on jboss-dev. If you want the actually source code I changed, please email me.) All, I really need another set of eyes to check out some code changes I've made. I'll check this in a day or so if I don't get any feedback. We've been having some problems lately with findBy methods that return references to the wrong rows in the database. (Please see the dev-threads "Serious Bug? EntityBean out of synch with database" and "race condition between EntityInstanceInterceptor"). In examining EntityInstanceInterceptor and EntitySynchronizationInterceptor.InstanceSynchronization I found a race condition and one other problem when an EntityInstanceCache.remove() is called(within a rollback or an exception). Also there are potential problems with re-entrant beans not getting a transactional "lock" because EntityEnterpriseContext.setTransaction is not done in a mutex lock block. race condition: - When a rollback happens within a transaction, InstanceSynchronization.afterCompletion would call ctx.setTransaction(null) and would not protect the EntityEnterpriseContext with a mutex lock. There it was quite possible for another thread waiting for the entity bean to leave it's transaction to wakeup, do a cache.get(id) before afterCompletion did a cache.remove and an InstancePool.free.(I actually wrote a little test that did a sleep after ctx.setTransaction(null) to verify this). Really bad things can happen like the context being put back into the instance pool while another thread thinks the context is still valid. invalid mutexes: - When an EntityInstanceCache.remove is called, the Entity's mutex is disassociated with the id of the Entity. Thus, all threads waiting on the same bean will be locking on an invalid mutex if EntityInstanceCache.remove is called. ctx.setTransaction not synchronized - setTransaction is called within EntityContainer.ContainerInterceptor. The mutex of the Entity is NOT acquire before this is done, therefore, with re-entrant beans, you can possibly have 2 transaction working on the same entity instance. Too many LOCKING-WAITING messages: - You server.log file can grow to 100 megabytes or more very quickly when beans are in contention. FIXES!! Files changed: AbstractInstanceCache.java EntityInstanceCache.java EntityInstanceInterceptor.java EntitySynchronizationInterceptor.java Files added: BeanSemaphore.java - Wherever there is an EntityInstanceCache.remove(), I make sure that I acquire the mutex of the entity before doing this. - I added the ability to invalidate a mutex. When AbstractInstanceCache.removeLock is called, the mutex is flagged as invalid. EntityInstanceInterceptor checks for this and does a re-lookup of the mutex. - I do ctx.setTransaction within the EntityInstanceInterceptor to ensure that a transactional lock happens. THis will fix the re-entrant bean problem I discussed earlier. - I put in some code in EntityInstanceInterceptor so that LOCKING-WAITING messages don't happen continuously. - Put in a Thread.yield() in the infamous EntityInstanceInterceptor do..while loop. - Added an extension of org.jboss.util.Semaphore, BeanSemaphore, for invalidation of mutexes. - Added an id check in EntityInstanceCache.get to make sure that the key you're looking up on is equal the the EntityEnterpriseContext.getId() Thanks in advance for any help with this, Bill DIFFS cvs diff -w EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java EntityInstanceCache.java AbstractInstanceCache.java (in directory D:\main\jboss2.3_src\jboss\src\main\org\jboss\ejb\plugins) Index: EntitySynchronizationInterceptor.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInt erceptor.java,v retrieving revision 1.34 diff -w -r1.34 EntitySynchronizationInterceptor.java 39a40 > import org.jboss.util.Sync; 414c415,421 < --- > EntityContainer container = (EntityContainer)ctx.getContainer(); > AbstractInstanceCache cache = (AbstractInstanceCache)container.getInstanceCache(); > Object id = ctx.getCacheKey(); > // Hopefully this transaction has an exclusive lock > // on this id so that cache.getLock returns a mutex that is being > // used by every other thread on this id. > Sync mutex = (Sync)cache.getLock(id); 416c423,425 < --- > // We really
RE: [JBoss-dev] RMI IIOP
Hi > we feel really lucky to > select JBoss. Its collectively THE best so far. Personally, I have found open source software to be far better and flexible than their commercial counterparts. This is one motivating factor of me being in this list and wanting to contribute to JBoss ! RMI-IIOP: I think, everyone can send what is required out of RMI-IIOP support in JBoss to me, I will document it, and we can start from there. Ajay --- Tahir Awan <[EMAIL PROTECTED]> wrote: > First application we wrote with JBoss was just to > bring in J2EE to this > company (have used WebLogic 5.1 in previous job). It > was a very simple app. > with some stateless session beans and JSP Model 1 > architecture. Currently, > its in QA and will be in production in about 6 > weeks. > Currently working on 2nd and quite big project. > Persistance is all XML, so > there's no entity beans but a lot of SB, with JSP > Model 2 architecture, > struts taglibs. Both projects use Apache (basic > auth), embedded tomcat and > JBoss 2.2. > > I will try to be in sync. with other guys on > RMI-IIOP. Hope to have some > requirements soon. > > Finally, as I have said many times to colleagues, we > feel really lucky to > select JBoss. Its collectively THE best so far. > > Tahir > > > > -Original Message- > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > Sent: Monday, June 11, 2001 3:34 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] RMI IIOP > > > > > > tahir... give us a reference, you using our stuff > in production? > > > > sync with the guys answering on RMI-IIOP (peter > saw your email)... > > > > does anyone know where to start? I sure don't :) > > marcf > > > > |-Original Message- > > |From: > [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On > > > Behalf Of Tahir > > |Awan > > |Sent: Monday, June 11, 2001 3:23 PM > > |To: '[EMAIL PROTECTED]' > > |Subject: RE: [JBoss-dev] RMI IIOP > > | > > | > > |Hi Marc, > > | > > |I would love to contribute to jboss and hope my > decent > > experience can be > > |helpful. > > |btw, I am using JBoss (and hence on the list) for > 6 months now. > > | > > |Thanks, > > |Tahir > > | > > |> -Original Message- > > |> From: marc fleury > [mailto:[EMAIL PROTECTED]] > > |> Sent: Monday, June 11, 2001 1:11 PM > > |> To: Jboss-Development@Lists. Sourceforge. Net > > |> Subject: [JBoss-dev] RMI IIOP > > |> > > |> > > |> So guys, > > |> > > |> now that it is a real requirement we need to > put that in... > > |> > > |> ANYONE interested in taking that on? I would > put the > > |> red-carpet out for that > > |> one brave soul. > > |> > > |> You know we need that "checkbox" somewhere and > I understand > > |> from teh BEA > > |> folks that no-one uses it *really* but it needs > to be > > |> there... so "wink" > > |> "wink" > > |> > > |> let me know PLEASE > > |> > > |> regards > > |> > > |> marcf > > |> > > |> _ > > |> Marc Fleury, Ph.D > > |> [EMAIL PROTECTED] > > |> _ > > |> > > |> > > |> > > |> ___ > > |> 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 > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Screwed up: commited into mainline by mistake
Since it was going to be commited to main just leave it. - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 1:10 PM Subject: [JBoss-dev] Screwed up: commited into mainline by mistake > I commited into the mainline by mistake instead of the JBoss 3.0 > (Rabbithole) branch. I'm sorry I'm such an idiot. I'm unfamiliar with CVS > and have been using WinCVS. I thought if I checkedout stuff from a branch, > WinCVS would automatically commit to that same branch. > > What do you all want me to do about this? I won't make this mistake again. > Sorry > > Regretful, > > Bill > > > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
no it is the "chinese torture" where the mutex always lets one go through and it goes in "busy wait"... we are on it. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Dominik Baranowski |Sent: Monday, June 11, 2001 2:37 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] race condition between |EntityInstanceInterceptor and InstanceSynchronization? | | |Hi Georg, | | I've been running into this problem for quite some time |now. Jboss enters |LOCKING-WAITING loop, the cpu goes to 100% and then after some time the |server goes dead. Is this due to a transaction deadlock? |I'm very interested in this fix, if someone is working on it. If no one |takes this I'd like to give it a try, but I'm not familiar with |the code, so |I might need a few orientation pointers. | |-dom | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Georg |Rehfeld |Sent: Thursday, June 07, 2001 10:45 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] race condition between |EntityInstanceInterceptor and InstanceSynchronization? | | |Dear Bill and Dan, | |> > I'd really like to go in and fix this problem, but I really |need another |set |> > of eyeballs to make sure I'm doing things right. Danch, can you |volunteer |> > to help? Also, while I'm in this code, maybe I should consider adding |the |> > "Missing wait/notify" and remove that buggy do..while loop as well. |> > |> |> I can certainly review. I won't have much time for investigation until |> this evening, and then my wife may have other plans for my time. | |I would be really happy, if you both could manage to correct the |wait/notify issue while on that code and fixing the race condition. | |Besides, I just answered a message, where someone seemed to have a |deadlock, that remained unresolved, though server log messages |told, that the transactions timed out (3 TX reported). The guy |had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). | |best regards |Georg | ___ ___ || + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg ||_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 | |PS: I don't think, I can really help, but I'll follow this thread |maybe at least I can document something. | | | |___ |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
RE: [JBoss-dev] RMI IIOP
First application we wrote with JBoss was just to bring in J2EE to this company (have used WebLogic 5.1 in previous job). It was a very simple app. with some stateless session beans and JSP Model 1 architecture. Currently, its in QA and will be in production in about 6 weeks. Currently working on 2nd and quite big project. Persistance is all XML, so there's no entity beans but a lot of SB, with JSP Model 2 architecture, struts taglibs. Both projects use Apache (basic auth), embedded tomcat and JBoss 2.2. I will try to be in sync. with other guys on RMI-IIOP. Hope to have some requirements soon. Finally, as I have said many times to colleagues, we feel really lucky to select JBoss. Its collectively THE best so far. Tahir > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 3:34 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RMI IIOP > > > tahir... give us a reference, you using our stuff in production? > > sync with the guys answering on RMI-IIOP (peter saw your email)... > > does anyone know where to start? I sure don't :) > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On > Behalf Of Tahir > |Awan > |Sent: Monday, June 11, 2001 3:23 PM > |To: '[EMAIL PROTECTED]' > |Subject: RE: [JBoss-dev] RMI IIOP > | > | > |Hi Marc, > | > |I would love to contribute to jboss and hope my decent > experience can be > |helpful. > |btw, I am using JBoss (and hence on the list) for 6 months now. > | > |Thanks, > |Tahir > | > |> -Original Message- > |> From: marc fleury [mailto:[EMAIL PROTECTED]] > |> Sent: Monday, June 11, 2001 1:11 PM > |> To: Jboss-Development@Lists. Sourceforge. Net > |> Subject: [JBoss-dev] RMI IIOP > |> > |> > |> So guys, > |> > |> now that it is a real requirement we need to put that in... > |> > |> ANYONE interested in taking that on? I would put the > |> red-carpet out for that > |> one brave soul. > |> > |> You know we need that "checkbox" somewhere and I understand > |> from teh BEA > |> folks that no-one uses it *really* but it needs to be > |> there... so "wink" > |> "wink" > |> > |> let me know PLEASE > |> > |> regards > |> > |> marcf > |> > |> _ > |> Marc Fleury, Ph.D > |> [EMAIL PROTECTED] > |> _ > |> > |> > |> > |> ___ > |> 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 > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java EntityInstanceCache.java AbstractInstanceCache.java
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, June 11, 2001 4:08 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] CVS update: > jboss/src/main/org/jboss/ejb/plugins > EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java > EntityInstanceCache.java AbstractInstanceCache.java > > > bill, > > I would really check all of the access to the state of the ctx. Since the > ctx is multithreaded we need to make sure that all the operations that > access it are kosher. > > I remember going through the excercise for the earlier versions and asking > simone to do the same. > > Simply do a search on the methods that access the Context and > make sure you > synchronize correctly. > > I remember that the cache passivation REALLY made things more complex > Off the top of my head, the first one I can think of it ctx.setTransaction that is done in EntityContainer.ContainerInterceptor.invoke. In my check-in I do this within EntityInstanceInterceptor.java instead. I also undo the setTransaction if an InstanceSynchronization is not registered with the TM. Should setTransaction be removed from EntityContainer.ContainerInterceptor.invoke, now that I do the association in EntityInstanceInterceptor? I'll look throw ctx access more thoroughly later tonight. I have "paid" work I must accomplish before hand Bill BTW, sorry again about the commit to mainline instead of the branch [snip] ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Hi Georg, I've been running into this problem for quite some time now. Jboss enters LOCKING-WAITING loop, the cpu goes to 100% and then after some time the server goes dead. Is this due to a transaction deadlock? I'm very interested in this fix, if someone is working on it. If no one takes this I'd like to give it a try, but I'm not familiar with the code, so I might need a few orientation pointers. -dom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Thursday, June 07, 2001 10:45 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization? Dear Bill and Dan, > > I'd really like to go in and fix this problem, but I really need another set > > of eyeballs to make sure I'm doing things right. Danch, can you volunteer > > to help? Also, while I'm in this code, maybe I should consider adding the > > "Missing wait/notify" and remove that buggy do..while loop as well. > > > > I can certainly review. I won't have much time for investigation until > this evening, and then my wife may have other plans for my time. I would be really happy, if you both could manage to correct the wait/notify issue while on that code and fixing the race condition. Besides, I just answered a message, where someone seemed to have a deadlock, that remained unresolved, though server log messages told, that the transactions timed out (3 TX reported). The guy had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: I don't think, I can really help, but I'll follow this thread maybe at least I can document something. ___ 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] Screwed up: commited into mainline by mistake
I commited into the mainline by mistake instead of the JBoss 3.0 (Rabbithole) branch. I'm sorry I'm such an idiot. I'm unfamiliar with CVS and have been using WinCVS. I thought if I checkedout stuff from a branch, WinCVS would automatically commit to that same branch. What do you all want me to do about this? I won't make this mistake again. Sorry Regretful, Bill
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java EntityInstanceCache.java AbstractInstanceCache.java
bill,
I would really check all of the access to the state of the ctx. Since the
ctx is multithreaded we need to make sure that all the operations that
access it are kosher.
I remember going through the excercise for the earlier versions and asking
simone to do the same.
Simply do a search on the methods that access the Context and make sure you
synchronize correctly.
I remember that the cache passivation REALLY made things more complex
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Monday, June 11, 2001 3:52 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins
|EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java
|EntityInstanceCache.java AbstractInstanceCache.java
|
|
| User: patriot1burke
| Date: 01/06/11 12:52:26
|
| Modified:src/main/org/jboss/ejb/plugins
|EntitySynchronizationInterceptor.java
|EntityInstanceInterceptor.java
|EntityInstanceCache.java AbstractInstanceCache.java
| Log:
| race condition:
| - When a rollback happens within a transaction,
| InstanceSynchronization.afterCompletion would call
|ctx.setTransaction(null)
| and would not protect the EntityEnterpriseContext with a mutex
|lock. There
| it was quite possible for another thread waiting for the entity bean to
| leave it's transaction to wakeup, do a cache.get(id) before
|afterCompletion
| did a cache.remove and an InstancePool.free.(I actually wrote a
|little test
| that did a sleep after ctx.setTransaction(null) to verify this).
|Really bad
| things can happen like the context being put back into the instance pool
| while another thread thinks the context is still valid.
| invalid mutexes:
| - When an EntityInstanceCache.remove is called, the Entity's mutex is
| disassociated with the id of the Entity. Thus, all threads waiting on the
| same bean will be locking on an invalid mutex if
|EntityInstanceCache.remove
| is called.
| ctx.setTransaction not synchronized
| - setTransaction is called within
|EntityContainer.ContainerInterceptor. The
| mutex of the Entity is NOT acquire before this is done, therefore, with
| re-entrant beans, you can possibly have 2 transaction working on the same
| entity instance.
| Too many LOCKING-WAITING messages:
| - You server.log file can grow to 100 megabytes or more very quickly when
| beans are in contention.
|
| FIXES:
|
| - Wherever there is an EntityInstanceCache.remove(), I make sure that I
| acquire the mutex of the entity before doing this.
| - I added the ability to invalidate a mutex. When
| AbstractInstanceCache.removeLock is called, the mutex is flagged
|as invalid.
| EntityInstanceInterceptor checks for this and does a re-lookup
|of the mutex.
| - I do ctx.setTransaction within the EntityInstanceInterceptor to ensure
| that a transactional lock happens. THis will fix the re-entrant
|bean problem
| I discussed earlier.
| - I put in some code in EntityInstanceInterceptor so that LOCKING-WAITING
| messages don't happen continuously.
| - Put in a Thread.yield() in the infamous EntityInstanceInterceptor
| do..while loop.
| - Added an extension of org.jboss.util.Semaphore, BeanSemaphore, for
| invalidation of mutexes.
| - Added an id check in EntityInstanceCache.get to make sure that the key
| you're looking up on is equal the the EntityEnterpriseContext.getId()
|
| Revision ChangesPath
| 1.35 +23 -5
|jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInterceptor.java
|
| Index: EntitySynchronizationInterceptor.java
| ===
| RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntitySynchroni
|zationInterceptor.java,v
| retrieving revision 1.34
| retrieving revision 1.35
| diff -u -r1.34 -r1.35
| --- EntitySynchronizationInterceptor.java2001/06/05 05:11:22 1.34
| +++ EntitySynchronizationInterceptor.java2001/06/11 19:52:26 1.35
| @@ -37,6 +37,7 @@
| import org.jboss.ejb.MethodInvocation;
| import org.jboss.metadata.ConfigurationMetaData;
| import org.jboss.logging.Logger;
| +import org.jboss.util.Sync;
|
| /**
| * This container filter takes care of EntityBean persistance.
| @@ -49,7 +50,7 @@
| * @see
| * @author Rickard Öberg ([EMAIL PROTECTED])
| * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
| -* @version $Revision: 1.34 $
| +* @version $Revision: 1.35 $
| */
| public class EntitySynchronizationInterceptor
| extends AbstractInterceptor
| @@ -411,22 +412,39 @@
| // If rolled back -> invalidate instance
| // If removed -> send back to the pool
| if (status == Status.STATUS_ROLLEDBACK || ctx.getId()
|== null) {
| -
| + EntityContainer container =
|(EntityContainer)ctx.getContainer();
| + AbstractInstanceCache cache =
|(Abs
[JBoss-dev] CVS update: jboss/src/build build.xml
User: starksm Date: 01/06/11 12:59:03 Modified:src/build build.xml Log: Start cleaning up the jar element includes to be readable Revision ChangesPath 1.75 +5 -2 jboss/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/src/build/build.xml,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- build.xml 2001/06/10 18:04:49 1.74 +++ build.xml 2001/06/11 19:59:03 1.75 @@ -217,8 +217,11 @@ +> + + + + http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins EntitySynchronizationInterceptor.java EntityInstanceInterceptor.java EntityInstanceCache.java AbstractInstanceCache.java
User: patriot1burke
Date: 01/06/11 12:52:26
Modified:src/main/org/jboss/ejb/plugins
EntitySynchronizationInterceptor.java
EntityInstanceInterceptor.java
EntityInstanceCache.java AbstractInstanceCache.java
Log:
race condition:
- When a rollback happens within a transaction,
InstanceSynchronization.afterCompletion would call ctx.setTransaction(null)
and would not protect the EntityEnterpriseContext with a mutex lock. There
it was quite possible for another thread waiting for the entity bean to
leave it's transaction to wakeup, do a cache.get(id) before afterCompletion
did a cache.remove and an InstancePool.free.(I actually wrote a little test
that did a sleep after ctx.setTransaction(null) to verify this). Really bad
things can happen like the context being put back into the instance pool
while another thread thinks the context is still valid.
invalid mutexes:
- When an EntityInstanceCache.remove is called, the Entity's mutex is
disassociated with the id of the Entity. Thus, all threads waiting on the
same bean will be locking on an invalid mutex if EntityInstanceCache.remove
is called.
ctx.setTransaction not synchronized
- setTransaction is called within EntityContainer.ContainerInterceptor. The
mutex of the Entity is NOT acquire before this is done, therefore, with
re-entrant beans, you can possibly have 2 transaction working on the same
entity instance.
Too many LOCKING-WAITING messages:
- You server.log file can grow to 100 megabytes or more very quickly when
beans are in contention.
FIXES:
- Wherever there is an EntityInstanceCache.remove(), I make sure that I
acquire the mutex of the entity before doing this.
- I added the ability to invalidate a mutex. When
AbstractInstanceCache.removeLock is called, the mutex is flagged as invalid.
EntityInstanceInterceptor checks for this and does a re-lookup of the mutex.
- I do ctx.setTransaction within the EntityInstanceInterceptor to ensure
that a transactional lock happens. THis will fix the re-entrant bean problem
I discussed earlier.
- I put in some code in EntityInstanceInterceptor so that LOCKING-WAITING
messages don't happen continuously.
- Put in a Thread.yield() in the infamous EntityInstanceInterceptor
do..while loop.
- Added an extension of org.jboss.util.Semaphore, BeanSemaphore, for
invalidation of mutexes.
- Added an id check in EntityInstanceCache.get to make sure that the key
you're looking up on is equal the the EntityEnterpriseContext.getId()
Revision ChangesPath
1.35 +23 -5
jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInterceptor.java
Index: EntitySynchronizationInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInterceptor.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- EntitySynchronizationInterceptor.java 2001/06/05 05:11:22 1.34
+++ EntitySynchronizationInterceptor.java 2001/06/11 19:52:26 1.35
@@ -37,6 +37,7 @@
import org.jboss.ejb.MethodInvocation;
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.logging.Logger;
+import org.jboss.util.Sync;
/**
* This container filter takes care of EntityBean persistance.
@@ -49,7 +50,7 @@
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
-* @version $Revision: 1.34 $
+* @version $Revision: 1.35 $
*/
public class EntitySynchronizationInterceptor
extends AbstractInterceptor
@@ -411,22 +412,39 @@
// If rolled back -> invalidate instance
// If removed -> send back to the pool
if (status == Status.STATUS_ROLLEDBACK || ctx.getId() == null) {
-
+ EntityContainer container = (EntityContainer)ctx.getContainer();
+ AbstractInstanceCache cache =
(AbstractInstanceCache)container.getInstanceCache();
+ Object id = ctx.getCacheKey();
+ // Hopefully this transaction has an exclusive lock
+ // on this id so that cache.getLock returns a mutex that is being
+ // used by every other thread on this id.
+ Sync mutex = (Sync)cache.getLock(id);
try {
-
+ // We really should be acquiring a mutex before
+ // mucking with the InstanceCache or InstancePool
+ mutex.acquire();
// finish the transaction association
ctx.setTransaction(null);
// remove from the cache
+ // removing from the cache should also invalidate the mutex thus
waking up
+ // other threads.
container.getInstanceCache().remove(ctx.getCacheKey());
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins BeanSemaphore.java
User: patriot1burke
Date: 01/06/11 12:50:42
Added: src/main/org/jboss/ejb/plugins BeanSemaphore.java
Log:
Extension of org.jbos.util.Semaphore to provide the ability to invalidate
a mutex that is no longer associated with a bean
Revision ChangesPath
1.1 jboss/src/main/org/jboss/ejb/plugins/BeanSemaphore.java
Index: BeanSemaphore.java
===
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins;
import org.jboss.util.Semaphore;
/**
* Allow ability to mark a Semaphore as no longer valid for mutex locking
*
* @author mailto:[EMAIL PROTECTED]";>Bill Burke
* @version $Revision: 1.1 $
*/
public class BeanSemaphore extends Semaphore
{
private boolean m_valid = true;
public BeanSemaphore(int allowed)
{
super(allowed);
m_valid = true;
}
public void invalidate()
{
m_valid = false;
}
public boolean isValid()
{
return m_valid;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
On Mon, 11 Jun 2001, Bill Burke wrote: > Cool, > > The mainline is 2.4? What happened to 2.3? Anyways, I'll check this code it's 2.3, will be released as 2.4 > in as soon as I figure out how to use WinCVS with SourceForge(I'm looking at > Simone's directions from the dev-list archives). Hey, my first > checkin!(Well isn't that SPEciAaaal?!). > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > Sent: Monday, June 11, 2001 2:33 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > > > > > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan > > |Christopherson > > |Sent: Monday, June 11, 2001 2:01 PM > > |To: [EMAIL PROTECTED] > > |Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > | > > | > > |On Mon, 11 Jun 2001, Bill Burke wrote: > > | > > |> > > |> Again, IMHO, these race condition fixes can't wait until JBoss > > |3.0 since it > > |> sounds like 3.0 won't be ready until August/September? > > |> > > | > > |I agree with Bill here - the race condition fix really does need to be in > > |2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the > > |synchronization interceptor (multiple instances per bean, etc.) > > > > yeah yeah yeah > > > > get the code in, of course 2.4 should be patched. > > > > marcf > > > > > > > > | > > |-danch > > | > > | > > |___ > > |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 > -- Dan Christopherson (danch) nVisia Technical Architect (www.nvisia.com) Opinions expressed are mine and do not neccessarily reflect any position or opinion of nVISIA. --- If you're a capitalist and you have the best goods and they're free, you don't have to proselytize, you just have to wait. -Eben Moglen ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
Wait a minute Should I check into JBoss 3.0 branch? The "mainline"(which is 2.4, 2.3???). Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Monday, June 11, 2001 3:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > Cool, > > The mainline is 2.4? What happened to 2.3? Anyways, I'll check this code > in as soon as I figure out how to use WinCVS with SourceForge(I'm > looking at > Simone's directions from the dev-list archives). Hey, my first > checkin!(Well isn't that SPEciAaaal?!). > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > > fleury > > Sent: Monday, June 11, 2001 2:33 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > > > > > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan > > |Christopherson > > |Sent: Monday, June 11, 2001 2:01 PM > > |To: [EMAIL PROTECTED] > > |Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > | > > | > > |On Mon, 11 Jun 2001, Bill Burke wrote: > > | > > |> > > |> Again, IMHO, these race condition fixes can't wait until JBoss > > |3.0 since it > > |> sounds like 3.0 won't be ready until August/September? > > |> > > | > > |I agree with Bill here - the race condition fix really does > need to be in > > |2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the > > |synchronization interceptor (multiple instances per bean, etc.) > > > > yeah yeah yeah > > > > get the code in, of course 2.4 should be patched. > > > > marcf > > > > > > > > | > > |-danch > > | > > | > > |___ > > |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 > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RMI IIOP
tahir... give us a reference, you using our stuff in production? sync with the guys answering on RMI-IIOP (peter saw your email)... does anyone know where to start? I sure don't :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Tahir |Awan |Sent: Monday, June 11, 2001 3:23 PM |To: '[EMAIL PROTECTED]' |Subject: RE: [JBoss-dev] RMI IIOP | | |Hi Marc, | |I would love to contribute to jboss and hope my decent experience can be |helpful. |btw, I am using JBoss (and hence on the list) for 6 months now. | |Thanks, |Tahir | |> -Original Message- |> From: marc fleury [mailto:[EMAIL PROTECTED]] |> Sent: Monday, June 11, 2001 1:11 PM |> To: Jboss-Development@Lists. Sourceforge. Net |> Subject: [JBoss-dev] RMI IIOP |> |> |> So guys, |> |> now that it is a real requirement we need to put that in... |> |> ANYONE interested in taking that on? I would put the |> red-carpet out for that |> one brave soul. |> |> You know we need that "checkbox" somewhere and I understand |> from teh BEA |> folks that no-one uses it *really* but it needs to be |> there... so "wink" |> "wink" |> |> let me know PLEASE |> |> regards |> |> marcf |> |> _ |> Marc Fleury, Ph.D |> [EMAIL PROTECTED] |> _ |> |> |> |> ___ |> 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
RE: [JBoss-dev] FW: Busy wait on one thread
back in the land of confusion what I am trying to say since the beginning is this. please use the RabbitHole branch for ALL NEW FEATURES. Patches that needs to go in the 2.3/2.4 branches are to be commited there as well. Of course this fix you are talking about should be incorporated in BOTH branches... although I will defer to Scott as he controls what goes in the maintenance releases. If I understand the discussion with Scott correctly ([EMAIL PROTECTED]) the 2.2.x series is done and the next one will be a 2.4 version. The 2.4 version and the 3.0 will need to have the same fixes and patches, 3.0 will need to have the enhancements. pfff versioning incorporates so many artificial problems :) let's not loose our heads on just 2 branches and to all that COMMIT FROM NOW ON REMEMBER THAT WE NEED THE 2 BRANCHES TO GROW IN PARALLEL FOR THE FIXES... Scott, can you explain it for these people as well? Also feel free to correct me if anything wasn't accurate marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, June 11, 2001 3:00 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] FW: Busy wait on one thread | | |Cool, | |The mainline is 2.4? What happened to 2.3? Anyways, I'll check this code |in as soon as I figure out how to use WinCVS with SourceForge(I'm |looking at |Simone's directions from the dev-list archives). Hey, my first |checkin!(Well isn't that SPEciAaaal?!). | |Bill | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of marc |> fleury |> Sent: Monday, June 11, 2001 2:33 PM |> To: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] FW: Busy wait on one thread |> |> |> |> |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan |> |Christopherson |> |Sent: Monday, June 11, 2001 2:01 PM |> |To: [EMAIL PROTECTED] |> |Subject: RE: [JBoss-dev] FW: Busy wait on one thread |> | |> | |> |On Mon, 11 Jun 2001, Bill Burke wrote: |> | |> |> |> |> Again, IMHO, these race condition fixes can't wait until JBoss |> |3.0 since it |> |> sounds like 3.0 won't be ready until August/September? |> |> |> | |> |I agree with Bill here - the race condition fix really does |need to be in |> |2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the |> |synchronization interceptor (multiple instances per bean, etc.) |> |> yeah yeah yeah |> |> get the code in, of course 2.4 should be patched. |> |> marcf |> |> |> |> | |> |-danch |> | |> | |> |___ |> |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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RMI IIOP
Hi Marc, I would love to contribute to jboss and hope my decent experience can be helpful. btw, I am using JBoss (and hence on the list) for 6 months now. Thanks, Tahir > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 1:11 PM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: [JBoss-dev] RMI IIOP > > > So guys, > > now that it is a real requirement we need to put that in... > > ANYONE interested in taking that on? I would put the > red-carpet out for that > one brave soul. > > You know we need that "checkbox" somewhere and I understand > from teh BEA > folks that no-one uses it *really* but it needs to be > there... so "wink" > "wink" > > let me know PLEASE > > regards > > marcf > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > > ___ > 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] RMI IIOP
Marc, Being a primarily a CORBA guy, I'd like to give this a go... I'd sign up! cheers, peter --- marc fleury <[EMAIL PROTECTED]> wrote: > So guys, > > now that it is a real requirement we need to put > that in... > > ANYONE interested in taking that on? I would put the > red-carpet out for that > one brave soul. > > You know we need that "checkbox" somewhere and I > understand from teh BEA > folks that no-one uses it *really* but it needs to > be there... so "wink" > "wink" > > let me know PLEASE > > regards > > marcf > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Forte CVS access problem
Guys, I am unable to reach CVS (read access) from Forte. But, I am able to connect to the repository through jCVS ! Here are my (Forte) CVS settings: Server Type: pserver Server name: cvs.sourceforge.net Repository : /cvsroot/jboss Username : anonymous Password : (nothing) I get 'Login Failed...' on these settings. Is this a problem with Forte ? Anyone else also using this ? Any work arounds ? Forte Version: Forte for Java Release 2 Community Edition Build 1160. jCVS works fine with similar settings ! Any help / info would be highly appreciated. Thanks Ajay __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RMI IIOP
Guys, I would be working to add RMI-IIOP support to JBoss. Can I get some requirements for this ? Thanks Ajay --- marc fleury <[EMAIL PROTECTED]> wrote: > go right ahead ajay, > > please post to this list as you need help > understanding the proxy stuff > > marcf > > = ** There are no shortcuts to any place worth going ** Ajay Gautam __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
Cool, The mainline is 2.4? What happened to 2.3? Anyways, I'll check this code in as soon as I figure out how to use WinCVS with SourceForge(I'm looking at Simone's directions from the dev-list archives). Hey, my first checkin!(Well isn't that SPEciAaaal?!). Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, June 11, 2001 2:33 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan > |Christopherson > |Sent: Monday, June 11, 2001 2:01 PM > |To: [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] FW: Busy wait on one thread > | > | > |On Mon, 11 Jun 2001, Bill Burke wrote: > | > |> > |> Again, IMHO, these race condition fixes can't wait until JBoss > |3.0 since it > |> sounds like 3.0 won't be ready until August/September? > |> > | > |I agree with Bill here - the race condition fix really does need to be in > |2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the > |synchronization interceptor (multiple instances per bean, etc.) > > yeah yeah yeah > > get the code in, of course 2.4 should be patched. > > marcf > > > > | > |-danch > | > | > |___ > |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
[JBoss-dev] Verifier issue: checking Primary Key implementation for equals() and hashcode()
JBoss version: 2.2.1 EJB Spec: 1.1 - Section 9.2.9 File: org.jboss.verifier.strategy.EJBVerifier11.java method:verifyPrimaryKey(EntityMetadata entity) 9.2.9.b and 9.2.9.c The verifier in JBoss verifies that a primary key class implements the methods equals() and hashcode(). This complies to requirements described in section 9.2.9 of the EJB 1.1 spec. I believe that the way the verifier checks the presence of these methods in the primary key class is not valid. Here is what it does: - Create 2 instances of the primary key class using the default constructor. - The method "equals()" is assumed to be implemented if the method "equals()" returns "true" when comparing the 2 instances. - The method "hashcode()" is assumed to be implemented if the return value of both instances is the same hashcode. This type of check makes an assumption that 2 instances created with the default constructor should be equal but the spec says nothing about this. I think that the check should be done differently (using introspection maybe?) as the verifier may mistakenly think that a primary class is not compliant to the spec. Claude Montpetit Macadamian Technologies Inc. "Software solutions for leading ISVs and e-Business" _ http://www.macadamian.com [EMAIL PROTECTED] (613)739-5976 x107 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee
> "Jesper" == Jesper Pedersen <[EMAIL PROTECTED]> writes: Jesper> You can say that methods in an interface are abstract, since Jesper> the interface doesn't contain an implementation. Jesper> But I see no reason for declaring them abstract, since the Jesper> abstract keyword only has meaning when used in a class Jesper> definition. Jesper> Sun doesn't declare methods in the interfaces abstract -- Jesper> check the Javadoc generated from EJB 2.0 PFD2 compared to Jesper> jboss-j2ee. JLS 9.4: For compatibility with older versions of Java, it is permitted but discouraged, as a matter of style, to redundantly specify the _abstract_ modifier for methods declared in interfaces. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dan |Christopherson |Sent: Monday, June 11, 2001 2:01 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] FW: Busy wait on one thread | | |On Mon, 11 Jun 2001, Bill Burke wrote: | |> |> Again, IMHO, these race condition fixes can't wait until JBoss |3.0 since it |> sounds like 3.0 won't be ready until August/September? |> | |I agree with Bill here - the race condition fix really does need to be in |2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the |synchronization interceptor (multiple instances per bean, etc.) yeah yeah yeah get the code in, of course 2.4 should be patched. marcf | |-danch | | |___ |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] RMI IIOP
go right ahead ajay, please post to this list as you need help understanding the proxy stuff marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Ajay |Gautam |Sent: Monday, June 11, 2001 2:17 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RMI IIOP | | |Hi | |I would *LOVE* to do this. | |I have been a member of this list for a few weeks now. | |I have been waiting for a module to come up, on which |I can work. I think, this would be perfect. | |Let me know what you guys think. | |Ajay | |--- marc fleury <[EMAIL PROTECTED]> wrote: |> So guys, |> |> now that it is a real requirement we need to put |> that in... |> |> ANYONE interested in taking that on? I would put the |> red-carpet out for that |> one brave soul. |> |> You know we need that "checkbox" somewhere and I |> understand from teh BEA |> folks that no-one uses it *really* but it needs to |> be there... so "wink" |> "wink" |> |> let me know PLEASE |> |> regards |> |> marcf |> |> _ |> Marc Fleury, Ph.D |> [EMAIL PROTECTED] |> _ |> |> |> |> ___ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> |http://lists.sourceforge.net/lists/listinfo/jboss-development | | |= |** There are no shortcuts to any place worth going ** | |Ajay Gautam | |__ |Do You Yahoo!? |Get personalized email addresses from Yahoo! Mail - only $35 |a year! 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
Re: [JBoss-dev] RMI IIOP
Hi I would *LOVE* to do this. I have been a member of this list for a few weeks now. I have been waiting for a module to come up, on which I can work. I think, this would be perfect. Let me know what you guys think. Ajay --- marc fleury <[EMAIL PROTECTED]> wrote: > So guys, > > now that it is a real requirement we need to put > that in... > > ANYONE interested in taking that on? I would put the > red-carpet out for that > one brave soul. > > You know we need that "checkbox" somewhere and I > understand from teh BEA > folks that no-one uses it *really* but it needs to > be there... so "wink" > "wink" > > let me know PLEASE > > regards > > marcf > > _ > Marc Fleury, Ph.D > [EMAIL PROTECTED] > _ > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-development = ** There are no shortcuts to any place worth going ** Ajay Gautam __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
On Mon, 11 Jun 2001, Bill Burke wrote: > > Again, IMHO, these race condition fixes can't wait until JBoss 3.0 since it > sounds like 3.0 won't be ready until August/September? > I agree with Bill here - the race condition fix really does need to be in 2.4 (maybe even 2.2.x). 3.0 Should get a more aggressive rewrite of the synchronization interceptor (multiple instances per bean, etc.) -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Feature Requests-432122 ] JMX RMI Connector Enhancements
Hi Geeks According to the JMX Specification: - CONNECTORs create a transparent view to the remote MBS through Java which therefore needs Java on the client. Protocol examples are: RMI/RMI-IIOP/JMS - ADAPTORs allows you to connect to the remote MBeanServer through its protocol and needs not Java on the client. But the Adaptor has to translate the Objects and Request to the protocol it supports. Protocol examples are: HTML/JMS Please note that there is a missmatch in the protocols because HTML/RMI/RMI-IIOP are (sloppy) presentation protocols whereare JMS is a transport protocol. Therefore JMS can be used as Connector or as Adaptor because it depends on how you make the presentation on top of that (That is also the reason why I think HTTP is wrong because it is the transport protocol). Have fun - Andy > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 9:46 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] [ jboss-Feature Requests-432122 ] JMX RMI > Connector Enhancements > > > This is a good idea, > > part of what I want to do for JBoss 3.0 is the General > Purpose Architecture, > which offers connectors PER MBEANSERVER at the VM level, the > connectors can > be RMI, RMI/IIOP, SOAP, HTTP, JMS anything and we carry the > message to the > target containers (or MBeans). We would need to be able to > create a series > of connectors PER MBS in a given VM... > > will keep a thread on that one > > marc > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of > |[EMAIL PROTECTED] > |Sent: Monday, June 11, 2001 11:36 AM > |To: [EMAIL PROTECTED] > |Subject: [JBoss-dev] [ jboss-Feature Requests-432122 ] JMX > RMI Connector > |Enhancements > | > | > |Feature Requests item #432122, was updated on 2001-06-11 08:36 > |You can respond by visiting: > |http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&; > |group_id=22866 > | > |Category: None > |Group: None > |Status: Open > |Priority: 5 > |Submitted By: Nobody/Anonymous (nobody) > |Assigned to: Nobody/Anonymous (nobody) > |Summary: JMX RMI Connector Enhancements > | > |Initial Comment: > |Additional parameter to allow multiple JMX > |RMIConnector per host to be registered in a Naming > |Service. Currently we are limited to one > |RMIConnectorService per machine because of the name > |binding. This prevents the running of multiple agents > |in separate VMs (perhaps on a multi-processor machine) > |controled by multiple RMIConnectors. > | > | > |- > - > | > |You can respond by visiting: > |http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&; > |group_id=22866 > | > |___ > |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
RE: [JBoss-dev] FW: Busy wait on one thread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, June 11, 2001 12:43 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > I mean "chill" > > that it is kind of deep and I want to have a clear picture of where things > are at before we start "wild" commits on the locking. > "wild"?? This is why I'm begging people to review my "race condition fixes" email. The race condition problems I found are pretty nasty and the fixes that I made(if they are good ones) really should be in JBoss 2.3 and even be patched into JBoss 2.2.x. Also the fixes don't fundamentally change the locking code, but rather protect the InstanceCache more closely. Again, PLEASE review my race condition email. > This is how I got in this mess in the first place (with Simone). > IMHO, InstanceCache synchronization is a mess and should really be looked at closely, now. We're seeing a corrupted cache with light to medium load of 10-15 concurrent users at various times. (JBoss 2.2.1, Dual CPU, Commit-Option 'B', CMP/JAWS, Linux). > So I will make it up to you as I work my way back to coding JBoss 3.0. > > Do put your code in a JBOSS3.0 branch on which I would like to code and I > will review it shortly. > Again, IMHO, these race condition fixes can't wait until JBoss 3.0 since it sounds like 3.0 won't be ready until August/September? Thanks Bill > Can you or someone branch the codebase? > > marcf > > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill > |Burke > |Sent: Monday, June 11, 2001 11:44 AM > |To: [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] FW: Busy wait on one thread > | > | > | > | > |> -Original Message- > |> From: [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]On Behalf Of marc > |> fleury > |> Sent: Monday, June 11, 2001 11:27 AM > |> To: [EMAIL PROTECTED] > |> Subject: RE: [JBoss-dev] FW: Busy wait on one thread > |> > |> > |> let's chill on that one for a couple of days... it is a tricky one. > |> > | > |Do you mean 'chill' on ditching locking or my race-condition fixes? > | > |Bill > | > |> I did get it right the first time around (when we were > benching at SUN). > |> Simone put a fancier cache but missed the One-Busy-Wait error, I > |> will try to > |> fix it. Frankly I need to sit down and think about the options and the > |> locking strategy... > |> > |> marcf > |> > |> |-Original Message- > |> |From: [EMAIL PROTECTED] > |> |[mailto:[EMAIL PROTECTED]]On > Behalf Of danch > |> |Sent: Monday, June 11, 2001 12:40 PM > |> |To: [EMAIL PROTECTED] > |> |Subject: Re: [JBoss-dev] FW: Busy wait on one thread > |> | > |> | > |> |Bill Burke wrote: > |> | > |> |> Marc, > |> |> > |> |> I've rewritten EntityInstanceInterceptor a little(see my race > |> |condition fix > |> |> email please) and put it some code so that LOCKING-WAITING isn't > |> |printed a > |> |> zillion times. I also added a Thread.yield() before > continue; in the > |> |> lock-do-while-loop. > |> |> > |> |> > |> |> I've also started looking into ditching the do..while loop > in favor of > |> |> wait/notify. It's much more complicated than I originally > |> |anticipated, but > |> |> I'm making progress. IMHO, the whole locking business should > |> be ditched > |> |> when you have commit-option-C. Let the database to the > |> synching for you > |> |> with the select-for-update feature(CMP) or make the BMP > |> developers handle > |> |> the locking. > |> | > |> |That will require multiple instances of each bean to be spec > compliant. > |> | > |> |-danch > |> | > |> | > |> | > |> | > |> | > |> |___ > |> |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 > > > > ___ > 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] RabbitHole branch created
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Monday, June 11, 2001 1:38 PM |To: JBoss Dev |Subject: [JBoss-dev] RabbitHole branch created | | |I created a RabbitHole branch off of the current main line for prototyping |the 3.0 generation of JBoss. You can access the branch via the command |line version of cvs using: | |cvs -d |:ext:[EMAIL PROTECTED]:/cvsroot/jboss |co -r RabbitHole jboss mutex.unlock() watch for those race conditions down the rabbit hole... marcf | | | | |___ |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] RabbitHole branch created
I created a RabbitHole branch off of the current main line for prototyping the 3.0 generation of JBoss. You can access the branch via the command line version of cvs using: cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r RabbitHole jboss ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
|So I will make it up to you as I work my way back to coding JBoss 3.0. | |Do put your code in a JBOSS3.0 branch on which I would like to code and I |will review it shortly. | |Can you or someone branch the codebase? Scott Stark just send me an email saying that he will take care of creating the "RabbitHole" branch and that he will post instructions to the list on how to check the stuff out. So EVERYONE PLEASE WAIT FOR SCOTT TO DO IT. So just a sync email... dont' do anything on branching somebody just tagged the "mutex" ;-) regards marcf ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RMI IIOP
So guys, now that it is a real requirement we need to put that in... ANYONE interested in taking that on? I would put the red-carpet out for that one brave soul. You know we need that "checkbox" somewhere and I understand from teh BEA folks that no-one uses it *really* but it needs to be there... so "wink" "wink" let me know PLEASE regards marcf _ Marc Fleury, Ph.D [EMAIL PROTECTED] _ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Feature Requests-432122 ] JMX RMI Connector Enhancements
This is a good idea, part of what I want to do for JBoss 3.0 is the General Purpose Architecture, which offers connectors PER MBEANSERVER at the VM level, the connectors can be RMI, RMI/IIOP, SOAP, HTTP, JMS anything and we carry the message to the target containers (or MBeans). We would need to be able to create a series of connectors PER MBS in a given VM... will keep a thread on that one marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |[EMAIL PROTECTED] |Sent: Monday, June 11, 2001 11:36 AM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [ jboss-Feature Requests-432122 ] JMX RMI Connector |Enhancements | | |Feature Requests item #432122, was updated on 2001-06-11 08:36 |You can respond by visiting: |http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&; |group_id=22866 | |Category: None |Group: None |Status: Open |Priority: 5 |Submitted By: Nobody/Anonymous (nobody) |Assigned to: Nobody/Anonymous (nobody) |Summary: JMX RMI Connector Enhancements | |Initial Comment: |Additional parameter to allow multiple JMX |RMIConnector per host to be registered in a Naming |Service. Currently we are limited to one |RMIConnectorService per machine because of the name |binding. This prevents the running of multiple agents |in separate VMs (perhaps on a multi-processor machine) |controled by multiple RMIConnectors. | | |-- | |You can respond by visiting: |http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&; |group_id=22866 | |___ |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] FW: Busy wait on one thread
I mean "chill" that it is kind of deep and I want to have a clear picture of where things are at before we start "wild" commits on the locking. This is how I got in this mess in the first place (with Simone). So I will make it up to you as I work my way back to coding JBoss 3.0. Do put your code in a JBOSS3.0 branch on which I would like to code and I will review it shortly. Can you or someone branch the codebase? marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Bill |Burke |Sent: Monday, June 11, 2001 11:44 AM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] FW: Busy wait on one thread | | | | |> -Original Message- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]On Behalf Of marc |> fleury |> Sent: Monday, June 11, 2001 11:27 AM |> To: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] FW: Busy wait on one thread |> |> |> let's chill on that one for a couple of days... it is a tricky one. |> | |Do you mean 'chill' on ditching locking or my race-condition fixes? | |Bill | |> I did get it right the first time around (when we were benching at SUN). |> Simone put a fancier cache but missed the One-Busy-Wait error, I |> will try to |> fix it. Frankly I need to sit down and think about the options and the |> locking strategy... |> |> marcf |> |> |-Original Message- |> |From: [EMAIL PROTECTED] |> |[mailto:[EMAIL PROTECTED]]On Behalf Of danch |> |Sent: Monday, June 11, 2001 12:40 PM |> |To: [EMAIL PROTECTED] |> |Subject: Re: [JBoss-dev] FW: Busy wait on one thread |> | |> | |> |Bill Burke wrote: |> | |> |> Marc, |> |> |> |> I've rewritten EntityInstanceInterceptor a little(see my race |> |condition fix |> |> email please) and put it some code so that LOCKING-WAITING isn't |> |printed a |> |> zillion times. I also added a Thread.yield() before continue; in the |> |> lock-do-while-loop. |> |> |> |> |> |> I've also started looking into ditching the do..while loop in favor of |> |> wait/notify. It's much more complicated than I originally |> |anticipated, but |> |> I'm making progress. IMHO, the whole locking business should |> be ditched |> |> when you have commit-option-C. Let the database to the |> synching for you |> |> with the select-for-update feature(CMP) or make the BMP |> developers handle |> |> the locking. |> | |> |That will require multiple instances of each bean to be spec compliant. |> | |> |-danch |> | |> | |> | |> | |> | |> |___ |> |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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of marc > fleury > Sent: Monday, June 11, 2001 11:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] FW: Busy wait on one thread > > > let's chill on that one for a couple of days... it is a tricky one. > Do you mean 'chill' on ditching locking or my race-condition fixes? Bill > I did get it right the first time around (when we were benching at SUN). > Simone put a fancier cache but missed the One-Busy-Wait error, I > will try to > fix it. Frankly I need to sit down and think about the options and the > locking strategy... > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of danch > |Sent: Monday, June 11, 2001 12:40 PM > |To: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] FW: Busy wait on one thread > | > | > |Bill Burke wrote: > | > |> Marc, > |> > |> I've rewritten EntityInstanceInterceptor a little(see my race > |condition fix > |> email please) and put it some code so that LOCKING-WAITING isn't > |printed a > |> zillion times. I also added a Thread.yield() before continue; in the > |> lock-do-while-loop. > |> > |> > |> I've also started looking into ditching the do..while loop in favor of > |> wait/notify. It's much more complicated than I originally > |anticipated, but > |> I'm making progress. IMHO, the whole locking business should > be ditched > |> when you have commit-option-C. Let the database to the > synching for you > |> with the select-for-update feature(CMP) or make the BMP > developers handle > |> the locking. > | > |That will require multiple instances of each bean to be spec compliant. > | > |-danch > | > | > | > | > | > |___ > |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
[JBoss-dev] [ jboss-Feature Requests-432122 ] JMX RMI Connector Enhancements
Feature Requests item #432122, was updated on 2001-06-11 08:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: JMX RMI Connector Enhancements Initial Comment: Additional parameter to allow multiple JMX RMIConnector per host to be registered in a Naming Service. Currently we are limited to one RMIConnectorService per machine because of the name binding. This prevents the running of multiple agents in separate VMs (perhaps on a multi-processor machine) controled by multiple RMIConnectors. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376688&aid=432122&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Local interfaces prototype
The question is coming from reviewing the code because I hadn't found how the interceptors were getting brought into the picture. I am updating the security interceptor to handle changes in the 2.0 spec and wanted to make sure security will work with the local interfaces. I'll trace the exectution path more throughly and comment on any issue I see. - Original Message - From: "Dan OConnor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 6:06 AM Subject: Re: [JBoss-dev] Local interfaces prototype > Hi Scott, > > Thanks for reviewing the code. > > A method invocation on a local interface calls the standard > container method invokeHome(MethodInvocation mi) or > invoke(MethodInvocation mi). From this point on, there is no > differentiation between a local call and a remote call in terms of the > path through the architecture (although some methods--such as > finder methods--behave differently depending on whether they are in > a remote or local home interface). > > The container calls getInterceptor().invoke(MethodInvocation) or > getInterceptor().invokeHome(MethodInvocation). The last interceptor > in the chain is the container's own "interceptor." Again, this > functionality isn't changed; what changed is the mapping of > methods to beans that this last interceptor references. (So you use > the same interceptors for local and remote interfaces.) > > On the way back out, I need to swizzle some exceptions that > inherit from RemoteException (to conform to the specification). > This swizzling is done in the BaseLocalContainerInvoker. > > Is this question just from code review, or did you notice incorrect > runtime behavior? > > -Dan > > On 10 Jun 01, at 16:23, Scott M Stark wrote: > > > I can't seem to find how the current interceptor architecture plugs into > > the local interfaces method invocation. Does this exist? > > > > - Original Message - > > From: "Dan OConnor" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, June 04, 2001 3:39 PM > > Subject: [JBoss-dev] Local interfaces prototype > > > > > > > Hi, > > > > > > With (much appreciated) help from Jay Walters, I've added a > > > prototype for support of local interfaces to CVS. There are many > > > aspects of this I haven't tested (e.g. a bean with both local and > > > remote interfaces, functionality of the EnterpriseContext, etc.), so I > > > was hoping that some of you familiar with the EJB 2.0 spec could > > > use them a little and post problems to this list or Sourceforge bug > > > tracker... or, of course, fix problems yourself. :-) > > > > > > I'm not posting this announcement to jboss-user because local > > > interface support definitely needs a little time to cook before it > > > enters general use. Please help me to cook it. Anyone who > > > disagrees with this may go ahead and cross post without further > > > discussion. :-) > > > > > > Just a quick design note for the code reviewers: I modeled local > > > interface support on the JRMP container invoker whenever > > > possible, so that someone familiar with that code base would > > > instantly understand what I was doing. However, I thought it better > > > not to add local interface support to the existing pluggable > > > ContainerInvoker system. This is because the local interfaces > > > implementation can remain constant as the distribution mechanism > > > (e.g. RMI/JRMP, CORBA, whatever...) changes. So local interfaces > > > are broken out. > > > > > > Also, you'll notice that I do not publish the home interface in our > > > JNDI system, except in a component name space when a bean > > > uses an ejb-local-ref. There is no reason to make the home globally > > > available, since local interfaces will only work for components > > > within an application. So instead, I publish the interfaces to the > > > application class. > > > > > > Finally, I made a small change to the verifier so it doesn't throw an > > > exception when a bean without remote interfaces is deployed. > > > However, you should know the local interfaces are not verified. > > > (Quick reminder: don't throw java.rmi.RemoteException.) > > > > > > -Dan O'Connor > > > > > > ___ > > > 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 > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] FW: Busy wait on one thread
let's chill on that one for a couple of days... it is a tricky one. I did get it right the first time around (when we were benching at SUN). Simone put a fancier cache but missed the One-Busy-Wait error, I will try to fix it. Frankly I need to sit down and think about the options and the locking strategy... marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of danch |Sent: Monday, June 11, 2001 12:40 PM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] FW: Busy wait on one thread | | |Bill Burke wrote: | |> Marc, |> |> I've rewritten EntityInstanceInterceptor a little(see my race |condition fix |> email please) and put it some code so that LOCKING-WAITING isn't |printed a |> zillion times. I also added a Thread.yield() before continue; in the |> lock-do-while-loop. |> |> |> I've also started looking into ditching the do..while loop in favor of |> wait/notify. It's much more complicated than I originally |anticipated, but |> I'm making progress. IMHO, the whole locking business should be ditched |> when you have commit-option-C. Let the database to the synching for you |> with the select-for-update feature(CMP) or make the BMP developers handle |> the locking. | |That will require multiple instances of each bean to be spec compliant. | |-danch | | | | | |___ |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] JMSContainerInvoker.java
what I am hearing is that you want jbossmq/jboss/servlet configuration in xml snippets in jboss.jcml, otherwise I don't see what it brings except yet another layer of indirection... marc |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Peter |Antman |Sent: Monday, June 11, 2001 3:02 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] JMSContainerInvoker.java | | |On 10 Jun, marc fleury wrote: |> |I do like simplicity of management (that why I redo every JBoss |> |distribution so I can configure it with a single property file - Ant, |> |copy and filter). |> |> what do you mean, what do you redo? | |Short example: | |>From jboss.jcml: | | |@rmi.port@ | | | |You see the @rmi.port@ | |In a propertyfile, for example default.properties ;-) | |rmi.port=1099 | | |Some stuff in build.xml: | | | |This may be reset dynamicaly with -Dtemplates.properties to use other |values for an installation. | |Turn on filtering while copying: | | | | | | | | |Makes it a snapp to install differently configured JBoss servers, just |write a new property file to make your installment from. | |I particulary like this in jbossmq.xml: | |bob |@topics@ | |This is where I drive my destination configurations ;-) | | |> |> | |> |# Here some code |> | |> |set_my_variable(11); |> |print get_my_variable; |> | |> |What do you think one will get, yes 1. Do you get any warnings? NO. Is |> |it hard to debug? Oh, yes. Verry hard. |> | |> |I think automatic creation of destinations for MDB suffers the same of |> |problems. |> |> geez you guys are all banging on this feature... you know what? |> |> two peas in a bucket |> |> f*ck it! (as my father in law will say (deep south))... |> |> we will see if people complain | |Calm down ;-) | |> |> |What happens when a created destination is suddenly destroyed when the |> |MDB is undeployed (perhaps for a redeploy because of code change)? Well, |> |all publisher to that destination will bark and be gone (if they was not |> |coded to be failsafe). Suddenly we do not have a loosly coupled system |> |any more, but the destination becomes just another remote interface |> |against the bean (answer: use stateless sessions instead of MDB). |> |> uh tell me how is that related to the fact that we create it at |> deployment time? if you remove a destination (period) then all |clients will |> be barking... if not then create a "durable topic" in the right |JMS stuff... |> we are not out to solve the world problems, if you want a durable topic |> then you need to tell us. I still stick to my guns (and I could |be wrong) |> |> |Ok,ok,ok. The only (I say only) acceptable thing a can think of is that |> |it *might* be OK if the jboss.xml is completly missing. Then we might do |> |somethink like automatic creation, *but only then*. |> |> ah... look at me in the eye... yes I do see that gleam in the |corner of your |> eye... you still see it don't you? yeah..ease of use for management, the |> "dirty step child" of J2EE we are squarely competing at the low end with |> very high end features for management... yeah you know it! yeah that |> gleam... | |He, he. But see further down too. Should it really be in |JMSContainerInvoker. One thing thats bothers me is that there are |several indications on that JBossMQ is actually not that production |ready. It behaves eratic during heavy load (messages are lost, and it is |VERRY slow), there are some creapy buggs in the management of durable |topic subscription, a server may dissapear without the clients ever |getting to know it, and probably much more. | |Hiram has done a fantastic jobb, but he does not seem to have that much |time any longer, and no one else has really showed up to take over or |work with the hard parts beside him. | |I know there are some potential guys in there, that could probably solve |this stuff. | |But until that has happened it is probably wise to have an |implementation of MDB that is possible to use with another JMS provider. | |Or, Marc, try to inspire some of the wise guys on this list to take on |JBossMQ. It would actually be good if there where more than one |developer active with JBossMQ at a time. | | |//Peter |> |> (drunk) |> |> marcf |> | |> |2. Is it a good think to implement it in JMSContainerInvoker? |> | |> |Well, maybe not. The container invoker is designed to be agnostic about |> |the underlying JMS provider. All its ways to communicate with the JMS |> |provider is done through indirection and interfaces. If this is placed |> |in JMSContainerInvoker it should not be dependand on any special JBossMQ |> |features, such as being able to create destinations on the fly through |> |JMX. Or perhaps to be more correct, if this is done, is must be a part |> |of the org.jboss.jms package that a JMX based destination creator is |> |part of the JMSContainerInvoker contact. |> | |> |Was that clear, or am I just babling around? |> | |> |Chers |> |Peter |> | |> | |> |On 1 Jun, H
RE: [JBoss-dev] FW: Busy wait on one thread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Georg > Rehfeld > Sent: Monday, June 11, 2001 8:49 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] FW: Busy wait on one thread > > > Hi Bill, > > > I've rewritten EntityInstanceInterceptor a little(see my race condition > fix > > email please) and put it some code so that LOCKING-WAITING > isn't printed a > > zillion times. I also added a Thread.yield() before continue; in the > > lock-do-while-loop. > > nice to hear that. > > > I've also started looking into ditching the do..while loop in favor of > > wait/notify. It's much more complicated than I originally anticipated, > but > > I'm making progress. IMHO, the whole locking business should be ditched > > when you have commit-option-C. Let the database to the synching for you > > with the select-for-update feature(CMP) or make the BMP > developers handle > > the locking. > As of this moment, I'm not working on removing the whole locking business. So if somebody wants to take it on, please do. > I assume including the activation of MULTIPLE bean instances? > 9.1.11 Fig 24. > I read the spec, but am confused on how MULTIPLE bean instances work with commit-option 'B'. Do you still have an instance cache for commit-option 'B' and only grab from this cache when there is no transaction associated with the method invokation? > And then, don't forget about optimistic locking behaviour, which > would help a lot when many clients mostly access beans concurrently > for read only purpose. Optimistic locking (sort of) can be mimicked > with relational DBs that don't have it built in by using a where > clause in update/delete that not only specifies the PK values (or > the rowid) but also all changed fields with their OLD values. > > A CMP/JAWS impl would require the old state to be saved and > generating dynamic WHERE SQL clauses based on the diff. BMP > developers have to do it similar by hand. > Really cool stuff! This can be easily implemented in CMP/JAWS since JAWS keeps the old state alive. Bill > Sample for readers unfamiliar with SQL (nobody here): > > bean fields: pk, name, address; address changed, old state known > generated SQL: > > update bean > setaddress = > where pk = > ANDaddress = > > This way the SQL can only update 1 row, when nobody has concurrently > modified the changed fields, if statement.executeUpdate() returns > 0 it must be interpreted as a concurrent modification coming too > late and the TX must be rolled back. > > Another variant could use a time stamp field similarly. > > regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > 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] remove(Object pk) support in JBoss
Has anyone successfully deployed an entity bean--on JBoss 2.0--that implements the remove(Object pk) method of the EJBHome interface? The JBoss verifier seems to want to only allow 'create' and 'findBy' methods on the home interface. If someone could point me to documentation on this, I'd be much obliged. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] race condition in EntityInstanceInterceptor FIXED?
(I'm resending this, because it didn't seem to show up on jboss-dev. If you
want the actually source code I changed, please email me.)
All,
I really need another set of eyes to check out some code changes I've made.
I'll check this in a day or so if I don't get any feedback. We've been
having some problems lately with findBy methods that return references to
the wrong rows in the database. (Please see the dev-threads "Serious Bug?
EntityBean out of synch with database" and "race condition between
EntityInstanceInterceptor"). In examining EntityInstanceInterceptor and
EntitySynchronizationInterceptor.InstanceSynchronization I found a race
condition and one other problem when an EntityInstanceCache.remove() is
called(within a rollback or an exception). Also there are potential problems
with re-entrant beans not getting a transactional "lock" because
EntityEnterpriseContext.setTransaction is not done in a mutex lock block.
race condition:
- When a rollback happens within a transaction,
InstanceSynchronization.afterCompletion would call ctx.setTransaction(null)
and would not protect the EntityEnterpriseContext with a mutex lock. There
it was quite possible for another thread waiting for the entity bean to
leave it's transaction to wakeup, do a cache.get(id) before afterCompletion
did a cache.remove and an InstancePool.free.(I actually wrote a little test
that did a sleep after ctx.setTransaction(null) to verify this). Really bad
things can happen like the context being put back into the instance pool
while another thread thinks the context is still valid.
invalid mutexes:
- When an EntityInstanceCache.remove is called, the Entity's mutex is
disassociated with the id of the Entity. Thus, all threads waiting on the
same bean will be locking on an invalid mutex if EntityInstanceCache.remove
is called.
ctx.setTransaction not synchronized
- setTransaction is called within EntityContainer.ContainerInterceptor. The
mutex of the Entity is NOT acquire before this is done, therefore, with
re-entrant beans, you can possibly have 2 transaction working on the same
entity instance.
Too many LOCKING-WAITING messages:
- You server.log file can grow to 100 megabytes or more very quickly when
beans are in contention.
FIXES!!
Files changed:
AbstractInstanceCache.java
EntityInstanceCache.java
EntityInstanceInterceptor.java
EntitySynchronizationInterceptor.java
Files added:
BeanSemaphore.java
- Wherever there is an EntityInstanceCache.remove(), I make sure that I
acquire the mutex of the entity before doing this.
- I added the ability to invalidate a mutex. When
AbstractInstanceCache.removeLock is called, the mutex is flagged as invalid.
EntityInstanceInterceptor checks for this and does a re-lookup of the mutex.
- I do ctx.setTransaction within the EntityInstanceInterceptor to ensure
that a transactional lock happens. THis will fix the re-entrant bean problem
I discussed earlier.
- I put in some code in EntityInstanceInterceptor so that LOCKING-WAITING
messages don't happen continuously.
- Put in a Thread.yield() in the infamous EntityInstanceInterceptor
do..while loop.
- Added an extension of org.jboss.util.Semaphore, BeanSemaphore, for
invalidation of mutexes.
- Added an id check in EntityInstanceCache.get to make sure that the key
you're looking up on is equal the the EntityEnterpriseContext.getId()
Thanks in advance for any help with this,
Bill
DIFFS
cvs diff -w EntitySynchronizationInterceptor.java
EntityInstanceInterceptor.java EntityInstanceCache.java
AbstractInstanceCache.java (in directory
D:\main\jboss2.3_src\jboss\src\main\org\jboss\ejb\plugins)
Index: EntitySynchronizationInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/EntitySynchronizationInt
erceptor.java,v
retrieving revision 1.34
diff -w -r1.34 EntitySynchronizationInterceptor.java
39a40
> import org.jboss.util.Sync;
414c415,421
<
---
> EntityContainer container = (EntityContainer)ctx.getContainer();
> AbstractInstanceCache cache =
(AbstractInstanceCache)container.getInstanceCache();
> Object id = ctx.getCacheKey();
> // Hopefully this transaction has an exclusive lock
> // on this id so that cache.getLock returns a mutex that is being
> // used by every other thread on this id.
> Sync mutex = (Sync)cache.getLock(id);
416c423,425
<
---
> // We really should be acquiring a mutex before
> // mucking with the InstanceCache or InstancePool
> mutex.acquire();
420a430,431
> // removing from the cache should also invalidate the mutex thus waking up
> // other threads.
423a435,438
> // REVISIT: FIXME:
> // We really should only let passivation free an instance because it is
> // quite possible that another thread is working with
> // the same context, but let's do it anyways.
429c444,447
<
---
> finally
> {
>
Re: [JBoss-dev] FW: Busy wait on one thread
Bill Burke wrote: > Marc, > > I've rewritten EntityInstanceInterceptor a little(see my race condition fix > email please) and put it some code so that LOCKING-WAITING isn't printed a > zillion times. I also added a Thread.yield() before continue; in the > lock-do-while-loop. > > > I've also started looking into ditching the do..while loop in favor of > wait/notify. It's much more complicated than I originally anticipated, but > I'm making progress. IMHO, the whole locking business should be ditched > when you have commit-option-C. Let the database to the synching for you > with the select-for-update feature(CMP) or make the BMP developers handle > the locking. That will require multiple instances of each bean to be spec compliant. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee
I'll begin the work tomorrow :) Cheers, /Jesper On Monday 11 June 2001 15:33, you wrote: > You're right. I can't find the javadoc on my machine that had the abstract > methods in interfaces, but the only files I actually did myself were the > Connector API ones and I don't seem to have that Javadoc right now. Maybe > it was in the O'Reilly book appendix? I remember thinking it was odd when > I saw it. It's not important. > > As I said in my previous email the abstract keyword on an interface method > clearly will have no impact, so feel free to change it. > > As for the javadoc, we had a pretty fair amount on the initial checkin, but > I wouldn't be surprised if we missed some, or if some is missing on the > latest 2.0 bits so again feel free to add. > > Cheers > > -Original Message- > From: Jesper Pedersen [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 11, 2001 7:07 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > > You can say that methods in an interface are abstract, since the > interface doesn't contain an implementation. > > But I see no reason for declaring them abstract, since the abstract keyword > only has meaning when used in a class definition. > > Sun doesn't declare methods in the interfaces abstract -- check the Javadoc > generated from EJB 2.0 PFD2 compared to jboss-j2ee. > > I think we -- and I would be willing to do that -- should clean the > interfaces such that they don't use the abstract keyword. > > And a bit more Javadoc wouldn't hurt ;) > > Cheers, > > Jesper > > On Monday 11 June 2001 12:22, you wrote: > > Not from the point of view of how things work. Interfaces are always > > abstract. I am pretty sure that is the way sun declares them which is > > why we did them that way first time. > > > > Javadoc certainly won't hurt. > > > > By he way Marc F, Jesper did the first pass of EJB 2.0 support for the > > jboss-j2ee project so he's been contributing... > > > > Cheers > > > > -Original Message- > > From: Jesper Pedersen > > To: [EMAIL PROTECTED] > > Sent: 6/11/01 2:39 AM > > Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > > > Hi. > > > > Is there a reason for declaring the interface methods in jboss-j2ee for > > abstract ? > > > > If not I'll clean it up and add JavaDoc ;) > > > > Cheers, > > > > Jesper > > ___ > 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
Re: [JBoss-dev] FW: Busy wait on one thread
Hi, I like your idea for optimistic locking, however I think generally you need to check that -no- fields have been changed, not just the ones you changed. These are two different behaviors, sometimes you want one and sometimes the other, but I think as a default you are more likely to want the -no- fields changed option. This is more like what versioning db's such as interbase/firebird do. david jencks On 2001.06.11 08:48:57 -0400 Georg Rehfeld wrote: > Hi Bill, > > > I've rewritten EntityInstanceInterceptor a little(see my race condition > fix > > email please) and put it some code so that LOCKING-WAITING isn't > printed a > > zillion times. I also added a Thread.yield() before continue; in the > > lock-do-while-loop. > > nice to hear that. > > > I've also started looking into ditching the do..while loop in favor of > > wait/notify. It's much more complicated than I originally anticipated, > but > > I'm making progress. IMHO, the whole locking business should be > ditched > > when you have commit-option-C. Let the database to the synching for > you > > with the select-for-update feature(CMP) or make the BMP developers > handle > > the locking. > > I assume including the activation of MULTIPLE bean instances? > 9.1.11 Fig 24. > > And then, don't forget about optimistic locking behaviour, which > would help a lot when many clients mostly access beans concurrently > for read only purpose. Optimistic locking (sort of) can be mimicked > with relational DBs that don't have it built in by using a where > clause in update/delete that not only specifies the PK values (or > the rowid) but also all changed fields with their OLD values. > > A CMP/JAWS impl would require the old state to be saved and > generating dynamic WHERE SQL clauses based on the diff. BMP > developers have to do it similar by hand. > > Sample for readers unfamiliar with SQL (nobody here): > > bean fields: pk, name, address; address changed, old state known > generated SQL: > > update bean > setaddress = > where pk = > ANDaddress = > > This way the SQL can only update 1 row, when nobody has concurrently > modified the changed fields, if statement.executeUpdate() returns > 0 it must be interpreted as a concurrent modification coming too > late and the TX must be rolled back. > > Another variant could use a time stamp field similarly. > > regards > Georg > ___ ___ > | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg > |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 > > > > ___ > 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] Reason for abstract methods in jboss-j2ee
You're right. I can't find the javadoc on my machine that had the abstract methods in interfaces, but the only files I actually did myself were the Connector API ones and I don't seem to have that Javadoc right now. Maybe it was in the O'Reilly book appendix? I remember thinking it was odd when I saw it. It's not important. As I said in my previous email the abstract keyword on an interface method clearly will have no impact, so feel free to change it. As for the javadoc, we had a pretty fair amount on the initial checkin, but I wouldn't be surprised if we missed some, or if some is missing on the latest 2.0 bits so again feel free to add. Cheers -Original Message- From: Jesper Pedersen [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 7:07 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee You can say that methods in an interface are abstract, since the interface doesn't contain an implementation. But I see no reason for declaring them abstract, since the abstract keyword only has meaning when used in a class definition. Sun doesn't declare methods in the interfaces abstract -- check the Javadoc generated from EJB 2.0 PFD2 compared to jboss-j2ee. I think we -- and I would be willing to do that -- should clean the interfaces such that they don't use the abstract keyword. And a bit more Javadoc wouldn't hurt ;) Cheers, Jesper On Monday 11 June 2001 12:22, you wrote: > Not from the point of view of how things work. Interfaces are always > abstract. I am pretty sure that is the way sun declares them which is why > we did them that way first time. > > Javadoc certainly won't hurt. > > By he way Marc F, Jesper did the first pass of EJB 2.0 support for the > jboss-j2ee project so he's been contributing... > > Cheers > > -Original Message- > From: Jesper Pedersen > To: [EMAIL PROTECTED] > Sent: 6/11/01 2:39 AM > Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > Hi. > > Is there a reason for declaring the interface methods in jboss-j2ee for > abstract ? > > If not I'll clean it up and add JavaDoc ;) > > Cheers, > > Jesper ___ 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] Local interfaces prototype
On 10 Jun 01, at 20:57, marc fleury wrote: > , I am not sure I understand the thought fully but the CI stuff is going > to be fully detached from the invocation layer (part of Rabbit hole). I > have a pretty clear idea on how to do that so the local interface should > just be a plug in teh container directly, bypassing all invocation, and > definitely independent of RMI, Corba, SOAP etc etc... Local interfaces are independent of the distribution protocol (JRMP, CORBA, SOAP, whatever). They are a plug hard-coded into the existing container that never needs to change. We are on the same page. > Pardon my ignorance of teh 2.0 spec but the whole stack of interceptors > still needs to be there for the local stuff right? in other words, the only > thing you bypass is the RemoteContainerInvoker stuff right? I am going to > remove that in the near future anyway... Absolutely. The whole stack of interceptors needs to be there. > Finally, I thought that a bean could be Remote or Local and that it was > transparent to the container, and we could use the same chain of Absolutely. A bean can have remote interfaces, local interfaces, or both; and I do use the same chain of interceptors and even the same "invoke" methods on the container. However, it is not exactly transparent to the container. For instance, a finder method on a remote home interface returns a remote component interface. The exact same finder method on a local home interface (e.g. findByPrimaryKey) returns a local component interface. But this is easy to handle through the existing method mapping infrastructure. > invocations I understand that this is a separate container stack > instanciated? so that you only have one mode of operation? No (unless I misunderstood the question). -Dan > > marcf > > | > |-Dan O'Connor > | > |___ > |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
Re: [JBoss-dev] FW: Busy wait on one thread
Hi Bill, > I've rewritten EntityInstanceInterceptor a little(see my race condition fix > email please) and put it some code so that LOCKING-WAITING isn't printed a > zillion times. I also added a Thread.yield() before continue; in the > lock-do-while-loop. nice to hear that. > I've also started looking into ditching the do..while loop in favor of > wait/notify. It's much more complicated than I originally anticipated, but > I'm making progress. IMHO, the whole locking business should be ditched > when you have commit-option-C. Let the database to the synching for you > with the select-for-update feature(CMP) or make the BMP developers handle > the locking. I assume including the activation of MULTIPLE bean instances? 9.1.11 Fig 24. And then, don't forget about optimistic locking behaviour, which would help a lot when many clients mostly access beans concurrently for read only purpose. Optimistic locking (sort of) can be mimicked with relational DBs that don't have it built in by using a where clause in update/delete that not only specifies the PK values (or the rowid) but also all changed fields with their OLD values. A CMP/JAWS impl would require the old state to be saved and generating dynamic WHERE SQL clauses based on the diff. BMP developers have to do it similar by hand. Sample for readers unfamiliar with SQL (nobody here): bean fields: pk, name, address; address changed, old state known generated SQL: update bean setaddress = where pk = ANDaddress = This way the SQL can only update 1 row, when nobody has concurrently modified the changed fields, if statement.executeUpdate() returns 0 it must be interpreted as a concurrent modification coming too late and the TX must be rolled back. Another variant could use a time stamp field similarly. regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Local interfaces prototype
Hi Scott, Thanks for reviewing the code. A method invocation on a local interface calls the standard container method invokeHome(MethodInvocation mi) or invoke(MethodInvocation mi). From this point on, there is no differentiation between a local call and a remote call in terms of the path through the architecture (although some methods--such as finder methods--behave differently depending on whether they are in a remote or local home interface). The container calls getInterceptor().invoke(MethodInvocation) or getInterceptor().invokeHome(MethodInvocation). The last interceptor in the chain is the container's own "interceptor." Again, this functionality isn't changed; what changed is the mapping of methods to beans that this last interceptor references. (So you use the same interceptors for local and remote interfaces.) On the way back out, I need to swizzle some exceptions that inherit from RemoteException (to conform to the specification). This swizzling is done in the BaseLocalContainerInvoker. Is this question just from code review, or did you notice incorrect runtime behavior? -Dan On 10 Jun 01, at 16:23, Scott M Stark wrote: > I can't seem to find how the current interceptor architecture plugs into > the local interfaces method invocation. Does this exist? > > - Original Message - > From: "Dan OConnor" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, June 04, 2001 3:39 PM > Subject: [JBoss-dev] Local interfaces prototype > > > > Hi, > > > > With (much appreciated) help from Jay Walters, I've added a > > prototype for support of local interfaces to CVS. There are many > > aspects of this I haven't tested (e.g. a bean with both local and > > remote interfaces, functionality of the EnterpriseContext, etc.), so I > > was hoping that some of you familiar with the EJB 2.0 spec could > > use them a little and post problems to this list or Sourceforge bug > > tracker... or, of course, fix problems yourself. :-) > > > > I'm not posting this announcement to jboss-user because local > > interface support definitely needs a little time to cook before it > > enters general use. Please help me to cook it. Anyone who > > disagrees with this may go ahead and cross post without further > > discussion. :-) > > > > Just a quick design note for the code reviewers: I modeled local > > interface support on the JRMP container invoker whenever > > possible, so that someone familiar with that code base would > > instantly understand what I was doing. However, I thought it better > > not to add local interface support to the existing pluggable > > ContainerInvoker system. This is because the local interfaces > > implementation can remain constant as the distribution mechanism > > (e.g. RMI/JRMP, CORBA, whatever...) changes. So local interfaces > > are broken out. > > > > Also, you'll notice that I do not publish the home interface in our > > JNDI system, except in a component name space when a bean > > uses an ejb-local-ref. There is no reason to make the home globally > > available, since local interfaces will only work for components > > within an application. So instead, I publish the interfaces to the > > application class. > > > > Finally, I made a small change to the verifier so it doesn't throw an > > exception when a bean without remote interfaces is deployed. > > However, you should know the local interfaces are not verified. > > (Quick reminder: don't throw java.rmi.RemoteException.) > > > > -Dan O'Connor > > > > ___ > > 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
Re: [JBoss-dev] Reason for abstract methods in jboss-j2ee
You can say that methods in an interface are abstract, since the interface doesn't contain an implementation. But I see no reason for declaring them abstract, since the abstract keyword only has meaning when used in a class definition. Sun doesn't declare methods in the interfaces abstract -- check the Javadoc generated from EJB 2.0 PFD2 compared to jboss-j2ee. I think we -- and I would be willing to do that -- should clean the interfaces such that they don't use the abstract keyword. And a bit more Javadoc wouldn't hurt ;) Cheers, Jesper On Monday 11 June 2001 12:22, you wrote: > Not from the point of view of how things work. Interfaces are always > abstract. I am pretty sure that is the way sun declares them which is why > we did them that way first time. > > Javadoc certainly won't hurt. > > By he way Marc F, Jesper did the first pass of EJB 2.0 support for the > jboss-j2ee project so he's been contributing... > > Cheers > > -Original Message- > From: Jesper Pedersen > To: [EMAIL PROTECTED] > Sent: 6/11/01 2:39 AM > Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee > > Hi. > > Is there a reason for declaring the interface methods in jboss-j2ee for > abstract ? > > If not I'll clean it up and add JavaDoc ;) > > Cheers, > > Jesper ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Reason for abstract methods in jboss-j2ee
Not from the point of view of how things work. Interfaces are always abstract. I am pretty sure that is the way sun declares them which is why we did them that way first time. Javadoc certainly won't hurt. By he way Marc F, Jesper did the first pass of EJB 2.0 support for the jboss-j2ee project so he's been contributing... Cheers -Original Message- From: Jesper Pedersen To: [EMAIL PROTECTED] Sent: 6/11/01 2:39 AM Subject: [JBoss-dev] Reason for abstract methods in jboss-j2ee Hi. Is there a reason for declaring the interface methods in jboss-j2ee for abstract ? If not I'll clean it up and add JavaDoc ;) Cheers, Jesper -- Jesper Pedersen, M.Sc. C.S.E Open Source Solution Manager Sun Certified Java 2 Developer IT+ A/S Phone: +45 86 78 21 00 Brendstrupgårdsvej 7 Fax: +45 86 78 21 02 8200 Århus N Direct:+45 87 40 08 49 Denmark Email: [EMAIL PROTECTED] ___ 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] Mail!
there you go! Vinay PS: Good to see you back on the list! - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "User @ JBoss" <[EMAIL PROTECTED]> Sent: Monday, June 11, 2001 2:14 AM Subject: RE: [JBoss-dev] Mail! > Just turn off the f***ing Html and you will see that it will work :) > > marc > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of K.V. > Vinay Menon > Sent: Monday, June 04, 2001 12:15 PM > To: User @ JBoss; Dev @ JBoss > Subject: [JBoss-dev] Mail! > > > Is it just me or is the mailiing list not working! Don't seem to get any > of my mails! [And yes, I have chosen to receive copies of my mails] > > Vinay > ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins SecurityProxyInterceptor.java SecurityInterceptor.java
User: starksm
Date: 01/06/11 00:04:15
Modified:src/main/org/jboss/ejb/plugins SecurityInterceptor.java
Added: src/main/org/jboss/ejb/plugins SecurityProxyInterceptor.java
Log:
Break out the cutom security proxy integration into a seperate interceptor
Revision ChangesPath
1.16 +9 -109jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java
Index: SecurityInterceptor.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/SecurityInterceptor.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- SecurityInterceptor.java 2001/05/10 03:19:54 1.15
+++ SecurityInterceptor.java 2001/06/11 07:04:15 1.16
@@ -6,48 +6,30 @@
*/
package org.jboss.ejb.plugins;
-import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
-import java.lang.reflect.UndeclaredThrowableException;
import java.rmi.RemoteException;
-import java.security.AccessControlContext;
-import java.security.AccessController;
import java.security.Principal;
import java.util.Iterator;
import java.util.Set;
-import javax.ejb.EJBContext;
-import javax.ejb.EntityContext;
-import javax.ejb.SessionContext;
import javax.naming.InitialContext;
-import javax.security.auth.Subject;
import org.jboss.ejb.Container;
-import org.jboss.ejb.ContainerInvokerContainer;
import org.jboss.ejb.MethodInvocation;
-
import org.jboss.logging.Logger;
import org.jboss.security.EJBSecurityManager;
import org.jboss.security.RealmMapping;
import org.jboss.security.SecurityAssociation;
-import org.jboss.security.SecurityProxy;
-import org.jboss.security.SecurityProxyFactory;
-/** The SecurityInterceptor is where the EJB declarative security model
-is enforced. It is also the layer where user's can introduce custom
-security via the SecurityProxy delegation model.
+/** The SecurityInterceptor is where the EJB 2.0 declarative security model
+is enforced.
@author Oleg Nitz
@author [EMAIL PROTECTED]
-@version $Revision: 1.15 $
+@version $Revision: 1.16 $
*/
public class SecurityInterceptor extends AbstractInterceptor
{
-/** The JNDI name of the SecurityProxyFactory used to wrap security
-proxy objects that do not implement the SecurityProxy interface
- */
-public final String SECURITY_PROXY_FACTORY_NAME = "java:/SecurityProxyFactory";
-
/**
* @clientCardinality 0..1
* @supplierCardinality 1
@@ -68,13 +50,6 @@
*/
protected RealmMapping realmMapping;
-/**
- * @supplierCardinality 0..1
- * @clientCardinality 1
- * @supplierQualifier custom security
- */
-protected SecurityProxy securityProxy;
-
public SecurityInterceptor()
{
}
@@ -84,47 +59,6 @@
this.container = container;
securityManager = container.getSecurityManager();
realmMapping = container.getRealmMapping();
-Object secProxy = container.getSecurityProxy();
-if( secProxy != null )
-{
-/* If this is not a SecurityProxy instance then use the default
-SecurityProxy implementation
-*/
-if( (secProxy instanceof SecurityProxy) == false )
-{
-try
-{
-// Get default SecurityProxyFactory from JNDI at
-InitialContext iniCtx = new InitialContext();
-SecurityProxyFactory proxyFactory = (SecurityProxyFactory)
iniCtx.lookup(SECURITY_PROXY_FACTORY_NAME);
-securityProxy = proxyFactory.create(secProxy);
-}
-catch(Exception e)
-{
-System.out.println("Failed to initialze DefaultSecurityProxy");
-e.printStackTrace();
-}
-}
-else
-{
-securityProxy = (SecurityProxy) secProxy;
-}
-
-// Initialize the securityProxy
-try
-{
-ContainerInvokerContainer ic = (ContainerInvokerContainer)
container;
-Class beanHome = ic.getHomeClass();
-Class beanRemote = ic.getRemoteClass();
-securityProxy.init(beanHome, beanRemote, securityManager);
-}
-catch(Exception e)
-{
-System.out.println("Failed to initialze SecurityProxy");
-e.printStackTrace();
-}
-System.out.println("Initialized SecurityProxy="+securityProxy);
-}
}
public Container getContainer()
@@ -142,54 +76,20 @@
{
// Authenticate the subject and apply
Re: [JBoss-dev] JMSContainerInvoker.java
On 10 Jun, marc fleury wrote: > |I do like simplicity of management (that why I redo every JBoss > |distribution so I can configure it with a single property file - Ant, > |copy and filter). > > what do you mean, what do you redo? Short example: >From jboss.jcml: @rmi.port@ You see the @rmi.port@ In a propertyfile, for example default.properties ;-) rmi.port=1099 Some stuff in build.xml: This may be reset dynamicaly with -Dtemplates.properties to use other values for an installation. Turn on filtering while copying: Makes it a snapp to install differently configured JBoss servers, just write a new property file to make your installment from. I particulary like this in jbossmq.xml: bob @topics@ This is where I drive my destination configurations ;-) > > | > |# Here some code > | > |set_my_variable(11); > |print get_my_variable; > | > |What do you think one will get, yes 1. Do you get any warnings? NO. Is > |it hard to debug? Oh, yes. Verry hard. > | > |I think automatic creation of destinations for MDB suffers the same of > |problems. > > geez you guys are all banging on this feature... you know what? > > two peas in a bucket > > f*ck it! (as my father in law will say (deep south))... > > we will see if people complain Calm down ;-) > > |What happens when a created destination is suddenly destroyed when the > |MDB is undeployed (perhaps for a redeploy because of code change)? Well, > |all publisher to that destination will bark and be gone (if they was not > |coded to be failsafe). Suddenly we do not have a loosly coupled system > |any more, but the destination becomes just another remote interface > |against the bean (answer: use stateless sessions instead of MDB). > > uh tell me how is that related to the fact that we create it at > deployment time? if you remove a destination (period) then all clients will > be barking... if not then create a "durable topic" in the right JMS stuff... > we are not out to solve the world problems, if you want a durable topic > then you need to tell us. I still stick to my guns (and I could be wrong) > > |Ok,ok,ok. The only (I say only) acceptable thing a can think of is that > |it *might* be OK if the jboss.xml is completly missing. Then we might do > |somethink like automatic creation, *but only then*. > > ah... look at me in the eye... yes I do see that gleam in the corner of your > eye... you still see it don't you? yeah..ease of use for management, the > "dirty step child" of J2EE we are squarely competing at the low end with > very high end features for management... yeah you know it! yeah that > gleam... He, he. But see further down too. Should it really be in JMSContainerInvoker. One thing thats bothers me is that there are several indications on that JBossMQ is actually not that production ready. It behaves eratic during heavy load (messages are lost, and it is VERRY slow), there are some creapy buggs in the management of durable topic subscription, a server may dissapear without the clients ever getting to know it, and probably much more. Hiram has done a fantastic jobb, but he does not seem to have that much time any longer, and no one else has really showed up to take over or work with the hard parts beside him. I know there are some potential guys in there, that could probably solve this stuff. But until that has happened it is probably wise to have an implementation of MDB that is possible to use with another JMS provider. Or, Marc, try to inspire some of the wise guys on this list to take on JBossMQ. It would actually be good if there where more than one developer active with JBossMQ at a time. //Peter > > (drunk) > > marcf > | > |2. Is it a good think to implement it in JMSContainerInvoker? > | > |Well, maybe not. The container invoker is designed to be agnostic about > |the underlying JMS provider. All its ways to communicate with the JMS > |provider is done through indirection and interfaces. If this is placed > |in JMSContainerInvoker it should not be dependand on any special JBossMQ > |features, such as being able to create destinations on the fly through > |JMX. Or perhaps to be more correct, if this is done, is must be a part > |of the org.jboss.jms package that a JMX based destination creator is > |part of the JMSContainerInvoker contact. > | > |Was that clear, or am I just babling around? > | > |Chers > |Peter > | > | > |On 1 Jun, Hiram Chirino wrote: > |> My vote on the issue is turn the feature OFF by default. > |> > |> A JMS queue is like a database table: I don't want the thing getting > |> created and destroyed every time I deploy and undeploy a bean. This is > |> mainly doe to the time indepenent processing "feature" JMS usually gives > |> you. If you are creating and destroying a destination, the publisher > |> becomes time dependent on when the bean is deployed (does this > |make sense?). > |> > |> Regards, > |> Hiram > |> > |> > |> - Original Message
