[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 21 Successful tests: 15 Errors:6 Failures: 0 [time of test: 20 September 2001 7:19 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] VirtualHosts, security and deployers
Excellent. This is something that really needs to be done and the proposal is very good. We're beginning to get our heads around smartcards and the security domain fits very neatly into this, as we dynamically create keystores for SSL and embedded encryption for http. The only other thing that I can think of is running a security manager over all of this. Has anyone tried this yet? Scott M Stark wrote: > > I've been looking at how to include virtual hosts for wars, ejbs and rars > that need to bind their exported interfaces to specific addresses. Also > needed > is a notion of a security domain for the KeyStore if you need to use SSL/TLS > with > the exported transport. The security domain could also be used for > authentication > and authorization of users, principal mapping, single sign-on, etc. > > Right now there are serveral notions of deployers, not all of which are well > defined by an interface. There is a base DeployerMBean that is > implemented by the J2eeDeployer and RARDeployer, but it is not used by the > EJB deployer(ContainerFactory) or the WAR deployers(EmbeddedTomcat, > EmbeddedJetty). > Rather there is an assumption about the signature of deploy made by the > J2eeDeployer > for the JarDeployerName and WarDeployerName mbeans it uses. There is also no > unified notion of security at the deployer level. EJBs and WARs based > security off of > jboss.xml and jboss-web.xml descriptors. RARs have another notion of > security > at the ConnectionFactoryLoaderMBean level. > > I would like to come up with an application domain notion that combines all > deployers, > auto deploy directories, virtual host interface and security into a logic > collection of > resources and application components with a common interface address and > security > domain. Effectively all of the mbeans in an application domain become > contained > mbeans within the application domain. For example, > > name="Default:service=J2eeApplication"> > Default > localhost > java:/jaas/localhost > :service=ContainerFactory > :service=EmbeddedCatalina > :service=RARDeployer > >name=":service=ContainerFactory"> > true > false > false > true > false > >name=":service=EmbeddedCatalina" > > webapps > >name="JCA:service=RARDeployer" /> > > > name=":service=ConnectionManagerFactoryLoader,name=MinervaNoTransCMFactory"> > MinervaNoTransCMFactory > > org.jboss.pool.connector.jboss.MinervaNoTransCMFactory > > > > > name="JCA:service=ConnectionFactoryLoader,name=MinervaDS"> > MinervaDS > :service=RARDeployer > > Minerva JDBC LocalTransaction ResourceAdapter > > > ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:1476 > > > MinervaSharedLocalCMFactory > > > # Pool type - uncomment to force, otherwise it is the default > #PoolConfiguration=per-factory > # Connection pooling properties - see > # org.jboss.pool.PoolParameters > MinSize=0 > MaxSize=10 > Blocking=true > GCEnabled=false > IdleTimeoutEnabled=false > InvalidateOnError=false > TrackLastUsed=false > GCIntervalMillis=12 > GCMinIdleMillis=120 > IdleTimeoutMillis=180 > MaxIdleTimeoutPercent=1.0 > > > > > :service=J2eeApplication > name="URLs">../deploy/default,../deploy/default/lib > > > > All services within a J2eeApplication domain would inherit the > J2eeApplication domain > name as their JMX ObjectName domain component. All services would be > associated > with the security domain of the J2eeApplication domain. > > A similar domain notion would need to be added to the 3.0 RH services > configuration. > > An alternative is to simply add VirtualHost and SecurityDomain notions to > the > common ServiceMBean interface for example, and use naming conventions to > achieve the same effect. > > Another alternative is to have multiple instances of JBoss running, one for > each > domain with the configuration name defining the domain with a multi-domain > launcher. > > I'm looking for comments and suggestions on how to do this. > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf & tx timeout
Hi Jason, > >Anyways, I think there is still an issue with the tx recipts for an MDB. I >have to set the default tx timeout insainly high to avoid this problem. > >I remember there were a few suggestions on how to fix this, but I am not >sure what happend to them... > I just commited chanages to HEAD that should fix this for MDB with BMT. Pease test and let me know if it worked. Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/mdb/META-INF ejb-jar.xml jboss.xml
User: chirino Date: 01/09/19 22:22:19 Modified:src/resources/mdb/META-INF ejb-jar.xml jboss.xml Log: Added a test case for BMP MDBs. It is used to test that bean does not get Transaction Timeout errors. To exercise the test, make sure you set you Transaction Timeout value to something under 10 seconds. Revision ChangesPath 1.5 +27 -0 jbosstest/src/resources/mdb/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/mdb/META-INF/ejb-jar.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ejb-jar.xml 2001/02/28 09:41:06 1.4 +++ ejb-jar.xml 2001/09/20 05:22:19 1.5 @@ -23,6 +23,19 @@ + + BMPBean + org.jboss.test.mdb.bean.BMPBean + + Bean + AUTO_ACKNOWLEDGE + +javax.jms.Queue + NonDurable + + + + QueueBean org.jboss.test.mdb.bean.QueueBean + Required + + 1.7 +5 -0 jbosstest/src/resources/mdb/META-INF/jboss.xml Index: jboss.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/mdb/META-INF/jboss.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- jboss.xml 2001/02/28 09:41:06 1.6 +++ jboss.xml 2001/09/20 05:22:19 1.7 @@ -7,6 +7,11 @@ queue/testObjectMessage + BMPBean + Standard Message Driven Bean + queue/A + + QueueBean Standard Message Driven Bean queue/testQueue ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/mdb/bean BMPBean.java
User: chirino
Date: 01/09/19 22:22:19
Added: src/main/org/jboss/test/mdb/bean BMPBean.java
Log:
Added a test case for BMP MDBs. It is used to test that bean does not
get Transaction Timeout errors. To exercise the test, make sure you
set you Transaction Timeout value to something under 10 seconds.
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/mdb/bean/BMPBean.java
Index: BMPBean.java
===
/*
* Copyright (c) 2000 Peter Antman DN <[EMAIL PROTECTED]>
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
package org.jboss.test.mdb.bean;
import javax.ejb.MessageDrivenBean;
import javax.ejb.MessageDrivenContext;
import javax.ejb.EJBException;
import javax.jms.MessageListener;
import javax.jms.Message;
import javax.naming.InitialContext;
import javax.transaction.Status;
import javax.transaction.Transaction;
import javax.transaction.TransactionManager;
import javax.transaction.xa.XAResource;
/**
* MessageBeanImpl.java
*
*
* Created: Sat Nov 25 18:07:50 2000
*
* @author
* @version
*/
public class BMPBean implements MessageDrivenBean, MessageListener{
private MessageDrivenContext ctx = null;
public BMPBean() {
}
public void setMessageDrivenContext(MessageDrivenContext ctx)
throws EJBException {
this.ctx = ctx;
}
public void ejbCreate() {}
public void ejbRemove() {ctx=null;}
public void onMessage(Message message) {
System.err.println("DEBUG: BMPBean got message" + message.toString() );
try {
TransactionManager tm = (TransactionManager)new
InitialContext().lookup("java:/TransactionManager");
Transaction threadTx = tm.suspend();
System.out.println("DEBUG Tx="+threadTx);
System.out.println("Sleeping for 10 seconds");
try { Thread.currentThread().sleep(1000*10);
} catch ( InterruptedException e ) {}
System.out.println("Sleep done");
if( threadTx != null )
tm.resume(threadTx);
} catch (Exception e) {
System.out.println("BMPBean Error:"+e);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/mdb/test MDBUnitTestCase.java
User: chirino
Date: 01/09/19 22:22:19
Modified:src/main/org/jboss/test/mdb/test MDBUnitTestCase.java
Log:
Added a test case for BMP MDBs. It is used to test that bean does not
get Transaction Timeout errors. To exercise the test, make sure you
set you Transaction Timeout value to something under 10 seconds.
Revision ChangesPath
1.4 +11 -3 jbosstest/src/main/org/jboss/test/mdb/test/MDBUnitTestCase.java
Index: MDBUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/mdb/test/MDBUnitTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MDBUnitTestCase.java 2001/09/18 22:00:44 1.3
+++ MDBUnitTestCase.java 2001/09/20 05:22:19 1.4
@@ -51,7 +51,7 @@
* @author mailto:[EMAIL PROTECTED]";>Peter Antman
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
* @author mailto:[EMAIL PROTECTED]";>David Jencks
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class MDBUnitTestCase
extends JBossTestCase
@@ -90,7 +90,7 @@
}
protected void printHeader() {
- getLog().debug("\n Testing method " + getName() +
+ getLog().info("\n Testing method " + getName() +
" for destination " +dest);
}
@@ -135,7 +135,7 @@
sender.close();
}
-
+
/**
* Test sending messages to Queue testQueue
*/
@@ -178,6 +178,12 @@
session.close();
}
+
+ public void testWaitForCompleation() throws Exception {
+ try { Thread.currentThread().sleep(1000*20);
+ } catch ( InterruptedException e ) {}
+ }
+
/**
* Setup the test suite.
*/
@@ -189,6 +195,8 @@
suite.addTest(new MDBUnitTestCase("testTopic","topic/testTopic"));
suite.addTest(new MDBUnitTestCase("testTopic","topic/testDurableTopic"));
suite.addTest(new MDBUnitTestCase("testQueue","queue/ex"));
+ suite.addTest(new MDBUnitTestCase("testQueue","queue/A"));
+ suite.addTest(new MDBUnitTestCase("testWaitForCompleation",""));
return getJ2eeSetup(suite, "mdb.jar");
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java
User: chirino
Date: 01/09/19 22:13:14
Modified:src/main/org/jboss/mq SpySession.java
Log:
Allows the ASF stuff to access the XAResouceManager to control
transactions.
Revision ChangesPath
1.5 +9 -1 jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpySession.java 2001/09/20 03:54:41 1.4
+++ SpySession.java 2001/09/20 05:13:14 1.5
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -430,4 +430,12 @@
}
}
+
+ /**
+* This is used by the ASF SessionPool stuff
+*/
+ public SpyXAResourceManager getXAResourceManager() {
+ return connection.spyXAResourceManager;
+ }
+
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/asf ServerSessionPoolFactory.java StdServerSession.java StdServerSessionPool.java StdServerSessionPoolFactory.java
User: chirino
Date: 01/09/19 22:08:21
Modified:src/main/org/jboss/jms/asf ServerSessionPoolFactory.java
StdServerSession.java StdServerSessionPool.java
StdServerSessionPoolFactory.java
Log:
Transaction Timeout Fix: MDB that took a long time to process a message
would timeout the transaction. We now use the JBossMQ XAResource directly
to manage the transaction for BMT beans.
Revision ChangesPath
1.3 +19 -29jboss/src/main/org/jboss/jms/asf/ServerSessionPoolFactory.java
Index: ServerSessionPoolFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jms/asf/ServerSessionPoolFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServerSessionPoolFactory.java 2001/07/21 04:18:28 1.2
+++ ServerSessionPoolFactory.java 2001/09/20 05:08:21 1.3
@@ -1,67 +1,57 @@
/*
- * Copyright (c) 2000 Peter Antman Tim <[EMAIL PROTECTED]>
+ * JBoss, the OpenSource J2EE webOS
*
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package org.jboss.jms.asf;
import javax.jms.Connection;
+import javax.jms.JMSException;
import javax.jms.MessageListener;
import javax.jms.ServerSessionPool;
-import javax.jms.JMSException;
/**
- * Defines the model for creating ServerSessionPoolFactory objects.
+ * Defines the model for creating ServerSessionPoolFactory objects.
*
- * Created: Wed Nov 29 15:55:21 2000
+ * Created: Wed Nov 29 15:55:21 2000
*
- * @author mailto:[EMAIL PROTECTED]";>Peter Antman.
- * @version $Revision: 1.2 $
+ * @authormailto:[EMAIL PROTECTED]";>Peter Antman .
+ * @version $Revision: 1.3 $
*/
public interface ServerSessionPoolFactory
{
/**
* Set the name of the factory.
*
-* @param nameThe name of the factory.
+* @param name The name of the factory.
*/
void setName(String name);
/**
* Get the name of the factory.
*
-* @returnThe name of the factory.
+* @return The name of the factory.
*/
String getName();
/**
-* Create a new ServerSessionPool.
+* Create a new ServerSessionPool .
*
* @param con
* @param maxSession
* @param isTransacted
* @param ack
* @param listener
-* @returnA new pool.
-*
+* @param isContainerManaged Description of Parameter
+* @returnA new pool.
* @throws JMSException
*/
ServerSessionPool getServerSessionPool(Connection con,
- int maxSession,
- boolean isTransacted,
- int ack,
- MessageListener listener)
- throws JMSException;
+ int maxSession,
+ boolean isTransacted,
+ int ack,
+ boolean isContainerManaged,
+ MessageListener listener)
+ throws JMSException;
}
1.8 +307 -150 jboss/src/main/org/jboss/jms/asf/StdServerSession.java
Index: StdServerSession.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/asf/StdServerSession.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StdServerSession.java 2001/07/21 20:27:13 1.7
+++ StdServerSession.java 2001/09/20 05:08:21 1.8
@@ -1,21 +1,11 @@
/*
- * Copyright (c) 2000 Peter Antman Tim <[EMAIL PROTECTED]>
+ * JBoss, the OpenSource J2EE webOS
*
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY;
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Or just switch QueuedPessimisticEJBLock to MethodOnlyEJBLock. It may work, may not. I haven't thought through all the possibilities. Try it at your own risk. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Ferguson, Doug > Sent: Wednesday, September 19, 2001 9:55 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > Does this mean that if you leave all the interceptor then there > is no transactional locking on the bean? > > This is an easy way to get ReadOnly before it gets implemented.. > > d. > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 19, 2001 10:53 AM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > Todd, > > I cannot reproduce this problem. You're going to have to give me a test > case before I believe you. Also, do you use standardjboss.xml to create > your Entity Bean configuration? Or do you make your own. If you use > standardjboss.xml, please attach this to your next reply. > > PLEASE NOTE! > > There has been an extra interceptor added to the interceptor > chain in 2.4.1. > Please look in the distributed standardjboss.xml that comes with 2.4.1. > EntityLockInterceptor should be in the interceptor chain, and also a new > field should be set to QueuedPessmisticEJBLock. > > i.e. > > > Standard CMP > EntityBean > false > > org.jboss.ejb.plugins.jrmp.server.JRMPContainer > Invoker ontainer-invoker> > > > org.jboss.ejb.plugins.LogInterceptor > > org.jboss.ejb.plugins.SecurityInterceptor > > org.jboss.ejb.plugins.TxInterceptorCMT > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor > > org.jboss.ejb.plugins.EntityLockInterceptor > > org.jboss.ejb.plugins.EntityInstanceInterceptor > > org.jboss.ejb.plugins.EntitySynchronizationIntercepto > r ptor> > > > org.jboss.ejb.plugins.EntityInstancePool > > org.jboss.ejb.plugins.EntityInstanceCache > > org.jboss.ejb.plugins.jaws.JAWSPersistenceMan > ager istence-manager> > > org.jboss.tm.TxManager > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLoc > k -policy> > > > True > > > > org.jboss.ejb.plugins.LRUEnterpriseContextCachePolic > y olicy> > > 50 > 1000 > > 300 > 600 > 400 > > 60 > > 1 > > 0.75 > > > > 100 > 10 > > A > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > > Huss > > Sent: Tuesday, September 18, 2001 8:16 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > > locking code has changed. I have an entity bean with all methods having > > the transaction attribute set to "RequiresNew" and works great > under JBoss > > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > > condition errors in this particular entity bean. > > > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > > calls on the same bean where one of the calls should block > until the other > > one completes (and it does in 2.4.0). I was able to reproduce the race > > condition and then downgrade to 2.4.0 and everything worked great again > > with one of the method calls blocking as expected, then > upgrading back to > > 2.4.1 one more time showed the race condition again. > > > > Lastly, is there a bugzilla or something similar for JBoss where I can > > submit bug reports, or is this the best place to do it? > > > > Thanks, > > Todd > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq SpySession.java SpyMessageConsumer.java Connection.java
User: dmaplesden
Date: 01/09/19 20:54:42
Modified:src/main/org/jboss/mq SpySession.java
SpyMessageConsumer.java Connection.java
Log:
fixed npe when a receive occurs after a subscription is closed. Also tidied up
closing down of sessions with receivers with message listeners.
Revision ChangesPath
1.4 +38 -36jbossmq/src/main/org/jboss/mq/SpySession.java
Index: SpySession.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpySession.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpySession.java 2001/08/17 03:04:01 1.3
+++ SpySession.java 2001/09/20 03:54:41 1.4
@@ -33,7 +33,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public abstract class SpySession
implements Session, XASession {
@@ -225,38 +225,40 @@
throws JMSException {
// allow other threads to process before closing this session
// Patch submitted by John Ellis (10/29/00)
- Thread.yield();
+// Thread.yield();
+ cat.debug("Session closing.");
- //deal with any unacked messages
- if ( !closed && transacted && spyXAResource == null ) {
- rollback();
- }
-
synchronized ( runLock ) {
+
if ( closed ) {
return;
}
- closed = true;
- }
-
- Iterator i;
- synchronized ( consumers ) {
- //notify the sleeping synchronous listeners
- if ( sessionConsumer != null ) {
-sessionConsumer.close();
+ Iterator i;
+ synchronized ( consumers ) {
+
+//notify the sleeping synchronous listeners
+if ( sessionConsumer != null ) {
+ sessionConsumer.close();
+}
+
+i = consumers.iterator();
}
-
- i = consumers.iterator();
- }
+
+ while ( i.hasNext() ) {
+SpyMessageConsumer messageConsumer = ( SpyMessageConsumer )i.next();
+messageConsumer.close();
+ }
+
+ //deal with any unacked messages
+ if ( transacted && spyXAResource == null ) {
+rollback();
+ }
+
+ connection.sessionClosing( this );
- while ( i.hasNext() ) {
- SpyMessageConsumer messageConsumer = ( SpyMessageConsumer )i.next();
- messageConsumer.close();
+ closed = true;
}
-
- connection.sessionClosing( this );
-
}
@@ -298,21 +300,21 @@
//Rollback a transacted session
public synchronized void rollback()
throws JMSException {
- if ( spyXAResource != null ) {
- throw new javax.jms.TransactionInProgressException( "Should not be call
from a XASession" );
- }
- if ( closed ) {
- throw new IllegalStateException( "The session is closed" );
- }
- if ( !transacted ) {
- throw new IllegalStateException( "The session is not transacted" );
- }
- cat.debug( "Session: rollback()" );
-
- // Stop message delivery
synchronized ( runLock ) {
+ if ( spyXAResource != null ) {
+throw new javax.jms.TransactionInProgressException( "Should not be call
from a XASession" );
+ }
+ if ( closed ) {
+throw new IllegalStateException( "The session is closed" );
+ }
+ if ( !transacted ) {
+throw new IllegalStateException( "The session is not transacted" );
+ }
+
+ cat.debug( "Session: rollback()" );
+
// rollback transaction
try {
connection.spyXAResourceManager.endTx( currentTransactionId, true );
1.8 +14 -2 jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java
Index: SpyMessageConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessageConsumer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SpyMessageConsumer.java 2001/08/21 23:16:17 1.7
+++ SpyMessageConsumer.java 2001/09/20 03:54:41 1.8
@@ -23,7 +23,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class SpyMessageConsumer
implements MessageConsumer, SpyConsumer, Runnable
@@ -264,6 +264,8 @@
public void close()
throws JMSException {
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
OK, took longer than I thought. There was a fundamental bug that was causing your freeze, but it was in code that only gets executed if something else is going wrong... So fixing the bug was simple, fixing every else just because it needed it took longer. Anyway I won't bore you with the details, it should work much better now (it works for me), let me know if it still doesn't. BTW: does Jetty hang on shutdown for anyone else? Happens every time for me. David. > -Original Message- > From: David Maplesden [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 20, 2001 12:57 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > For me the perf test freezes after one or two of these > > messages, which I > > always get. Doesn't matter which persistence manager I use. > > > > I'm attaching the server and client (test) logs. Any ideas? > > > > Strange... I'll have a look. > > > > > btw, in the jbossmq unit test, would you mind using the > > getInitialContext() > > from JBossTestCase rather than new InitialContext()? I was > > hoping to get > > all the getting of initial contexts in one place in case we > > wanted to use > > properties passed from the build file to determine where we look. > > > > Sure thing, I didn't change this on purpose, it never existed in the > original file which I edited and then it got lost when I > merged my new tests > with the new format. > > > > > Thanks > > david jencks > > > > > > On 2001.09.19 18:53:25 -0400 David Maplesden wrote: > > > Ok I have had a look at the mq tests and they run fine for > > me, I didn't > > > have > > > any trouble. > > > > > > The only thing I changed was to use the rollinglogged > > persistence manager > > > instead of the file persistence manager for JBossMQ. > This shouldn't > > > change > > > anything except the performance (rolling logged is many > > times faster), I > > > only did it so the tests would finish in a reasonable time, > > as it was the > > > JBossMQPerfStressTestCase took nearly 5 minutes to > finish. I would > > > imagine > > > that with file persistence and running 1000 iterations the > > total time > > > could > > > take something like an 30 minutes to an hour (this is only a rough > > > estimate > > > based on my previous experience). > > > > > > During the test several errors are thrown out by the > > engine, looking at > > > the > > > code these errors are all created by the test code closing > > the session > > > the > > > message listener is registered with too soon. In other > words these > > > errors > > > are difficult to avoid but harmless. > > > > > > The errors in particular I am talking about are > > > > > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > > > listening > > > thread. > > > javax.jms.JMSException: Invalid transaction id. > > > at > > > > > org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceMana > > ger.java:62) > > > at > > org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) > > > at java.lang.Thread.run(Thread.java:484) > > > > > > or > > > > > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > > > listening > > > thread. > > > org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver > > > at org.jboss.mq.Connection.receive(Connection.java:595) > > > at > > org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) > > > at java.lang.Thread.run(Thread.java:484) > > > linked exception is: > > > javax.jms.JMSException: The provided subscription does not exist > > > <> > > > > > > These should happen at most once per run, and sometimes you > > get neither, > > > if > > > the timing of the threads closing down happens in the right order. > > > > > > Other than that everything seems fine to me. If you > > continue to have > > > trouble let me know. > > > > > > Cheers > > > David > > > > > > > -Original Message- > > > > From: David Maplesden [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, September 20, 2001 8:21 AM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > > > > > > > I'll have a look, I've been through the MQ test stuff before > > > > and it did all > > > > work originally. I haven't looked at it since all the > > > > changes to the build > > > > system and new test stuff so its not too surprising if its > > > > having trouble. > > > > > > > > I'll let you know how I get on. > > > > > > > > David > > > > > > > > > -Original Message- > > > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > > > Sent: Thursday, September 20, 2001 7:35 AM > > > > > To: jboss-dev > > > > > Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > > > > > > > > > > Hi, > > > > > > > > > > It appears that most of the jbossmq tests are not working > > > > > currently with > > > > > rh. Much of this appear
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientILService.java
User: dmaplesden
Date: 01/09/19 20:55:11
Modified:src/main/org/jboss/mq/il/oil OILClientILService.java
Log:
Improved error message when client side error received
Revision ChangesPath
1.3 +2 -2 jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java
Index: OILClientILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientILService.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- OILClientILService.java 2001/08/17 03:04:04 1.2
+++ OILClientILService.java 2001/09/20 03:55:11 1.3
@@ -30,7 +30,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2 $
+ * @version$Revision: 1.3 $
*/
public class OILClientILService implements Runnable,
org.jboss.mq.il.ClientILService {
//the client IL
@@ -183,7 +183,7 @@
}
try {
- cat.error( e );
+ cat.error( "Exception handling server request", e );
out.writeByte( 1 );
out.writeObject( e );
out.reset();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server JMSTopic.java ClientConsumer.java
User: dmaplesden
Date: 01/09/19 20:52:57
Modified:src/main/org/jboss/mq/server JMSTopic.java
ClientConsumer.java
Log:
fixed bug for message acknowledgement after receiver closed for topics
Revision ChangesPath
1.5 +9 -2 jbossmq/src/main/org/jboss/mq/server/JMSTopic.java
Index: JMSTopic.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/JMSTopic.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JMSTopic.java 2001/08/17 03:04:06 1.4
+++ JMSTopic.java 2001/09/20 03:52:57 1.5
@@ -26,7 +26,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class JMSTopic extends JMSDestination {
@@ -86,7 +86,7 @@
DurableSubcriptionID id = topic.getDurableSubscriptionID();
if ( id == null ) {
synchronized ( tempQueues ) {
-queue = ( BasicQueue )tempQueues.remove( sub );
+queue = ( BasicQueue )tempQueues.get( sub );
}
} else {
synchronized ( durQueues ) {
@@ -97,6 +97,13 @@
queue.removeSubscriber( sub );
}
+ void cleanupSubscription(Subscription sub){
+ //just try to remove from tempQueues, don't worry if its not there
+ synchronized ( tempQueues ) {
+ tempQueues.remove( sub );
+ }
+ }
+
public void addReceiver( Subscription sub ) {
getQueue( sub ).addReceiver( sub );
}
1.6 +8 -2 jbossmq/src/main/org/jboss/mq/server/ClientConsumer.java
Index: ClientConsumer.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/ClientConsumer.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ClientConsumer.java 2001/08/29 22:45:58 1.5
+++ ClientConsumer.java 2001/09/20 03:52:57 1.6
@@ -25,7 +25,7 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class ClientConsumer implements Runnable {
//The JMSServer object
@@ -256,8 +256,14 @@
}
void removeRemovedSubscription( int subId ) {
+ Subscription sub = null;
synchronized ( subscriptions ) {
- removedSubscriptions.remove( new Integer( subId ) );
+ sub = (Subscription) removedSubscriptions.remove( new Integer( subId ) );
+ }
+ if(sub != null){
+ JMSDestination topic = server.getJMSDestination( sub.destination );
+ if(topic instanceof JMSTopic)
+((JMSTopic) topic).cleanupSubscription(sub);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Does this mean that if you leave all the interceptor then there is no transactional locking on the bean? This is an easy way to get ReadOnly before it gets implemented.. d. -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 19, 2001 10:53 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 Todd, I cannot reproduce this problem. You're going to have to give me a test case before I believe you. Also, do you use standardjboss.xml to create your Entity Bean configuration? Or do you make your own. If you use standardjboss.xml, please attach this to your next reply. PLEASE NOTE! There has been an extra interceptor added to the interceptor chain in 2.4.1. Please look in the distributed standardjboss.xml that comes with 2.4.1. EntityLockInterceptor should be in the interceptor chain, and also a new field should be set to QueuedPessmisticEJBLock. i.e. Standard CMP EntityBean false org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker org.jboss.ejb.plugins.LogInterceptor org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor org.jboss.ejb.plugins.EntityInstancePool org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock True org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy 50 1000 300 600 400 60 1 0.75 100 10 A > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > Huss > Sent: Tuesday, September 18, 2001 8:16 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > locking code has changed. I have an entity bean with all methods having > the transaction attribute set to "RequiresNew" and works great under JBoss > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > condition errors in this particular entity bean. > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > calls on the same bean where one of the calls should block until the other > one completes (and it does in 2.4.0). I was able to reproduce the race > condition and then downgrade to 2.4.0 and everything worked great again > with one of the method calls blocking as expected, then upgrading back to > 2.4.1 one more time showed the race condition again. > > Lastly, is there a bugzilla or something similar for JBoss where I can > submit bug reports, or is this the best place to do it? > > Thanks, > Todd > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] VirtualHosts, security and deployers
- Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 5:55 PM Subject: Re: [JBoss-dev] VirtualHosts, security and deployers > > A security domain is really a passive property that is available to the > > services > > within the domain. The only point at which a security domain and virtual > > host > > have a relationship is if the domain was using SSL/TLS and needed a > > server > > certificate that used the virtual host DNS name in order for SSL clients > > to > > see a valid certificate. Other than that the virtual host and security > > domain are > > really independent. > > So you are saying each virtual host can have or use many security domains > and each security domain can be used by many virtual hosts? Whereas a > particular application has to have one virtual host and one security > domain? A virtual host would only have one security domain and a security domain may be used by multiple virtual hosts. It makes sense to allow individual services and components within a virtual host to override the security domain. It also makes sense to allow security domains to form domains of trust to allow for single sign-on or transparent principal/credential mapping between security domains. > > > Certainly an rar needs some security support, but what interface would > > one > > > export that is bound to an address? > > > > > I can think of many. JDBC connections when we start offering client > > containers, JMS > > connections, etc. Basically any managed connection may need to be made > > available > > only on the virtual host interface. > > hmm... I was kind of thinking a client container could be a mini-jboss with > a client deployer and its own ConnectionFactoryLoaders...and very little > else. > A client container is just one example. In three tier deployments of the server it is very likely that I would only want to allow access to resources between the tier2-tier3 interface(tier2 JDBC pool for a tier3 DB. The users and credentials for accessing the databas are likely to be unrelated to the tier1 clients.). In short, if a resource is creating a network object that may need to be secured it needs to externalize the address on which it binds the network object and it needs to externalize any authentication, authorization policies as well. > > The SecurityDomain configuration would show up in a mbean along with > > the corresponding JAAS login configuration info. I removed the security > > related config from the ConnectionFactories as this would be delegated to > > the SecurityDomain object. > > So you are proposing (in psued0 mbean-xml) > > ... > >... > > > > > >... > > > > > > rather than > > > ... > >... > > > >... > > > > > ... > > > > The second avoids mapping several principal mappings to one connection > factory. Offhand, I can't think of a way it would make sense to have more > than one principal mapping/connection factory, can you? > > Yes, but the actual mapping is not configured in the mbean descriptor. It is a by-product of the JAAS login modules associated with the security domain. The same for user to password or credential mapping. None of this info should be in the JBoss configuration files. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/perf JBossMQPerfStressTestCase.java
User: dmaplesden
Date: 01/09/19 18:06:30
Modified:src/main/org/jboss/test/jbossmq/perf
JBossMQPerfStressTestCase.java
Log:
change new InitialContext to getInitialContext
Revision ChangesPath
1.3 +1 -1
jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java
Index: JBossMQPerfStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossMQPerfStressTestCase.java2001/09/19 19:16:54 1.2
+++ JBossMQPerfStressTestCase.java2001/09/20 01:06:30 1.3
@@ -667,7 +667,7 @@
if (context == null)
{
- context = new InitialContext();
+ context = getInitialContext();
QueueConnectionFactory queueFactory =
(QueueConnectionFactory)context.lookup(QUEUE_FACTORY);
queueConnection = queueFactory.createQueueConnection();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
> > For me the perf test freezes after one or two of these > messages, which I > always get. Doesn't matter which persistence manager I use. > > I'm attaching the server and client (test) logs. Any ideas? > Strange... I'll have a look. > > btw, in the jbossmq unit test, would you mind using the > getInitialContext() > from JBossTestCase rather than new InitialContext()? I was > hoping to get > all the getting of initial contexts in one place in case we > wanted to use > properties passed from the build file to determine where we look. > Sure thing, I didn't change this on purpose, it never existed in the original file which I edited and then it got lost when I merged my new tests with the new format. > > Thanks > david jencks > > > On 2001.09.19 18:53:25 -0400 David Maplesden wrote: > > Ok I have had a look at the mq tests and they run fine for > me, I didn't > > have > > any trouble. > > > > The only thing I changed was to use the rollinglogged > persistence manager > > instead of the file persistence manager for JBossMQ. This shouldn't > > change > > anything except the performance (rolling logged is many > times faster), I > > only did it so the tests would finish in a reasonable time, > as it was the > > JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would > > imagine > > that with file persistence and running 1000 iterations the > total time > > could > > take something like an 30 minutes to an hour (this is only a rough > > estimate > > based on my previous experience). > > > > During the test several errors are thrown out by the > engine, looking at > > the > > code these errors are all created by the test code closing > the session > > the > > message listener is registered with too soon. In other words these > > errors > > are difficult to avoid but harmless. > > > > The errors in particular I am talking about are > > > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > > listening > > thread. > > javax.jms.JMSException: Invalid transaction id. > > at > > > org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceMana > ger.java:62) > > at > org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) > > at java.lang.Thread.run(Thread.java:484) > > > > or > > > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > > listening > > thread. > > org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver > > at org.jboss.mq.Connection.receive(Connection.java:595) > > at > org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) > > at java.lang.Thread.run(Thread.java:484) > > linked exception is: > > javax.jms.JMSException: The provided subscription does not exist > > <> > > > > These should happen at most once per run, and sometimes you > get neither, > > if > > the timing of the threads closing down happens in the right order. > > > > Other than that everything seems fine to me. If you > continue to have > > trouble let me know. > > > > Cheers > > David > > > > > -Original Message- > > > From: David Maplesden [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, September 20, 2001 8:21 AM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > > > > I'll have a look, I've been through the MQ test stuff before > > > and it did all > > > work originally. I haven't looked at it since all the > > > changes to the build > > > system and new test stuff so its not too surprising if its > > > having trouble. > > > > > > I'll let you know how I get on. > > > > > > David > > > > > > > -Original Message- > > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, September 20, 2001 7:35 AM > > > > To: jboss-dev > > > > Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > > > > > > > Hi, > > > > > > > > It appears that most of the jbossmq tests are not working > > > > currently with > > > > rh. Much of this appears to me to be configuration > problems. On my > > > > machine, running JBossMQPerfStressTestCase usually freezes > > > > something so > > > > that subsequent tests don't run and jboss will not shut > > > down: for this > > > > reason I commented it out of the testsuite/build.xml. > > > > > > > > Could the jbossmq experts take a look? > > > > > > > > You may find the ability to set counts via a local.properties > > > > file useful: > > > > > > > > ### Test properties > > > > > > > > junit.timeout=12 > > > > jbosstest.threadcount=2 > > > > jbosstest.iterationcount=2 > > > > jbosstest.beancount=2 > > > > > > > > > > > > You may find the one-test target useful: > > > > > > > > ./build.sh -DJBossMQPerfStressTestCase one-test > > > > > > > > runs only the named test. > > > > > > > > Thanks > > > > david jencks > > > > > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROT
Re: [JBoss-dev] VirtualHosts, security and deployers
On 2001.09.19 19:43:34 -0400 Scott M Stark wrote: > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 19, 2001 3:50 PM > Subject: Re: [JBoss-dev] VirtualHosts, security and deployers > > > > Hi, > > This is great! > > > > I have some questions... > > > > As I understand it a virtual host is an ip address (+ port?) > Just an IP address and maybe a name. The name may not resolve > to the IP address if the interface on which a service is bound is > behind a NAT firewall. The services associated with the virtual host > will have ports. > > > A security domain is an authentication/authorization mechanism > (instance), > > and something is within a security domain if it uses that instance for > its > > authentication/authorization. > > > Correct. It is a logical grouping of users, roles, a KeyStore(certs, > private > keys, > secret keys), permissions, etc. > > > In your scheme are the virtual hosts and security domains coextensive? > (do > > they partition the set of components identically)? > > Do the security domains form a sub-partition of the virtual hosts? vice > > versa? are they independent? > > > A security domain is really a passive property that is available to the > services > within the domain. The only point at which a security domain and virtual > host > have a relationship is if the domain was using SSL/TLS and needed a > server > certificate that used the virtual host DNS name in order for SSL clients > to > see a valid certificate. Other than that the virtual host and security > domain are > really independent. So you are saying each virtual host can have or use many security domains and each security domain can be used by many virtual hosts? Whereas a particular application has to have one virtual host and one security domain? > > > And for me the biggest question - how does this relate to classloaders? > > > > So... if virtual host = security domain, do we also have a classloader > > (ServiceLibrary/Scope type thing) for it? Is this the same as the > > application classloader or is it the parent classloader of the > application > > classloader? > > > I can see it going that way if you want the services in a domain to be > isolated > from other domains. Users trying to use JBoss for ISP hosting definitely > would > like that property. In that case the Application MBean would have a class > loader > that simply isolated the application resources from other domains. Java2 > permissions > can also be associated with the domain level class loader. > > > > > More comments interspersed. > > > > On 2001.09.19 16:50:56 -0400 Scott M Stark wrote: > > > I've been looking at how to include virtual hosts for wars, ejbs and > rars > > > that need to bind their exported interfaces to specific addresses. > Also > > > needed > > > is a notion of a security domain for the KeyStore if you need to use > > > SSL/TLS > > > with > > > the exported transport. The security domain could also be used for > > > authentication > > > and authorization of users, principal mapping, single sign-on, etc. > > Certainly an rar needs some security support, but what interface would > one > > export that is bound to an address? > > > I can think of many. JDBC connections when we start offering client > containers, JMS > connections, etc. Basically any managed connection may need to be made > available > only on the virtual host interface. hmm... I was kind of thinking a client container could be a mini-jboss with a client deployer and its own ConnectionFactoryLoaders...and very little else. > > > > All services within a J2eeApplication domain would inherit the > > > J2eeApplication domain > > > name as their JMX ObjectName domain component. All services would be > > > associated > > > with the security domain of the J2eeApplication domain. > > > > OK, but haven't you left out the configuration of the security domain? > For > > instance, the ConnectionFactoryLoader security stuff seems to have > > disappeared. I don't see right off how you could easily separate > principal > > mappings from their ConnectionFactories-- it seems to me that one > > application might use 5 ConnectionFactories each with an incompatible > > PrincipalMapping. > > > The SecurityDomain configuration would show up in a mbean along with > the corresponding JAAS login configuration info. I removed the security > related config from the ConnectionFactories as this would be delegated to > the SecurityDomain object. So you are proposing (in psued0 mbean-xml) ... ... ... rather than ... ... ... ... The second avoids mapping several principal mappings to one connection factory. Offhand, I can't think of a way it would make sense to have more than one principal mapping/connection factory, can you? > > > > > > > A similar domain notion would need to be added to t
[JBoss-dev] Re: MethodOnlyLock in 2.4.1?
Should *ALL* entity beans use the MethodOnlyEJBLock policy, or just the read-only entity beans? I was under the impression that only the read-only entity beans should use this policy, but your comment about standardjboss.xml below leads me to believe otherwise. ++jeff On Wednesday 19 September 2001 07:37 am, Bill Burke wrote: > MethodOnlyLock is there, but the read-only special case has not been put in > yet. > > But, > > You can use the entity instance per transaction interceptors I wrote. > Unfortunately there is a stupid bug in them in the 2.4.1 release, but you > can get latest from the CVS Branch_2_4 to get my fixes. > > With "entity instance per transaction", entities are not locked into a > transaction, but instead an instance per entity bean is created per > transaction. To use this do the following: > > 1. Either change standardjboss.xml or create your own configuration as > follows. > 2. Edit the Standard CMP EntityBean (and/or BMP) > 3. Search for and switch it from QueuedPessimisticEJBLock > to MethodOnlyLock. > 4. Change EntityInstanceInterceptor to EntityMultiInstanceInterceptor > 5. Change EntitySynchronizationInterceptor to > EntityMultiInstanceSynchronizationInterceptor > 6. Change to B or C. > > Regards, > > BIll > > > -Original Message- > > From: Jeffrey Wescott [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, September 18, 2001 6:21 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: MethodOnlyLock in 2.4.1? > > > > > > Did MethodOnlyLock for read-only entity beans make it into 2.4.1? > > If so, is > > there any documentation on how to use it anywhere? > > > > ++jeff ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
For me the perf test freezes after one or two of these messages, which I always get. Doesn't matter which persistence manager I use. I'm attaching the server and client (test) logs. Any ideas? btw, in the jbossmq unit test, would you mind using the getInitialContext() from JBossTestCase rather than new InitialContext()? I was hoping to get all the getting of initial contexts in one place in case we wanted to use properties passed from the build file to determine where we look. Thanks david jencks On 2001.09.19 18:53:25 -0400 David Maplesden wrote: > Ok I have had a look at the mq tests and they run fine for me, I didn't > have > any trouble. > > The only thing I changed was to use the rollinglogged persistence manager > instead of the file persistence manager for JBossMQ. This shouldn't > change > anything except the performance (rolling logged is many times faster), I > only did it so the tests would finish in a reasonable time, as it was the > JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would > imagine > that with file persistence and running 1000 iterations the total time > could > take something like an 30 minutes to an hour (this is only a rough > estimate > based on my previous experience). > > During the test several errors are thrown out by the engine, looking at > the > code these errors are all created by the test code closing the session > the > message listener is registered with too soon. In other words these > errors > are difficult to avoid but harmless. > > The errors in particular I am talking about are > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > listening > thread. > javax.jms.JMSException: Invalid transaction id. > at > org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceManager.java:62) > at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) > at java.lang.Thread.run(Thread.java:484) > > or > > [SpyMessageConsumer,WARN] Message consumer closing due to error in > listening > thread. > org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver > at org.jboss.mq.Connection.receive(Connection.java:595) > at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) > at java.lang.Thread.run(Thread.java:484) > linked exception is: > javax.jms.JMSException: The provided subscription does not exist > <> > > These should happen at most once per run, and sometimes you get neither, > if > the timing of the threads closing down happens in the right order. > > Other than that everything seems fine to me. If you continue to have > trouble let me know. > > Cheers > David > > > -Original Message- > > From: David Maplesden [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 20, 2001 8:21 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > I'll have a look, I've been through the MQ test stuff before > > and it did all > > work originally. I haven't looked at it since all the > > changes to the build > > system and new test stuff so its not too surprising if its > > having trouble. > > > > I'll let you know how I get on. > > > > David > > > > > -Original Message- > > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, September 20, 2001 7:35 AM > > > To: jboss-dev > > > Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > > > > Hi, > > > > > > It appears that most of the jbossmq tests are not working > > > currently with > > > rh. Much of this appears to me to be configuration problems. On my > > > machine, running JBossMQPerfStressTestCase usually freezes > > > something so > > > that subsequent tests don't run and jboss will not shut > > down: for this > > > reason I commented it out of the testsuite/build.xml. > > > > > > Could the jbossmq experts take a look? > > > > > > You may find the ability to set counts via a local.properties > > > file useful: > > > > > > ### Test properties > > > > > > junit.timeout=12 > > > jbosstest.threadcount=2 > > > jbosstest.iterationcount=2 > > > jbosstest.beancount=2 > > > > > > > > > You may find the one-test target useful: > > > > > > ./build.sh -DJBossMQPerfStressTestCase one-test > > > > > > runs only the named test. > > > > > > Thanks > > > david jencks > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > freezelog.log
[JBoss-dev] ejb-jar whitespace
hello... I can't seem to find much info on this... This is valid in ejb-jar.xml for JBoss AND Weblogic Stateless these are only valid for Weblogic... it appears to be just the new lines and whitespace messing it up... Stateless Stateless they give this error... [Container factory] Deploying:file:/C:/dev/JBoss-2.4.1/tmp/deploy/Default/interest.jar/ [Container factory] org.jboss.ejb.DeploymentException: Error in ejb-jar.xml for Session Bean Interest: session type should be 'Stateful' or 'Stateless' [Container factory] at org.jboss.metadata.ApplicationMetaData.importEjbJarXml(ApplicationMetaData.j ava:140) [Container factory] at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:140) [Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:438) [Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:369) [Container factory] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:304) I tried switching parsers to xerces... no difference... I was under the impression that white space wouldn't mater in the ejb-jar.xml... Is this how the parsing is supposed to behave? thanks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/jndi HANamingService.java HAJNDI.java
User: patriot1burke
Date: 01/09/19 16:57:59
Modified:src/main/org/jboss/ha/jndi HANamingService.java HAJNDI.java
Log:
HAJNDI sort of works now. Framework definately works now.
Revision ChangesPath
1.3 +24 -19jbossmx/src/main/org/jboss/ha/jndi/HANamingService.java
Index: HANamingService.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/jndi/HANamingService.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HANamingService.java 2001/09/18 21:21:08 1.2
+++ HANamingService.java 2001/09/19 23:57:59 1.3
@@ -58,7 +58,7 @@
@author oberg
@author [EMAIL PROTECTED]
- @version $Revision: 1.2 $
+ @version $Revision: 1.3 $
*/
public class HANamingService extends ServiceMBeanSupport implements Runnable,
HANamingServiceMBean, DistributedReplicantManager.ReplicantListener
{
@@ -107,7 +107,7 @@
public String getName()
{
- return "HA-JNDI";
+ return "HAJNDI";
}
public ObjectName getObjectName(MBeanServer server, ObjectName name)
@@ -195,8 +195,10 @@
public void replicantsChanged(String key, ArrayList newReplicants)
{
- if (key.equals("HA-JNDI"))
+ log.info("replicantsChanged");
+ if (key.equals("HAJNDI"))
{
+ log.info("HAJNDI replicantChanged");
synchronized(this.hatarget)
{
hatarget.setTargets(newReplicants.toArray());
@@ -204,6 +206,7 @@
}
else if (key.equals("DistributedReplicantManager"))
{
+ log.info("DistributedReplicantManager replicantChanged");
synchronized(this.hatarget)
{
hatarget.setManagers(newReplicants);
@@ -213,37 +216,39 @@
public void initService() throws Exception
{
- }
-
- public void startService()
- throws Exception
- {
- log.info("Starting HA-JNDI server");
+ log.info("Initializing HAJNDI server");
partition = (HAPartition)new InitialContext().lookup("/HAPartition/" +
partitionName);
replicantManager = partition.getDistributedReplicantManager();
log.info("Create remote object");
theServer = new HAJNDI(partition);
- ((HAJNDI)theServer).init();
-
log.info("Export RMI server");
stub = UnicastRemoteObject.exportObject(theServer);
+ log.info("initialize HAJNDI");
+ theServer.init();
+ }
+
+ public void startService()
+ throws Exception
+ {
+ log.info("Starting HAJNDI server");
log.info("Bind replicant to DistributedReplicantManager");
- replicantManager.add("HA-JNDI", stub);
+ replicantManager.add("HAJNDI", stub);
- log.info("Get all replicants for DistributedReplicantManager and HA-JNDI");
+ log.info("Get all replicants for DistributedReplicantManager and HAJNDI");
ArrayList managers =
this.replicantManager.lookupReplicants("DistributedReplicantManager");
- ArrayList replicants = this.replicantManager.lookupReplicants("HA-JNDI");
+ ArrayList replicants = this.replicantManager.lookupReplicants("HAJNDI");
- log.info("Create HA-JNDI RMI Proxy with " + replicants.size() + "
replicants");
- this.hatarget = new HARMITarget("HA-JNDI", 10, 50, managers,
replicants.toArray(), new RoundRobin());
+ log.info("Create HAJNDI RMI Proxy with " + replicants.size() + " replicants");
+ this.hatarget = new HARMITarget("HAJNDI", 10, 50, managers,
replicants.toArray(), new RoundRobin());
this.hastub = (Naming)Proxy.newProxyInstance(
Naming.class.getClassLoader(),
new Class[] { Naming.class },
this.hatarget);
- log.info("Register with replicantManager as listener for HA-JNDI replicants");
- replicantManager.registerListener("HA-JNDI", this);
+ log.info("Register with replicantManager as listener for HAJNDI replicants");
+ replicantManager.registerListener("HAJNDI", this);
+ replicantManager.registerListener("DistributedReplicantManager", this);
log.info("Start listener");
try
@@ -340,7 +345,7 @@
protected void listen()
{
- Thread t = new Thread(this, "HA-JNDI Server");
+ Thread t = new Thread(this, "HAJNDI Server");
t.start();
}
1.3 +51 -11jbossmx/src/main/org/jboss/ha/jndi/HAJNDI.java
Index: HAJNDI.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/jndi/HAJNDI.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HAJNDI.java 2001/09/18 13:59:28 1.2
+++ HAJNDI.java 2001/09/19 23:57:59 1.3
@
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha HARMITarget.java HAPartitionImpl.java DistributedReplicantManagerImpl.java ClusterPartition.java
User: patriot1burke
Date: 01/09/19 16:57:43
Modified:src/main/org/jboss/ha HARMITarget.java HAPartitionImpl.java
DistributedReplicantManagerImpl.java
ClusterPartition.java
Log:
HAJNDI sort of works now. Framework definately works now.
Revision ChangesPath
1.2 +6 -0 jbossmx/src/main/org/jboss/ha/HARMITarget.java
Index: HARMITarget.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/HARMITarget.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- HARMITarget.java 2001/09/14 03:53:29 1.1
+++ HARMITarget.java 2001/09/19 23:57:43 1.2
@@ -22,7 +22,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
* @author mailto:[EMAIL PROTECTED]";>Bill Burke
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -90,6 +90,7 @@
public Object getRemoteTarget()
{
+ System.out.println("number of targets: " + targets.length);
if (targets.length == 0)
{
findTargetsSynchronously ();
@@ -222,6 +223,11 @@
|| targetException instanceof UnknownHostException)
{
// ignore
+ System.out.println("Connection failure");
+}
+else if (targetException instanceof RemoteException)
+{
+ System.out.println("RemoteException called: " +
targetException.getClass().getName());
}
else
{
1.6 +35 -11jbossmx/src/main/org/jboss/ha/HAPartitionImpl.java
Index: HAPartitionImpl.java
===
RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/HAPartitionImpl.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- HAPartitionImpl.java 2001/09/18 21:56:49 1.5
+++ HAPartitionImpl.java 2001/09/19 23:57:43 1.6
@@ -18,6 +18,7 @@
import JavaGroups.MethodCall;
import JavaGroups.RpcDispatcher;
import JavaGroups.RspList;
+import JavaGroups.Rsp;
import JavaGroups.GroupRequest;
import JavaGroups.View;
import JavaGroups.Address;
@@ -46,7 +47,7 @@
protected ArrayList listeners = new ArrayList();
protected String partitionName;
protected Vector members = null;
- protected int timeout = 500;
+ protected int timeout = 0;
protected JChannel channel = null;
protected DistributedReplicantManagerImpl replicantManager;
protected String nodeName;
@@ -64,16 +65,10 @@
public void init() throws Exception
{
- log.info("Get current members");
- View view = channel.GetView();
- this.members = view.GetMembers();
- log.info("Num cluster members: " + members.size());
log.info("SetMembershipListener");
SetMembershipListener(this);
log.info("SetMessageListener");
SetMessageListener(this);
- log.info("get nodeName");
- this.nodeName = channel.GetLocalAddress().toString();
log.info("create replicant manager");
this.replicantManager = new DistributedReplicantManagerImpl(this);
log.info("init replicant manager");
@@ -107,6 +102,21 @@
log.info("done initing..");
}
+ public void start() throws Exception
+ {
+ log.info("get nodeName");
+ this.nodeName = channel.GetLocalAddress().toString();
+ log.info("Get current members");
+ View view = channel.GetView();
+ this.members = view.GetMembers();
+ log.info("Num cluster members: " + members.size());
+ // We must now syncrhonize new state transfer subscriber
+ boolean rc = channel.GetState(null, 8000);
+ if (rc) log.info("State was retrieved successfully");
+ else log.info("State could not be retrieved, (must be first member of
group)");
+ replicantManager.start();
+ }
+
public void close() throws Exception
{
channel.Close();
@@ -157,7 +167,14 @@
if (rsp != null)
{
for (int i = 0; i < rsp.size(); i++)
-rtn.add(rsp.elementAt(i));
+ {
+Object item = rsp.elementAt(i);
+if (item instanceof Rsp)
+{
+ item = ((Rsp)item).GetValue();
+}
+rtn.add(item);
+ }
}
if (!excludeSelf)
@@ -182,9 +199,9 @@
{
stateHandlers.put(objectName, subscriber);
// We must now syncrhonize new state transfer subscriber
- boolean rc = channel.GetState(null, 8000);
- if (rc) log.info("State was retrieved successfully");
- else log.info("State could not be retrieved, (must be first member of
group
[JBoss-dev] CVS update: newsite/src/docs store.jsp
User: starksm Date: 01/09/19 16:56:12 Modified:src/docs store.jsp Log: Update the MVCSoft product ID. Revision ChangesPath 1.2 +1 -1 newsite/src/docs/store.jsp Index: store.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/store.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- store.jsp 2001/08/30 22:29:19 1.1 +++ store.jsp 2001/09/19 23:56:12 1.2 @@ -18,7 +18,7 @@ It supports EJB 2.0 CMP entity objects, relationships, and the EJB Query Language. You can begin working with EJB 2.0 entities right away, and you are free to redistribute your processed EJB components along with the MVCSoft runtime components at no additional cost. Developed by Dan OConnor. - Buy at Flashline + Buy at Flashline JBoss Deployer Plugin for Together A plugin for the popular TogetherJ modeling IDE that allows one to launch JBoss in debug mode, deploy the EJBs, launch Tomcat in debug and ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] VirtualHosts, security and deployers
- Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 3:50 PM Subject: Re: [JBoss-dev] VirtualHosts, security and deployers > Hi, > This is great! > > I have some questions... > > As I understand it a virtual host is an ip address (+ port?) Just an IP address and maybe a name. The name may not resolve to the IP address if the interface on which a service is bound is behind a NAT firewall. The services associated with the virtual host will have ports. > A security domain is an authentication/authorization mechanism (instance), > and something is within a security domain if it uses that instance for its > authentication/authorization. > Correct. It is a logical grouping of users, roles, a KeyStore(certs, private keys, secret keys), permissions, etc. > In your scheme are the virtual hosts and security domains coextensive? (do > they partition the set of components identically)? > Do the security domains form a sub-partition of the virtual hosts? vice > versa? are they independent? > A security domain is really a passive property that is available to the services within the domain. The only point at which a security domain and virtual host have a relationship is if the domain was using SSL/TLS and needed a server certificate that used the virtual host DNS name in order for SSL clients to see a valid certificate. Other than that the virtual host and security domain are really independent. > And for me the biggest question - how does this relate to classloaders? > > So... if virtual host = security domain, do we also have a classloader > (ServiceLibrary/Scope type thing) for it? Is this the same as the > application classloader or is it the parent classloader of the application > classloader? > I can see it going that way if you want the services in a domain to be isolated from other domains. Users trying to use JBoss for ISP hosting definitely would like that property. In that case the Application MBean would have a class loader that simply isolated the application resources from other domains. Java2 permissions can also be associated with the domain level class loader. > > More comments interspersed. > > On 2001.09.19 16:50:56 -0400 Scott M Stark wrote: > > I've been looking at how to include virtual hosts for wars, ejbs and rars > > that need to bind their exported interfaces to specific addresses. Also > > needed > > is a notion of a security domain for the KeyStore if you need to use > > SSL/TLS > > with > > the exported transport. The security domain could also be used for > > authentication > > and authorization of users, principal mapping, single sign-on, etc. > Certainly an rar needs some security support, but what interface would one > export that is bound to an address? > I can think of many. JDBC connections when we start offering client containers, JMS connections, etc. Basically any managed connection may need to be made available only on the virtual host interface. > > All services within a J2eeApplication domain would inherit the > > J2eeApplication domain > > name as their JMX ObjectName domain component. All services would be > > associated > > with the security domain of the J2eeApplication domain. > > OK, but haven't you left out the configuration of the security domain? For > instance, the ConnectionFactoryLoader security stuff seems to have > disappeared. I don't see right off how you could easily separate principal > mappings from their ConnectionFactories-- it seems to me that one > application might use 5 ConnectionFactories each with an incompatible > PrincipalMapping. > The SecurityDomain configuration would show up in a mbean along with the corresponding JAAS login configuration info. I removed the security related config from the ConnectionFactories as this would be delegated to the SecurityDomain object. > > > > A similar domain notion would need to be added to the 3.0 RH services > > configuration. > > > > An alternative is to simply add VirtualHost and SecurityDomain notions to > > the > > common ServiceMBean interface for example, and use naming conventions to > > achieve the same effect. > > I think being able to deploy/undeploy sars or *service.xml into a > preexisting VirtualHost/SecurityDomain is desirable. How about having a > "universal deployer" that sets up the VirtualHost/SecurityDomain, that must > be deployed first, and then anything it allows (services, rars, ears, wars, > whatever) can be deployed into it based on their VirtualHost/SecurityDomain > attributes. Having the mbeans separate rather than enclosed seems to me > offhand as if it would make immediate and delayed deployment more similar > and simpler. On the other hand...Enclosing the sets of mbeans in one > element provides a convenient "set" of mbeans to deploy together in the > configure/init/start cycle. How about... the enclosing element just > specifies the domain, virtual host, and security domain, and all the
[JBoss-dev] CVS update: jboss-j2ee/src/main/javax/transaction/xa package.html XAException.java XAResource.java Xid.java
User: sparre
Date: 01/09/19 16:29:04
Modified:src/main/javax/transaction/xa XAException.java
XAResource.java Xid.java
Added: src/main/javax/transaction/xa package.html
Log:
Some XA javadocs
Revision ChangesPath
1.6 +149 -17 jboss-j2ee/src/main/javax/transaction/xa/XAException.java
Index: XAException.java
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/main/javax/transaction/xa/XAException.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- XAException.java 2001/05/19 08:23:10 1.5
+++ XAException.java 2001/09/19 23:29:03 1.6
@@ -6,68 +6,200 @@
*/
package javax.transaction.xa;
-/** The XAException is thown by the Resource Manager (RM) to inform the
-Transaction Manager of error encountered for the transaction involved.
-
-@version $Revision: 1.5 $
-*/
+/**
+ * The XAException is thrown by resource managers in case of problems.
+ *
+ * @version $Revision: 1.6 $
+ */
public class XAException extends java.lang.Exception {
+/**
+ * The error code.
+ */
public int errorCode = 0;
-/** Creates new XAException without detail message.
-*/
+/**
+ * Creates new XAException without detail message.
+ */
public XAException() {
}
-/** Constructs an XAException with the specified detail message.
-@param msg the detail message.
-*/
+/**
+ * Constructs an XAException with the specified detail
+ * message.
+ *
+ * @param msg the detail message.
+ */
public XAException(String msg) {
super(msg);
}
-/** Constructs an XAException for the specified error code.
-@param msg the detail message.
-*/
+/**
+ * Constructs an XAException for the specified error code.
+ *
+ * @param errorCode the error code.
+ */
public XAException(int errorCode) {
super();
this.errorCode = errorCode;
}
// STATIC VARIABLES -
+
+// changed numbers to match SUNs by pkendall for interoperability
-/** changed numbers to match SUNs by pkendall for interoperability */
+// added by kimptoc - needed for jbossmq to compile...
+// others added by jwalters for completeness
-/** added by kimptoc - needed for jbossmq to compile... */
-/** others added by jwalters for completeness */
+/**
+ * Error code indicating that an asynchronous operation is outstanding.
+ */
public static final int XAER_ASYNC = -2;
+
+/**
+ * Error code indicating that a resource manager error has occurred.
+ */
public static final int XAER_RMERR = -3;
+
+/**
+ * Error code indicating that an {@link Xid} is not valid.
+ */
public static final int XAER_NOTA = -4;
+
+/**
+ * Error code indicating that invalid arguments were passed.
+ */
public static final int XAER_INVAL = -5;
+
+/**
+ * Error code indicating a protocol error. This happens if a method
+ * is invoked on a resource when it is not in the correct state for it.
+ */
public static final int XAER_PROTO = -6;
+
+/**
+ * Error code indicating that the resource manager has failed and is
+ * not available.
+ */
public static final int XAER_RMFAIL= -7;
+
+/**
+ * Error code indicating that a Xid given as an argument is already
+ * known to the resource manager.
+ */
public static final int XAER_DUPID = -8;
+
+/**
+ * Error code indicating that the resource manager is doing work
+ * outside the global transaction.
+ */
public static final int XAER_OUTSIDE = -9;
+
+// added by jwalters - needed for jboss
-/** added by jwalters - needed for jboss */
+/**
+ * Error code indicating that the transaction branch was read-only,
+ * and has already been committed.
+ */
public static final int XA_RDONLY = 3;
+
+/**
+ * Error code indicating that the method invoked returned without having
+ * any effect, and that it may be invoked again.
+ * Note that this constant is not defined in JTA 1.0.1, but appears in
+ * J2EE(TM) as shipped by SUN.
+ */
public static final int XA_RETRY = 4;
+
+/**
+ * Error code indicating that a heuristic mixed decision was made.
+ * This indicates that parts of the transaction were committed,
+ * while other parts were rolled back.
+ */
public static final int XA_HEURMIX = 5;
+
+/**
+ * Error code indicating that a heuristic ro
Re: [JBoss-dev] BUILD FAILED
How did you start the build? From jboss-all/security or jboss-all/build? --jason On Thu, 20 Sep 2001, Philip Van Bogaert wrote: > Hi, > If i try to build jboss-all > i get various of compiler-errors > what can i do to help resolve this (i think classpath problems) > > Greetz-Tbone > > output follows: > > compile-classes: > [unjar] Expanding: C:\sandbox\jboss-all\thirdparty\sun\jaas\lib\jaas.jar > into C:\sandbox\jboss-all\security\output\classes > [javac] Compiling 16 source files to > C:\sandbox\jboss-all\security\output\classes > C:\sandbox\jboss-all\security\src\main\org\jboss\security\AbstractSecurityPr > oxy. > java:14: cannot resolve symbol > symbol: class MethodInvocation > location: package ejb > import org.jboss.ejb.MethodInvocation; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManager.java:42: cannot resolve symbol > symbol: class CachePolicy > location: package util > import org.jboss.util.CachePolicy; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyMa > nager.java:43: cannot resolve symbol > symbol: class TimedCachePolicy > location: package util > import org.jboss.util.TimedCachePolicy; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyMa > nager.java:83: cannot resolve symbol > symbol: class CachePolicy > location: class org.jboss.security.plugins.JaasSecurityManager >private CachePolicy domainCache; >^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManager.java:153: cannot resolve symbol > symbol: class CachePolicy > location: class org.jboss.security.plugins.JaasSecurityManager >public void setCachePolicy(CachePolicy domainCache) > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManagerService.java:40: cannot resolve symbol > symbol: class Logger > location: package logging > import org.jboss.logging.Logger; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManagerService.java:44: cannot resolve symbol > symbol: class CachePolicy > location: package util > import org.jboss.util.CachePolicy; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyMa > nagerService.java:45: cannot resolve symbol > symbol: class ServiceMBeanSupport > location: package system > import org.jboss.system.ServiceMBeanSupport; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyMa > nagerService.java:61: cannot resolve symbol > symbol: class ServiceMBeanSupport > location: class org.jboss.security.plugins.JaasSecurityManagerService >extends ServiceMBeanSupport >^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManagerServiceMBean.java:13: cannot resolve symbol > symbol: class ServiceMBean > location: package system > extends org.jboss.system.ServiceMBean > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyMa > nagerService.java:65: cannot resolve symbol > symbol: class Logger > location: class org.jboss.security.plugins.JaasSecurityManagerService >private static Logger log; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManagerService.java:71: cannot resolve symbol > symbol: class CachePolicy > location: class org.jboss.security.plugins.JaasSecurityManagerService >private static CachePolicy cachePolicy; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri > tyManagerService.java:213: cannot resolve symbol > symbol: class Logger > location: class > org.jboss.security.plugins.JaasSecurityManagerService.SecurityDo > mainObjectFactory > static Logger log = Logger.create(SecurityDomainObjectFactory.class); > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo > licy > Service.java:19: cannot resolve symbol > symbol: class NonSerializableFactory > location: package naming > import org.jboss.naming.NonSerializableFactory; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo > licy > Service.java:22: cannot resolve symbol > symbol: class ServiceMBeanSupport > location: package system > import org.jboss.system.ServiceMBeanSupport; > ^ > C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo > licy > Service.java:30: cannot resolve symbol > symbol: class ServiceMBeanSupport > location: class org.jboss.security.plugins.SecurityPolicyService > public class SecurityPolicyService extends ServiceMBeanSupport implements > Securi > tyPolicyServiceMBean >
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
Ok I have had a look at the mq tests and they run fine for me, I didn't have any trouble. The only thing I changed was to use the rollinglogged persistence manager instead of the file persistence manager for JBossMQ. This shouldn't change anything except the performance (rolling logged is many times faster), I only did it so the tests would finish in a reasonable time, as it was the JBossMQPerfStressTestCase took nearly 5 minutes to finish. I would imagine that with file persistence and running 1000 iterations the total time could take something like an 30 minutes to an hour (this is only a rough estimate based on my previous experience). During the test several errors are thrown out by the engine, looking at the code these errors are all created by the test code closing the session the message listener is registered with too soon. In other words these errors are difficult to avoid but harmless. The errors in particular I am talking about are [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. javax.jms.JMSException: Invalid transaction id. at org.jboss.mq.SpyXAResourceManager.ackMessage(SpyXAResourceManager.java:62) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:365) at java.lang.Thread.run(Thread.java:484) or [SpyMessageConsumer,WARN] Message consumer closing due to error in listening thread. org.jboss.mq.SpyJMSException: Cannot create a ConnectionReceiver at org.jboss.mq.Connection.receive(Connection.java:595) at org.jboss.mq.SpyMessageConsumer.run(SpyMessageConsumer.java:319) at java.lang.Thread.run(Thread.java:484) linked exception is: javax.jms.JMSException: The provided subscription does not exist <> These should happen at most once per run, and sometimes you get neither, if the timing of the threads closing down happens in the right order. Other than that everything seems fine to me. If you continue to have trouble let me know. Cheers David > -Original Message- > From: David Maplesden [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 20, 2001 8:21 AM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > I'll have a look, I've been through the MQ test stuff before > and it did all > work originally. I haven't looked at it since all the > changes to the build > system and new test stuff so its not too surprising if its > having trouble. > > I'll let you know how I get on. > > David > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 20, 2001 7:35 AM > > To: jboss-dev > > Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > > > > Hi, > > > > It appears that most of the jbossmq tests are not working > > currently with > > rh. Much of this appears to me to be configuration problems. On my > > machine, running JBossMQPerfStressTestCase usually freezes > > something so > > that subsequent tests don't run and jboss will not shut > down: for this > > reason I commented it out of the testsuite/build.xml. > > > > Could the jbossmq experts take a look? > > > > You may find the ability to set counts via a local.properties > > file useful: > > > > ### Test properties > > > > junit.timeout=12 > > jbosstest.threadcount=2 > > jbosstest.iterationcount=2 > > jbosstest.beancount=2 > > > > > > You may find the one-test target useful: > > > > ./build.sh -DJBossMQPerfStressTestCase one-test > > > > runs only the named test. > > > > Thanks > > david jencks > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] BUILD FAILED
Hi, If i try to build jboss-all i get various of compiler-errors what can i do to help resolve this (i think classpath problems) Greetz-Tbone output follows: compile-classes: [unjar] Expanding: C:\sandbox\jboss-all\thirdparty\sun\jaas\lib\jaas.jar into C:\sandbox\jboss-all\security\output\classes [javac] Compiling 16 source files to C:\sandbox\jboss-all\security\output\classes C:\sandbox\jboss-all\security\src\main\org\jboss\security\AbstractSecurityPr oxy. java:14: cannot resolve symbol symbol : class MethodInvocation location: package ejb import org.jboss.ejb.MethodInvocation; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManager.java:42: cannot resolve symbol symbol : class CachePolicy location: package util import org.jboss.util.CachePolicy; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyMa nager.java:43: cannot resolve symbol symbol : class TimedCachePolicy location: package util import org.jboss.util.TimedCachePolicy; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyMa nager.java:83: cannot resolve symbol symbol : class CachePolicy location: class org.jboss.security.plugins.JaasSecurityManager private CachePolicy domainCache; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManager.java:153: cannot resolve symbol symbol : class CachePolicy location: class org.jboss.security.plugins.JaasSecurityManager public void setCachePolicy(CachePolicy domainCache) ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManagerService.java:40: cannot resolve symbol symbol : class Logger location: package logging import org.jboss.logging.Logger; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManagerService.java:44: cannot resolve symbol symbol : class CachePolicy location: package util import org.jboss.util.CachePolicy; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyMa nagerService.java:45: cannot resolve symbol symbol : class ServiceMBeanSupport location: package system import org.jboss.system.ServiceMBeanSupport; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyMa nagerService.java:61: cannot resolve symbol symbol : class ServiceMBeanSupport location: class org.jboss.security.plugins.JaasSecurityManagerService extends ServiceMBeanSupport ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManagerServiceMBean.java:13: cannot resolve symbol symbol : class ServiceMBean location: package system extends org.jboss.system.ServiceMBean ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyMa nagerService.java:65: cannot resolve symbol symbol : class Logger location: class org.jboss.security.plugins.JaasSecurityManagerService private static Logger log; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManagerService.java:71: cannot resolve symbol symbol : class CachePolicy location: class org.jboss.security.plugins.JaasSecurityManagerService private static CachePolicy cachePolicy; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\JaasSecuri tyManagerService.java:213: cannot resolve symbol symbol : class Logger location: class org.jboss.security.plugins.JaasSecurityManagerService.SecurityDo mainObjectFactory static Logger log = Logger.create(SecurityDomainObjectFactory.class); ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo licy Service.java:19: cannot resolve symbol symbol : class NonSerializableFactory location: package naming import org.jboss.naming.NonSerializableFactory; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo licy Service.java:22: cannot resolve symbol symbol : class ServiceMBeanSupport location: package system import org.jboss.system.ServiceMBeanSupport; ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo licy Service.java:30: cannot resolve symbol symbol : class ServiceMBeanSupport location: class org.jboss.security.plugins.SecurityPolicyService public class SecurityPolicyService extends ServiceMBeanSupport implements Securi tyPolicyServiceMBean ^ C:\sandbox\jboss-all\security\src\main\org\jboss\security\plugins\SecurityPo licy ServiceMBean.java:17: cannot resolve symbol symbol : class ServiceMBean location: package system public interface SecurityPolicyServiceMBean extends org.jboss.system.ServiceMBean
Re: [JBoss-dev] RH, Jetty, Service Archives...
I've been seeing something like this too, could you send it to me also? I think there may be a problem with the URLClassloaders getting stuck if they have a startup problem and then you can never get rid of them. Will try to look soon. Thanks david jencks On 2001.09.19 17:38:53 -0400 Julian Gosnell wrote: > David Maplesden wrote: > > > Hi Julian, > > > > Most of your problems are coming from the fact that service deployment > has > > only really been half done, there are several issues directly relating > to > > your comments below that need to be sorted out. > > > > Briefly then... > > > > > I am working on packaging up the Jetty service into an archive. > > > > > > I have some questions... > > > > > > 1. Should I call it a SAR or a JSR ? > > > > Whichever you want, I think I am begining to prefer .sar > > > > > > > > 2. should I deploy it to ./deploy or ./deploy/lib ? > > > > > > > Probably in ./deploy/lib as this way you are guaranteed that it will be > > deployed before any EAR's in ./deploy. This is one of the outstanding > > issues with deployment at the moment, we have no way of specifying > > dependencies between sar's and ear's and rar's. > > > > > 3. Can I include jars in it (I tried top level dir and META-INF/lib - > > > no joy) - how ? > > > > > > > You can't currently include jars, you should be able to in my opinion, > but > > currently you can't. > > > > > 4. Should Jetty's configuration be done in the archive, nicely > > > packaged, but awkward to edit, or in ./conf/default, easy to edit but > > > ... - or both ? > > > > > > > Whichever you think is best. I personally think there should be room > for a > > directory structure in a sar that gets expanded when it is deployed. > This > > way you can include it in your sar and then it gets expanded to where > > someone can easily edit it. There would be issues with redeployment > but > > they shouldn't be hard to resolve. > > > > > 5. It only seems to deploy some of the time - other > > > times I get : > > > > > > java.net.MalformedURLException: no protocol: > > > META-INF/jboss-service.xml > > > at java.net.URL.(URL.java:473) > > > at java.net.URL.(URL.java:376) > > > at java.net.URL.(URL.java:330) > > > at org.jboss.deployment.ServiceDeployer.getDocument(Unknown Source) > > > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > > > at java.lang.reflect.Method.invoke(Native Method) > > > at > > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > > java:1628) > > > > > > at > > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > > java:1523) > > > > > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > > > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > > > at java.lang.Thread.run(Thread.java:484) > > > [AutoDeployer] Deployment > > > failed:file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0 > > > alpha/deploy/lib/jetty.sar > > > > > > org.jboss.deployment.DeploymentException: No valid service.xml file > > > foundno protocol: META-INF/jboss-service.xml > > > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > > > at java.lang.reflect.Method.invoke(Native Method) > > > at > > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > > java:1628) > > > > > > at > > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > > java:1523) > > > > > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > > > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > > > at java.lang.Thread.run(Thread.java:484) > > > > > > > This final error should only occur if there is no jboss-service.xml > file in > > the sar's META-INF directory. Let us know if it occurs otherwise. > > OTHERWISE ! > > If I take the same SAR file, which definitely HAS a jboss-service.xml > file in > it, it will sometimes deploy perfectly, othertimes, I get the above > exception. > > Once I have got the exception out of a running JBoss, I have to restart > it, > since the file will never deploy successfully again. > > I can mail you the jetty.sar if you like. > > Jules > > > > > > > > > And yet if I restart with the same service deployed - no > > > problemo. Once the exception has been thrown, that seems to be > > > it. Subsequent deployments all fail in the same manner. > > > > > > > > > Any clues/pointers would be much appreciated, > > > > > > > > > > > > Jules > > > > > > > Cheers > > > > David > > > > > > > > _ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > >
[JBoss-dev] CVS update: jbosstest build.xml
User: dmaplesden Date: 01/09/19 15:44:50 Modified:.build.xml Log: change one-test target to find tests in 'perf' directories as well Revision ChangesPath 1.30 +2 -1 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- build.xml 2001/09/19 19:16:53 1.29 +++ build.xml 2001/09/19 22:44:50 1.30 @@ -10,7 +10,7 @@ - + @@ -1841,6 +1841,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MDB non-xa cf & tx timeout
hi jason, On Wed, 2001-09-19 at 21:10, Jason Dillon wrote: > Just a note, but it looks like there is still a problem with MDB tx timeouts > with a non-xa connection factory. I mentioned this problem a while ago, > then the world fell apart, then my computers freaked out and then I got ill. > > Now, I have recomved from 2 of the 3 and am looking into this problem some > more. I am currently using a 2.5 snapshot, so I might move over to 2.4.x. > It does have the new locking and jbossmq stuff right? > > Anyways, I think there is still an issue with the tx recipts for an MDB. I > have to set the default tx timeout insainly high to avoid this problem. we've been experiencing something similar here, strange TX timeouts when using Entity Beans from a MDB (actually the MDB calls a SLSB which does some stuff which involves ~10 EB's). the TX times out after just ~5 seconds despite the fact that the timeout is set to 200 or somethng like that ... we're trying to nail down the problem and see if we can get a minimal test case for reproducing this by tomorrow. on the other hand, a first look actually suggests that the problem is when an Entity Bean throws a CreateException and calls setRollBackOnly() ... with 2.4.0 the SLSB was able to catch() the CreateException; with 2.4.1 the CreateException never gets through to the SLSB. this only started to happen when we switched over to 2.4.1 (which does have the new locking and JBossMQ in place); 2.4.0 does not show this behaviour. hope to have more precise data available by tomorrow. stay tuned, christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/test JBossMQUnitTestCase.java
User: dmaplesden
Date: 01/09/19 15:45:23
Modified:src/main/org/jboss/test/jbossmq/test
JBossMQUnitTestCase.java
Log:
added additional simple tests
Revision ChangesPath
1.3 +221 -10
jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java
Index: JBossMQUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/test/JBossMQUnitTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossMQUnitTestCase.java 2001/09/15 01:50:16 1.2
+++ JBossMQUnitTestCase.java 2001/09/19 22:45:23 1.3
@@ -15,14 +15,14 @@
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-package org.jboss.test.jbossmq.test;
+package org.jboss.test.jbossmq.test;
import javax.naming.*;
import javax.jms.*;
import java.util.*;
-import org.apache.log4j.Category;
import org.jboss.test.JBossTestCase;
+import org.apache.log4j.Category;
/**
* JBossMQUnitTestCase.java
@@ -32,7 +32,7 @@
* @author
* @version
*/
-public class JBossMQUnitTestCase
+public class JBossMQUnitTestCase
extends JBossTestCase
{
// Provider specific
@@ -43,6 +43,7 @@
static String TEST_TOPIC = "topic/testTopic";
//JMSProviderAdapter providerAdapter;
+ static Context context;
static QueueConnection queueConnection;
static TopicConnection topicConnection;
@@ -55,7 +56,7 @@
private void drainQueue() throws Exception {
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueReceiver receiver = session.createReceiver(queue);
Message message = receiver.receive( 2000 );
@@ -82,10 +83,15 @@
protected void connect() throws Exception {
- QueueConnectionFactory queueFactory = (QueueConnectionFactory)
getInitialContext().lookup(QUEUE_FACTORY);
+ if( context == null ) {
+
+ context = new InitialContext();
+
+ }
+ QueueConnectionFactory queueFactory = (QueueConnectionFactory)
context.lookup(QUEUE_FACTORY);
queueConnection = queueFactory.createQueueConnection();
- TopicConnectionFactory topicFactory =
(TopicConnectionFactory)getInitialContext().lookup(TOPIC_FACTORY);
+ TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.lookup(TOPIC_FACTORY);
topicConnection = topicFactory.createTopicConnection();
getLog().debug("Connection to spyderMQ established.");
@@ -117,7 +123,7 @@
drainQueue();
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueSender sender = session.createSender(queue);
TextMessage message = session.createTextMessage();
@@ -173,9 +179,10 @@
public void run() {
Category log = Category.getInstance(getClass().getName());
try {
+
log.debug("Server Thread Started");
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)new InitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueReceiver queueReceiver = session.createReceiver(queue);
@@ -198,7 +205,7 @@
log.debug("Server Thread Finished");
} catch ( Exception e ) {
- log.error("Error", e);
+ log.error("Error",e);
}
}
};
@@ -206,7 +213,7 @@
serverThread.start();
QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)getInitialContext().lookup(TEST_QUEUE);
+ Queue queue = (Queue)context.lookup(TEST_QUEUE);
QueueRequestor queueRequestor = new QueueRequestor(session, queue);
TextMessage message = session.createTextMessage();
@@ -231,4 +238,208 @@
getLog().debug("RequestReplyQueue passed");
}
+
+ public void testMessageListener() throws Exception{
+ getLog().debug("Starting MessageListener test");
+
+ connect();
+ queueConnection.start();
+ drainQueue();
+
Re: [JBoss-dev] VirtualHosts, security and deployers
Hi, This is great! I have some questions... As I understand it a virtual host is an ip address (+ port?) A security domain is an authentication/authorization mechanism (instance), and something is within a security domain if it uses that instance for its authentication/authorization. In your scheme are the virtual hosts and security domains coextensive? (do they partition the set of components identically)? Do the security domains form a sub-partition of the virtual hosts? vice versa? are they independent? And for me the biggest question - how does this relate to classloaders? So... if virtual host = security domain, do we also have a classloader (ServiceLibrary/Scope type thing) for it? Is this the same as the application classloader or is it the parent classloader of the application classloader? More comments interspersed. On 2001.09.19 16:50:56 -0400 Scott M Stark wrote: > I've been looking at how to include virtual hosts for wars, ejbs and rars > that need to bind their exported interfaces to specific addresses. Also > needed > is a notion of a security domain for the KeyStore if you need to use > SSL/TLS > with > the exported transport. The security domain could also be used for > authentication > and authorization of users, principal mapping, single sign-on, etc. Certainly an rar needs some security support, but what interface would one export that is bound to an address? > > Right now there are serveral notions of deployers, not all of which are > well > defined by an interface. There is a base DeployerMBean that is > implemented by the J2eeDeployer and RARDeployer, but it is not used by > the > EJB deployer(ContainerFactory) or the WAR deployers(EmbeddedTomcat, > EmbeddedJetty). > Rather there is an assumption about the signature of deploy made by the > J2eeDeployer > for the JarDeployerName and WarDeployerName mbeans it uses. There is also > no > unified notion of security at the deployer level. EJBs and WARs based > security off of > jboss.xml and jboss-web.xml descriptors. RARs have another notion of > security > at the ConnectionFactoryLoaderMBean level. > > I would like to come up with an application domain notion that combines > all > deployers, > auto deploy directories, virtual host interface and security into a logic > collection of > resources and application components with a common interface address and > security > domain. Effectively all of the mbeans in an application domain become > contained > mbeans within the application domain. For example, > > name="Default:service=J2eeApplication"> > Default > localhost > java:/jaas/localhost > :service=ContainerFactory > :service=EmbeddedCatalina > :service=RARDeployer > >name=":service=ContainerFactory"> > true > false > false > true > false > >name=":service=EmbeddedCatalina" > > webapps > >name="JCA:service=RARDeployer" /> > > > name=":service=ConnectionManagerFactoryLoader,name=MinervaNoTransCMFactory"> > MinervaNoTransCMFactory > > org.jboss.pool.connector.jboss.MinervaNoTransCMFactory > > > > > name="JCA:service=ConnectionFactoryLoader,name=MinervaDS"> > MinervaDS > :service=RARDeployer > > Minerva JDBC LocalTransaction ResourceAdapter > > > ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:1476 > > > MinervaSharedLocalCMFactory > > > # Pool type - uncomment to force, otherwise it is the default > #PoolConfiguration=per-factory > # Connection pooling properties - see > # org.jboss.pool.PoolParameters > MinSize=0 > MaxSize=10 > Blocking=true > GCEnabled=false > IdleTimeoutEnabled=false > InvalidateOnError=false > TrackLastUsed=false > GCIntervalMillis=12 > GCMinIdleMillis=120 > IdleTimeoutMillis=180 > MaxIdleTimeoutPercent=1.0 > > > > > :service=J2eeApplication > name="URLs">../deploy/default,../deploy/default/lib > > > > All services within a J2eeApplication domain would inherit the > J2eeApplication domain > name as their JMX ObjectName domain component. All services would be > associated > with the security domain of the J2eeApplication domain. OK, but haven't you left out the configuration of the security domain? For instance, the ConnectionFactoryLoader security stuff seems to have disappeared. I don't see right off how you could easily separate principal mappings from their ConnectionFactories-- it seems to me that one application might use 5 ConnectionFactories each with an incompatible PrincipalMapping. > > A similar domain notion would need to be added to the 3.0 RH services > configuration. > > An alternative is to simply add VirtualHost and SecurityDomain notions to > the > common ServiceMBean interface for example, and use naming conventions to > achieve the same effect. I think being able to deploy/undeploy
Re: [JBoss-dev] RH, Jetty, Service Archives...
David Maplesden wrote: > Hi Julian, > > Most of your problems are coming from the fact that service deployment has > only really been half done, there are several issues directly relating to > your comments below that need to be sorted out. > > Briefly then... > > > I am working on packaging up the Jetty service into an archive. > > > > I have some questions... > > > > 1. Should I call it a SAR or a JSR ? > > Whichever you want, I think I am begining to prefer .sar > > > > > 2. should I deploy it to ./deploy or ./deploy/lib ? > > > > Probably in ./deploy/lib as this way you are guaranteed that it will be > deployed before any EAR's in ./deploy. This is one of the outstanding > issues with deployment at the moment, we have no way of specifying > dependencies between sar's and ear's and rar's. > > > 3. Can I include jars in it (I tried top level dir and META-INF/lib - > > no joy) - how ? > > > > You can't currently include jars, you should be able to in my opinion, but > currently you can't. > > > 4. Should Jetty's configuration be done in the archive, nicely > > packaged, but awkward to edit, or in ./conf/default, easy to edit but > > ... - or both ? > > > > Whichever you think is best. I personally think there should be room for a > directory structure in a sar that gets expanded when it is deployed. This > way you can include it in your sar and then it gets expanded to where > someone can easily edit it. There would be issues with redeployment but > they shouldn't be hard to resolve. > > > 5. It only seems to deploy some of the time - other > > times I get : > > > > java.net.MalformedURLException: no protocol: > > META-INF/jboss-service.xml > > at java.net.URL.(URL.java:473) > > at java.net.URL.(URL.java:376) > > at java.net.URL.(URL.java:330) > > at org.jboss.deployment.ServiceDeployer.getDocument(Unknown Source) > > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > java:1628) > > > > at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > java:1523) > > > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > > at java.lang.Thread.run(Thread.java:484) > > [AutoDeployer] Deployment > > failed:file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0 > > alpha/deploy/lib/jetty.sar > > > > org.jboss.deployment.DeploymentException: No valid service.xml file > > foundno protocol: META-INF/jboss-service.xml > > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > > at java.lang.reflect.Method.invoke(Native Method) > > at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > java:1628) > > > > at > > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > > java:1523) > > > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > > at java.lang.Thread.run(Thread.java:484) > > > > This final error should only occur if there is no jboss-service.xml file in > the sar's META-INF directory. Let us know if it occurs otherwise. OTHERWISE ! If I take the same SAR file, which definitely HAS a jboss-service.xml file in it, it will sometimes deploy perfectly, othertimes, I get the above exception. Once I have got the exception out of a running JBoss, I have to restart it, since the file will never deploy successfully again. I can mail you the jetty.sar if you like. Jules > > > > And yet if I restart with the same service deployed - no > > problemo. Once the exception has been thrown, that seems to be > > it. Subsequent deployments all fail in the same manner. > > > > > > Any clues/pointers would be much appreciated, > > > > > > > > Jules > > > > Cheers > > David > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH, Jetty, Service Archives...
Hi Julian, Most of your problems are coming from the fact that service deployment has only really been half done, there are several issues directly relating to your comments below that need to be sorted out. Briefly then... > I am working on packaging up the Jetty service into an archive. > > I have some questions... > > 1. Should I call it a SAR or a JSR ? Whichever you want, I think I am begining to prefer .sar > > 2. should I deploy it to ./deploy or ./deploy/lib ? > Probably in ./deploy/lib as this way you are guaranteed that it will be deployed before any EAR's in ./deploy. This is one of the outstanding issues with deployment at the moment, we have no way of specifying dependencies between sar's and ear's and rar's. > 3. Can I include jars in it (I tried top level dir and META-INF/lib - > no joy) - how ? > You can't currently include jars, you should be able to in my opinion, but currently you can't. > 4. Should Jetty's configuration be done in the archive, nicely > packaged, but awkward to edit, or in ./conf/default, easy to edit but > ... - or both ? > Whichever you think is best. I personally think there should be room for a directory structure in a sar that gets expanded when it is deployed. This way you can include it in your sar and then it gets expanded to where someone can easily edit it. There would be issues with redeployment but they shouldn't be hard to resolve. > 5. It only seems to deploy some of the time - other > times I get : > > java.net.MalformedURLException: no protocol: > META-INF/jboss-service.xml > at java.net.URL.(URL.java:473) > at java.net.URL.(URL.java:376) > at java.net.URL.(URL.java:330) > at org.jboss.deployment.ServiceDeployer.getDocument(Unknown Source) > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > at java.lang.Thread.run(Thread.java:484) > [AutoDeployer] Deployment > failed:file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0 > alpha/deploy/lib/jetty.sar > > org.jboss.deployment.DeploymentException: No valid service.xml file > foundno protocol: META-INF/jboss-service.xml > at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1628) > > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl. > java:1523) > > at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) > at org.jboss.deployment.AutoDeployer.run(Unknown Source) > at java.lang.Thread.run(Thread.java:484) > This final error should only occur if there is no jboss-service.xml file in the sar's META-INF directory. Let us know if it occurs otherwise. > And yet if I restart with the same service deployed - no > problemo. Once the exception has been thrown, that seems to be > it. Subsequent deployments all fail in the same manner. > > > Any clues/pointers would be much appreciated, > > > > Jules > Cheers David > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RH, Jetty, Service Archives...
I am working on packaging up the Jetty service into an archive. I have some questions... 1. Should I call it a SAR or a JSR ? 2. should I deploy it to ./deploy or ./deploy/lib ? 3. Can I include jars in it (I tried top level dir and META-INF/lib - no joy) - how ? 4. Should Jetty's configuration be done in the archive, nicely packaged, but awkward to edit, or in ./conf/default, easy to edit but ... - or both ? 5. It only seems to deploy some of the time - other times I get : java.net.MalformedURLException: no protocol: META-INF/jboss-service.xml at java.net.URL.(URL.java:473) at java.net.URL.(URL.java:376) at java.net.URL.(URL.java:330) at org.jboss.deployment.ServiceDeployer.getDocument(Unknown Source) at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) at org.jboss.deployment.AutoDeployer.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) [AutoDeployer] Deployment failed:file:/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/lib/jetty.sar org.jboss.deployment.DeploymentException: No valid service.xml file foundno protocol: META-INF/jboss-service.xml at org.jboss.deployment.ServiceDeployer.deploy(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.AutoDeployer.deploy(Unknown Source) at org.jboss.deployment.AutoDeployer.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) And yet if I restart with the same service deployed - no problemo. Once the exception has been thrown, that seems to be it. Subsequent deployments all fail in the same manner. Any clues/pointers would be much appreciated, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] VirtualHosts, security and deployers
I've been looking at how to include virtual hosts for wars, ejbs and rars that need to bind their exported interfaces to specific addresses. Also needed is a notion of a security domain for the KeyStore if you need to use SSL/TLS with the exported transport. The security domain could also be used for authentication and authorization of users, principal mapping, single sign-on, etc. Right now there are serveral notions of deployers, not all of which are well defined by an interface. There is a base DeployerMBean that is implemented by the J2eeDeployer and RARDeployer, but it is not used by the EJB deployer(ContainerFactory) or the WAR deployers(EmbeddedTomcat, EmbeddedJetty). Rather there is an assumption about the signature of deploy made by the J2eeDeployer for the JarDeployerName and WarDeployerName mbeans it uses. There is also no unified notion of security at the deployer level. EJBs and WARs based security off of jboss.xml and jboss-web.xml descriptors. RARs have another notion of security at the ConnectionFactoryLoaderMBean level. I would like to come up with an application domain notion that combines all deployers, auto deploy directories, virtual host interface and security into a logic collection of resources and application components with a common interface address and security domain. Effectively all of the mbeans in an application domain become contained mbeans within the application domain. For example, Default localhost java:/jaas/localhost :service=ContainerFactory :service=EmbeddedCatalina :service=RARDeployer true false false true false webapps MinervaNoTransCMFactory org.jboss.pool.connector.jboss.MinervaNoTransCMFactory MinervaDS :service=RARDeployer Minerva JDBC LocalTransaction ResourceAdapter ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:1476 MinervaSharedLocalCMFactory # Pool type - uncomment to force, otherwise it is the default #PoolConfiguration=per-factory # Connection pooling properties - see # org.jboss.pool.PoolParameters MinSize=0 MaxSize=10 Blocking=true GCEnabled=false IdleTimeoutEnabled=false InvalidateOnError=false TrackLastUsed=false GCIntervalMillis=12 GCMinIdleMillis=120 IdleTimeoutMillis=180 MaxIdleTimeoutPercent=1.0 :service=J2eeApplication ../deploy/default,../deploy/default/lib All services within a J2eeApplication domain would inherit the J2eeApplication domain name as their JMX ObjectName domain component. All services would be associated with the security domain of the J2eeApplication domain. A similar domain notion would need to be added to the 3.0 RH services configuration. An alternative is to simply add VirtualHost and SecurityDomain notions to the common ServiceMBean interface for example, and use naming conventions to achieve the same effect. Another alternative is to have multiple instances of JBoss running, one for each domain with the configuration name defining the domain with a multi-domain launcher. I'm looking for comments and suggestions on how to do this. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
I'll have a look, I've been through the MQ test stuff before and it did all work originally. I haven't looked at it since all the changes to the build system and new test stuff so its not too surprising if its having trouble. I'll let you know how I get on. David > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 20, 2001 7:35 AM > To: jboss-dev > Subject: [JBoss-dev] Help wanted on jbossmq tests (rh/3.0) > > > Hi, > > It appears that most of the jbossmq tests are not working > currently with > rh. Much of this appears to me to be configuration problems. On my > machine, running JBossMQPerfStressTestCase usually freezes > something so > that subsequent tests don't run and jboss will not shut down: for this > reason I commented it out of the testsuite/build.xml. > > Could the jbossmq experts take a look? > > You may find the ability to set counts via a local.properties > file useful: > > ### Test properties > > junit.timeout=12 > jbosstest.threadcount=2 > jbosstest.iterationcount=2 > jbosstest.beancount=2 > > > You may find the one-test target useful: > > ./build.sh -DJBossMQPerfStressTestCase one-test > > runs only the named test. > > Thanks > david jencks > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Help wanted on jbossmq tests (rh/3.0)
Hi, It appears that most of the jbossmq tests are not working currently with rh. Much of this appears to me to be configuration problems. On my machine, running JBossMQPerfStressTestCase usually freezes something so that subsequent tests don't run and jboss will not shut down: for this reason I commented it out of the testsuite/build.xml. Could the jbossmq experts take a look? You may find the ability to set counts via a local.properties file useful: ### Test properties junit.timeout=12 jbosstest.threadcount=2 jbosstest.iterationcount=2 jbosstest.beancount=2 You may find the one-test target useful: ./build.sh -DJBossMQPerfStressTestCase one-test runs only the named test. Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jbossmq/perf JBossMQPerfStressTestCase.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/jbossmq/perf
JBossMQPerfStressTestCase.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.2 +712 -527
jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java
Index: JBossMQPerfStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jbossmq/perf/JBossMQPerfStressTestCase.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JBossMQPerfStressTestCase.java2001/09/12 04:55:39 1.1
+++ JBossMQPerfStressTestCase.java2001/09/19 19:16:54 1.2
@@ -1,546 +1,731 @@
/*
- * Copyright (c) 2000 Hiram Chirino <[EMAIL PROTECTED]>
+ * JBoss, the OpenSource J2EE webOS
*
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package org.jboss.test.jbossmq.perf;
+import java.util.*;
+import javax.jms.*;
import javax.naming.*;
-import javax.jms.*;
-import java.util.*;
+import org.apache.log4j.Category;
+
+import org.jboss.test.JBossTestCase;
/**
- * JBossMQPerfStressTestCase.java
- *
- * Some simple tests of JBossMQ
+ * JBossMQPerfStressTestCase.java Some simple tests of JBossMQ
*
* @author
* @version
*/
+
+public class JBossMQPerfStressTestCase extends JBossTestCase
+{
-public class JBossMQPerfStressTestCase extends junit.framework.TestCase {
-
- // Provider specific
- static String TOPIC_FACTORY = "ConnectionFactory";
- static String QUEUE_FACTORY = "ConnectionFactory";
-
- static String TEST_QUEUE = "queue/testQueue";
- static String TEST_TOPIC = "topic/testTopic";
-
- static int PERFORMANCE_TEST_ITERATIONS = 1000;
- static byte[] PERFORMANCE_TEST_DATA_PAYLOAD = new byte[10*1024];
-
- static int TRANS_NONE = 0;
- static int TRANS_INDIVIDUAL = 1;
- static int TRANS_TOTAL = 2;
- static String[] TRANS_DESC = {"NOT", "individually", "totally"};
-
- //JMSProviderAdapter providerAdapter;
- static Context context;
- static QueueConnection queueConnection;
- static TopicConnection topicConnection;
-
- public JBossMQPerfStressTestCase(String name) throws Exception{
- super(name);
- }
-
-
- // Emptys out all the messages in a queue
- private void drainQueue() throws Exception {
-
- QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)context.lookup(TEST_QUEUE);
-
- QueueReceiver receiver = session.createReceiver(queue);
- Message message = receiver.receive( 2000 );
- int c=0;
- while( message != null ) {
- message = receiver.receive( 2000 );
- c++;
- }
-
- if( c!=0 )
- System.out.println(" Drained "+c+" messages from the queue");
-
- session.close();
-
- }
-
- private void waitForSynchMessage() throws Exception {
- QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)context.lookup(TEST_QUEUE);
-
- QueueReceiver receiver = session.createReceiver(queue);
- receiver.receive();
- session.close();
- }
-
- private void sendSynchMessage() throws Exception {
- QueueSession session = queueConnection.createQueueSession(false,
Session.AUTO_ACKNOWLEDGE);
- Queue queue = (Queue)context.lookup(TEST_QUEUE);
-
- QueueSender sender = session.createSender(queue);
-
- Message message = session.createMessage();
- sender.send(message);
-
- sessio
[JBoss-dev] CVS update: jbosstest build.xml
User: d_jencks
Date: 01/09/19 12:16:53
Modified:.build.xml
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.29 +36 -3 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- build.xml 2001/09/18 08:24:30 1.28
+++ build.xml 2001/09/19 19:16:53 1.29
@@ -10,7 +10,7 @@
-
+
@@ -69,6 +69,13 @@
+
+
+
+
+
+
+
@@ -119,6 +126,11 @@
os.name: ${os.name}
os.arch: ${os.arch}
os.version: ${os.version}
+
+
+jbosstest.iterationcount: ${jbosstest.iterationcount}
+jbosstest.threadcount: ${jbosstest.threadcount}
+jbosstest.beancount: ${jbosstest.beancount}
]]>
@@ -1514,6 +1526,9 @@
+
+
+
@@ -1533,7 +1548,9 @@
-
+
+
+
@@ -1608,6 +1625,10 @@
+
+
+
+
@@ -1704,6 +1725,10 @@
+
+
+
+
@@ -1749,7 +1774,11 @@
+
+
+
+
@@ -1765,7 +1794,7 @@
fork="${junit.batchtest.fork}">
-
+
@@ -1791,6 +1820,10 @@
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/perf/test PerfStressTestCase.java SecurePerfStressTestCase.java Setup.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/perf/test PerfStressTestCase.java
SecurePerfStressTestCase.java Setup.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.3 +42 -39
jbosstest/src/main/org/jboss/test/perf/test/PerfStressTestCase.java
Index: PerfStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/perf/test/PerfStressTestCase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- PerfStressTestCase.java 2001/09/17 17:33:53 1.2
+++ PerfStressTestCase.java 2001/09/19 19:16:54 1.3
@@ -35,15 +35,18 @@
/** Test of EJB call invocation overhead.
@author [EMAIL PROTECTED]
- @version $Revision: 1.2 $
+ @version $Revision: 1.3 $
*/
public class PerfStressTestCase extends JBossTestCase
{
-static int N = 1000;
+ int iterationCount;
+ int beanCount;
public PerfStressTestCase(String name)
{
super(name);
+ iterationCount = getIterationCount();
+ beanCount = getBeanCount();
}
public void testClientSession() throws Exception
@@ -70,7 +73,7 @@
bean.remove(0, 100);
long end = System.currentTimeMillis();
long elapsed = end - start;
- getLog().debug("Elapsed time = "+(elapsed / N));
+ getLog().debug("Elapsed time = "+(elapsed / iterationCount));
}
public void testTimings() throws Exception
@@ -172,144 +175,144 @@
private void noop(Probe bean) throws Exception
{
- getLog().debug("Starting "+N+" noop() invocations");
+ getLog().debug("Starting "+iterationCount+" noop() invocations");
long start = System.currentTimeMillis();
- for(int n = 0; n < N; n ++)
+ for(int n = 0; n < iterationCount; n ++)
bean.noop();
long end = System.currentTimeMillis();
long elapsed = end - start;
- getLog().debug(N+" noop() invocations = "+elapsed+" ms, "+(elapsed / N)+"
ms/noop");
+ getLog().debug(iterationCount+" noop() invocations = "+elapsed+" ms,
"+(elapsed / iterationCount)+" ms/noop");
}
private void ping(Probe bean) throws Exception
{
- getLog().debug("Starting "+N+" ping(PING) invocations");
+ getLog().debug("Starting "+iterationCount+" ping(PING) invocations");
long start = System.currentTimeMillis();
- for(int n = 0; n < N; n ++)
+ for(int n = 0; n < iterationCount; n ++)
bean.ping("PING");
long end = System.currentTimeMillis();
long elapsed = end - start;
- getLog().debug(N+" ping() invocations = "+elapsed+" ms, "+(elapsed / N)+"
ms/noop");
+ getLog().debug(iterationCount+" ping() invocations = "+elapsed+" ms,
"+(elapsed / iterationCount)+" ms/noop");
}
private void echo(Probe bean) throws Exception
{
- getLog().debug("Starting "+N+" echo(ECHO) invocations");
+ getLog().debug("Starting "+iterationCount+" echo(ECHO) invocations");
long start = System.currentTimeMillis();
- for(int n = 0; n < N; n ++)
+ for(int n = 0; n < iterationCount; n ++)
{
String echo = bean.echo("ECHO");
}
long end = System.currentTimeMillis();
long elapsed = end - start;
- getLog().debug(N+" echo() invocations = "+elapsed+" ms, "+(elapsed / N)+"
ms/noop");
+ getLog().debug(iterationCount+" echo() invocations = "+elapsed+" ms,
"+(elapsed / iterationCount)+" ms/noop");
}
private void txRequired(TxSession bean) throws Exception
{
- getLog().debug("Starting "+N+" txRequired() invocations");
+ getLog().debug("Starting "+iterationCount+" txRequired() invocations");
long start = System.currentTimeMillis();
- for(int n = 0; n < N; n ++)
+ for(int n = 0; n < iterationCount; n ++)
{
String echo = bean.txRequired();
}
long end = System.currentTimeMillis();
long elapsed = end - start;
- getLog().debug(N+" txRequired() invocations = "+elapsed+" ms, "+(elapsed /
N)+" ms/txRequired");
+ getLog().debug(iterationCount+" txRequired() invocations = "+elapsed+" ms,
"+(elapsed / iterationCount)+" ms/txRequired");
}
private void txRequiresNew(TxSession bean) throws Exception
{
- getLog().debug("Starting "+N+" txRequired() invocations");
+ getLog().debug("Starting "+iterationCount+" txRequired() invocations");
long start = System.currentTimeMillis();
- for(int n = 0; n < N; n ++)
+ for(int n = 0; n < iterationCount; n ++)
{
String echo = bean.txRequiresNew();
}
long end = System
[JBoss-dev] [ jboss-Change Notes-462964 ] Stress tests use counts from build.xml
Change Notes item #462964, was opened at 2001-09-19 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=462964&group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: Stress tests use counts from build.xml Initial Comment: I've changed the stress tests to use threadcount, iterationcount, and beancount from the build.xml files. You can set these in a local.properties file like this: ### Test properties junit.timeout=12 jbosstest.threadcount=2 jbosstest.iterationcount=2 jbosstest.beancount=2 You may want to use such small values until the tests all work with these small values. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=462964&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test JBossTestCase.java JBossTestServices.java JBossTestSetup.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test JBossTestCase.java
JBossTestServices.java JBossTestSetup.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.5 +18 -2 jbosstest/src/main/org/jboss/test/JBossTestCase.java
Index: JBossTestCase.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/JBossTestCase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JBossTestCase.java2001/09/18 22:00:42 1.4
+++ JBossTestCase.java2001/09/19 19:16:53 1.5
@@ -42,7 +42,7 @@
* ../lib).
*
* @authorDavid Jencks
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class JBossTestCase
extends TestCase
@@ -51,7 +51,6 @@
private JBossTestServices delegate;
-
// Static
// Constructors --
/**
@@ -277,6 +276,23 @@
suite.addTest(new TestSuite(clazz));
return getJ2eeSetup(suite, jarName);
}
+
+ protected int getThreadCount()
+ {
+ return delegate.getThreadCount();
+ }
+
+ protected int getIterationCount()
+ {
+ return delegate.getIterationCount();
+ }
+
+ protected int getBeanCount()
+ {
+ return delegate.getBeanCount();
+ }
+
+
//private methods--
1.4 +23 -1 jbosstest/src/main/org/jboss/test/JBossTestServices.java
Index: JBossTestServices.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/JBossTestServices.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JBossTestServices.java2001/09/18 22:00:42 1.3
+++ JBossTestServices.java2001/09/19 19:16:53 1.4
@@ -41,7 +41,7 @@
* ../lib).
*
* @authorDavid Jencks
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class JBossTestServices
{
@@ -50,6 +50,10 @@
private final static String serviceDeployerName =
"JBOSS-SYSTEM:service=ServiceDeployer";
private final static String j2eeDeployerName = "J2EE:service=J2eeDeployer";
+ private final static int DEFAULT_THREADCOUNT = 10;
+ private final static int DEFAULT_ITERATIONCOUNT = 1000;
+ private final static int DEFAULT_BEANCOUNT = 100;
+
// Attributes
private RMIConnector server;
private Category log;
@@ -326,6 +330,24 @@
Object[] params = {"other"};
String[] signature = {"java.lang.String"};
invoke(jaasMgr, "flushAuthenticationCache", params, signature);
+ }
+
+ int getThreadCount()
+ {
+ log.info("jbosstest.threadcount: " +
System.getProperty("jbosstest.threadcount"));
+ return Integer.getInteger("jbosstest.threadcount",
DEFAULT_THREADCOUNT).intValue();
+ }
+
+ int getIterationCount()
+ {
+ log.info("jbosstest.iterationcount: " +
System.getProperty("jbosstest.iterationcount"));
+ return Integer.getInteger("jbosstest.iterationcount",
DEFAULT_ITERATIONCOUNT).intValue();
+ }
+
+ int getBeanCount()
+ {
+ log.info("jbosstest.beancount: " + System.getProperty("jbosstest.beancount"));
+ return Integer.getInteger("jbosstest.beancount",
DEFAULT_BEANCOUNT).intValue();
}
1.3 +17 -1 jbosstest/src/main/org/jboss/test/JBossTestSetup.java
Index: JBossTestSetup.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/JBossTestSetup.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JBossTestSetup.java 2001/09/18 22:00:42 1.2
+++ JBossTestSetup.java 2001/09/19 19:16:53 1.3
@@ -44,7 +44,7 @@
* ../lib).
*
* @authorDavid Jencks
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class JBossTestSetup
extends TestSetup
@@ -246,6 +246,22 @@
protected void flushAuthCache() throws Exception
{
delegate.flushAuthCache();
+ }
+
+
+ protected int getThreadCount()
+ {
+ return delegate.getThreadCount();
+ }
+
+ protected int getIterationCount()
+ {
+ return delegate.getIterationCount();
+ }
+
+ protected int getBeanCount()
+ {
+ return delegate.getBeanCount();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://list
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/bank/test BankStressTestCase.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/bank/test BankStressTestCase.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.4 +20 -20
jbosstest/src/main/org/jboss/test/bank/test/BankStressTestCase.java
Index: BankStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/bank/test/BankStressTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BankStressTestCase.java 2001/09/18 22:00:43 1.3
+++ BankStressTestCase.java 2001/09/19 19:16:54 1.4
@@ -23,7 +23,7 @@
*
* @see
* @author Author: d_jencks among many others
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class BankStressTestCase
extends JBossTestCase
@@ -36,8 +36,6 @@
Exception exc;
// Static
- private static final int THREAD_COUNT = 10;
- private static final int ITERATIONS = 100;
// Constructors --
public BankStressTestCase(String name)
@@ -170,11 +168,12 @@
final Object lock = new Object();
- iter = THREAD_COUNT;
- getLog().info("Start test. "+THREAD_COUNT+ " threads, "+ITERATIONS+"
iterations");
+ iter = getThreadCount();
+ final int iterationCount = getIterationCount();
+ getLog().info("Start test. "+getThreadCount()+ " threads,
"+getIterationCount()+" iterations");
long start = System.currentTimeMillis();
- for (int i = 0; i < THREAD_COUNT; i++)
+ for (int i = 0; i < getThreadCount(); i++)
{
Thread.sleep(50);
new Thread(new Runnable()
@@ -186,7 +185,7 @@
try
{
- for (int j = 0; j < ITERATIONS; j++)
+ for (int j = 0; j < iterationCount; j++)
{
if (exc != null) break;
@@ -226,7 +225,7 @@
getLog().info(from.getPrimaryKey()+":"+from.getBalance());
getLog().info(to.getPrimaryKey()+":"+to.getBalance());
getLog().info("Time:"+(end-start));
- getLog().info("Avg.
time/call(ms):"+((end-start)/(THREAD_COUNT*ITERATIONS*6)));
+ getLog().info("Avg.
time/call(ms):"+((end-start)/(getThreadCount()*getIterationCount()*6)));
}
public void testMultiThread2()
@@ -243,11 +242,12 @@
final Object lock = new Object();
- iter = THREAD_COUNT;
- getLog().info("Start test. "+THREAD_COUNT+ " threads, "+ITERATIONS+"
iterations");
+ iter = getThreadCount();
+ final int iterationCount = getIterationCount();
+ getLog().info("Start test. "+getThreadCount()+ " threads,
"+getIterationCount()+" iterations");
long start = System.currentTimeMillis();
- for (int i = 0; i < THREAD_COUNT; i++)
+ for (int i = 0; i < getThreadCount(); i++)
{
Thread.sleep(500); // Wait between each client
new Thread(new Runnable()
@@ -262,7 +262,7 @@
Account from = teller.createAccount(marc, 50);
Account to = teller.createAccount(rickard, 0);
- for (int j = 0; j < ITERATIONS; j++)
+ for (int j = 0; j < iterationCount; j++)
{
if (exc != null) break;
@@ -299,7 +299,7 @@
long end = System.currentTimeMillis();
getLog().info("Time:"+(end-start));
- getLog().info("Avg.
time/call(ms):"+((end-start)/(THREAD_COUNT*ITERATIONS*6)));
+ getLog().info("Avg.
time/call(ms):"+((end-start)/(getThreadCount()*getIterationCount()*6)));
}
public void testTransaction()
@@ -348,7 +348,7 @@
getLog().debug("Rickard acquired");
getLog().debug("Acquire accounts");
- Account from = teller.getAccount(marc, 50*ITERATIONS);
+ Account from = teller.getAccount(marc, 50*getIterationCount());
Account to = teller.getAccount(rickard, 0);
getLog().debug("Show balance");
@@ -357,11 +357,11 @@
getLog().info("Transfer money");
long start = System.currentTimeMillis();
- teller.transferTest(from, to, 50, ITERATIONS);
+ teller.transferTest(from, to, 50, getIterationCount());
long end = System.currentTimeMillis();
getLog().info("Transfer done");
getLog().info("Total time(ms):"+(end-start));
- getLog().info("Avg. time/call(ms):"+((end-start)/(ITERATIONS*2)));
+ getLog().info("Avg.
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/hello/test HelloTimingStressTestCase.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/hello/test
HelloTimingStressTestCase.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.5 +38 -38
jbosstest/src/main/org/jboss/test/hello/test/HelloTimingStressTestCase.java
Index: HelloTimingStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/hello/test/HelloTimingStressTestCase.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- HelloTimingStressTestCase.java2001/09/18 22:00:43 1.4
+++ HelloTimingStressTestCase.java2001/09/19 19:16:54 1.5
@@ -26,13 +26,13 @@
*
* @see
* @author Author: schaefera
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*/
public class HelloTimingStressTestCase
extends JBossTestCase
{
// Constants -
-private static final int ITERATIONS = 500;
+
// Attributes
// Static
@@ -85,23 +85,23 @@
throws Exception
{
long start = System.currentTimeMillis();
- long start2 = start;
+ long start2 = start;
HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
Hello hello = home.create();
- for (int i = 0 ; i < ITERATIONS; i++)
+ for (int i = 0 ; i < getIterationCount(); i++)
{
- hello.hello("Rickard");
+ hello.hello("Rickard");
- if (i % 100 == 0 && i != 0)
- {
- long end = System.currentTimeMillis();
- getLog().debug("Time/call(ms):"+((end-start2)/100));
- start2 = end;
- }
+ if (i % 100 == 0 && i != 0)
+ {
+long end = System.currentTimeMillis();
+getLog().debug("Time/call(ms):"+((end-start2)/100));
+start2 = end;
+ }
}
long end = System.currentTimeMillis();
- getLog().debug("Avg. time/call(ms):"+((end-start)/ITERATIONS));
+ getLog().debug("Avg. time/call(ms):"+((end-start)/getIterationCount()));
}
/**
@@ -116,19 +116,19 @@
long start2 = start;
HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
Hello hello = home.create();
- for (int i = 0 ; i < ITERATIONS; i++)
+ for (int i = 0 ; i < getIterationCount(); i++)
{
hello.helloHello(hello);
- if (i % 100 == 0 && i != 0)
- {
- long end = System.currentTimeMillis();
- getLog().debug("Time/call(ms):"+((end-start2)/100));
- start2 = end;
- }
+ if (i % 100 == 0 && i != 0)
+ {
+long end = System.currentTimeMillis();
+getLog().debug("Time/call(ms):"+((end-start2)/100));
+start2 = end;
+ }
}
long end = System.currentTimeMillis();
- getLog().debug("Avg. time/call(ms):"+((end-start)/ITERATIONS));
+ getLog().debug("Avg. time/call(ms):"+((end-start)/getIterationCount()));
}
/**
@@ -143,28 +143,28 @@
Hello hello = home.create();
long start = System.currentTimeMillis();
- hello.testSpeed("Rickard", ITERATIONS);
+ hello.testSpeed("Rickard", getIterationCount());
long end = System.currentTimeMillis();
- getLog().debug("Avg. time/call(ms):"+((end-start)/ITERATIONS));
+ getLog().debug("Avg. time/call(ms):"+((end-start)/getIterationCount()));
}
*/
/**
* This tests the speed of InitialContext lookups
-*
+* including getting the initial context.
* @exception Exception
*/
public void testContextSpeed()
throws Exception
{
- long start = System.currentTimeMillis();
+ long start = System.currentTimeMillis();
- getLog().debug("Starting context lookup speed test");
- for (int i = 0; i < ITERATIONS; i++)
- {
-HelloHome home = (HelloHome)getInitialContext().lookup(HelloHome.JNDI_NAME);
-}
+ getLog().debug("Starting context lookup speed test");
+ for (int i = 0; i < getIterationCount(); i++)
+ {
+ HelloHome home = (HelloHome)new
InitialContext().lookup(HelloHome.JNDI_NAME);
+ }
long end =
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/lock/test EnterpriseEntityTest.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/lock/test EnterpriseEntityTest.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.6 +8 -17
jbosstest/src/main/org/jboss/test/lock/test/EnterpriseEntityTest.java
Index: EnterpriseEntityTest.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/lock/test/EnterpriseEntityTest.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EnterpriseEntityTest.java 2001/09/18 22:00:44 1.5
+++ EnterpriseEntityTest.java 2001/09/19 19:16:54 1.6
@@ -144,28 +144,19 @@
*/
protected void setUp() throws Exception
{
- nbThreads = DEFAULT_THREAD_COUNT;
- iterations = DEFAULT_ITERATIONS;
+ nbThreads = getThreadCount();//DEFAULT_THREAD_COUNT;
+ iterations = getIterationCount();//DEFAULT_ITERATIONS;
getLog().debug("+++ Setting up: " + getClass().getName() + " test: " +
getName());
- // get a handle on an entity bean
- Context ctx = new InitialContext();
+ EnterpriseEntityHome home =
+ (EnterpriseEntityHome)getInitialContext().lookup(jndiname);
+
try
{
- EnterpriseEntityHome home =
- (EnterpriseEntityHome)ctx.lookup(jndiname);
-
- try
- {
-entity = home.findByPrimaryKey("seb");
- }
- catch (FinderException e)
- {
-entity = home.create("seb");
- }
+ entity = home.findByPrimaryKey("seb");
}
- finally
+ catch (FinderException e)
{
- ctx.close();
+ entity = home.create("seb");
}
// setup the threads
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cts/test StatelessSessionStressTestCase.java
User: d_jencks
Date: 01/09/19 12:16:54
Modified:src/main/org/jboss/test/cts/test
StatelessSessionStressTestCase.java
Log:
Changed stress tests to have counts set from build.xml. You may set values in a
local.properties file.
Revision ChangesPath
1.4 +7 -13
jbosstest/src/main/org/jboss/test/cts/test/StatelessSessionStressTestCase.java
Index: StatelessSessionStressTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/cts/test/StatelessSessionStressTestCase.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StatelessSessionStressTestCase.java 2001/09/18 22:00:43 1.3
+++ StatelessSessionStressTestCase.java 2001/09/19 19:16:54 1.4
@@ -16,7 +16,6 @@
import javax.management.*;
import org.jboss.test.cts.interfaces.*;
-//import junit.framework.*;
import junit.framework.Test;
import org.jboss.test.JBossTestCase;
@@ -28,7 +27,7 @@
* @see
* @author Author: kimptoc
* @author Author: d_jencks converted to JBossTestCase and logging.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class StatelessSessionStressTestCase
@@ -76,21 +75,16 @@
{
getLog().debug("Callback test");
- StatefulSession sessionBean [] = new StatefulSession [125];
- StatefulSessionHome home = null;
- int i = 0;
+ StatefulSession sessionBean[] = new StatefulSession[getBeanCount()];
+ StatefulSessionHome home = null;
+ int i = 0;
try
{
- Properties props = System.getProperties();
-
getLog().debug("Obtain home interface");
- // Create a new session object
- Context ctx = new InitialContext(props);
-
home =
-( StatefulSessionHome ) ctx.lookup("ejbcts/StatefulSessionBean");
+
(StatefulSessionHome)getInitialContext().lookup("ejbcts/StatefulSessionBean");
}
catch (Exception Ex)
{
@@ -99,7 +93,7 @@
try
{
- for (i = 0; i < 125; i++)
+ for (i = 0; i < getBeanCount(); i++)
{
sessionBean [i] = home.create();
@@ -108,7 +102,7 @@
}
// Kill all the beans
- for (i = 0; i < 125; i++)
+ for (i = 0; i < getBeanCount(); i++)
sessionBean [i].remove();
}
catch (Exception ex)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MDB non-xa cf & tx timeout
Just a note, but it looks like there is still a problem with MDB tx timeouts with a non-xa connection factory. I mentioned this problem a while ago, then the world fell apart, then my computers freaked out and then I got ill. Now, I have recomved from 2 of the 3 and am looking into this problem some more. I am currently using a 2.5 snapshot, so I might move over to 2.4.x. It does have the new locking and jbossmq stuff right? Anyways, I think there is still an issue with the tx recipts for an MDB. I have to set the default tx timeout insainly high to avoid this problem. I remember there were a few suggestions on how to fix this, but I am not sure what happend to them... --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
Correct. - Original Message - From: "Hunter Hillegas" <[EMAIL PROTECTED]> To: "JBoss Dev" <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 11:34 AM Subject: Re: [JBoss-dev] Optimized EJB calls in catalina > So all you have to do is not include the EJB interfaces in your WAR? > > > From: "Scott M Stark" <[EMAIL PROTECTED]> > > Organization: JBoss Group > > Reply-To: [EMAIL PROTECTED] > > Date: Wed, 19 Sep 2001 11:25:41 -0700 > > To: <[EMAIL PROTECTED]> > > Subject: Re: [JBoss-dev] Optimized EJB calls in catalina > > > > On the plus side, if you remove the EJB interfaces from WEB-INF/classes > > that were required to compile JSP pages, the pages do compile and > > calls are optimized. Apparently the jasper integration in catalina will use > > the context class loader for compilation. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs basicconfiguration.xml
User: gropi Date: 01/09/19 11:38:23 Modified:src/xdocs basicconfiguration.xml Log: Revised version by Fernando Garcia-Loygorri. Revision ChangesPath 1.2 +703 -307 manual/src/xdocs/basicconfiguration.xml Index: basicconfiguration.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/basicconfiguration.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- basicconfiguration.xml2001/08/29 09:19:36 1.1 +++ basicconfiguration.xml2001/09/19 18:38:22 1.2 @@ -1,321 +1,717 @@ + + + - Configuration - Authors: + +Configuration + +Authors: + + + + + Scott + Stark + + + [EMAIL PROTECTED] + + + + + + + Vladimir + Blagojevic + + + [EMAIL PROTECTED] + + + + + + Introduction + - - Scott - Stark - - [EMAIL PROTECTED] + JBoss ships preconfigured, so there's nothing you need to do to get + it up and running. However, you will likely need to make minor + configuration changes to support your specific applications and + environment. + - - Vladimir - Blagojevic - - [EMAIL PROTECTED] + The following section gives you an overview of the directory + structure of a standard JBoss installation. The next section + briefly describes all of the various configuration files present + in the conf directory. - - Introduction - JBoss ships preconfigured, so there's nothing you need to do to get it up - and running. However, you will likely need to make minor configuration -changes to support your specific applications. This section gives an -overview of the configuration files and directories. The Advanced - Configuration section gives detailed instructions for -specific configuration changes you may require. - - - - - Directory structure - All directories referred to in the next section are - relative to - directories are the following: - - - - - bin - All the binaries included with JBoss distribution are located in this - directory. Using the Batch (Windows) or Shell (UNIX) - scripts here, you can start the server. You can also run the EJX - deployment descriptor editor by double-clicking on it - (if your platform supports that) or issuing the command: java -jar ejx.jar - - - lib and lib/ext - The two directories contain java libraries in jar and zip format that - JBoss uses. There is a split between - those libraries which had to be in the system classpath (.ie jars in lib - directory) vs the other ones in lib/ext - directory that are made available to the JBoss server MLet based - classloader. - - If there is a need to add some java libraries to JBoss, for example jdbc - driver jars, these should be dropped in lib/ext - directory and will be picked up by JBoss automatically. - - - db - Directory containing hypersonic and instantdb databases related files - (configuration files, indexing tables etc ) as well - as JBossMQ - JMS provider message queue files. - - - deploy - This is JBoss's deployment directory. Just drop your jars here and - they will be deployed automatically. - - - log
RE: [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session Beans?
Hey Sacha, Can you make this configurable in AbstractInstancePool? I set up a flag to enable entity pooling, but I didn't look at the implementation of AbstractInstancePool to find out that pooling has been turned off totally. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Sacha > Labourey > Sent: Wednesday, September 19, 2001 1:15 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless > Session Beans? > > > I can take a look at it tomorrow (except if someone wants to correct this > before) > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Scott M Stark > > Envoyé : mercredi, 19 septembre 2001 19:15 > > À : [EMAIL PROTECTED] > > Objet : [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session > > Beans? > > > > > > We should restore pooling of stateless session beans and message driven > > beans. If such beans perform any non-trivial initialization > > during ejbCreate > > for use across stateless methods we are killing the performance > > of the bean > > and wasting these resources. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Jim, I'm in total agreement here. Serialized access is really only good for synchronized caching. Yes, for commit option 'B' and 'C' there is a way to duplicate instances of entity beans. Unfortunately, this code has a major bug in it so you would have to go to CVS and get latest from Branch_2_4. How to enable it? 1. In standardjboss.xml(or your own container-configuration), change to B or C. 2. Also change the from QueuedPessimisticEJBLock to MethodOnlyEJBLock. 3. Also change EntityInstanceInterceptor to EntityMultiInstanceInterceptor. 4. Also change EntitySynchronizationInterceptor to EntityMultiInstanceSynchronizationInterceptor. I'm sorry that this is not documented. Also, unfortunately, this stuff will not work with commit-option 'A' since no caching is done. This can be improved later. Regards, Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of James > Cook > Sent: Wednesday, September 19, 2001 1:31 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > Bill, > > Since there is little documentation regarding locking, can you clear up a > question? > > Don't take this as a slam. All of the major commercial vendors have > discovered that it is problematic to perform serialization of > client access > to EJB's in the container. [We can expound upon this, if you feel this is > not the case]. WebLogic was the last holdout and since 6.1, they too, have > removed serialized access from their container. > > Does jBoss currently support (in 2.4.1) the opportunity to duplicate > instances of entity beans in the container? If so, how do I enable it, and > do we run tests against the server in this mode? Also, if so, > shouldn't this > be enabled as the default...taking the queue from every other app server > vendor? > > thanks, > jim > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
On Wed, Sep 19, 2001 at 06:22:18PM +0100, Ignacio Coloma wrote: > Hi, I am not sure, but looking in the EJB spec (draft version), for two > times it specifically forbid the optimized EJB calls made in JBoss. Citing > the draft: > You can turn the optimization off. Most container vendors implement this optimization. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
Yes, and you can turn off optimization if you want. Call the JBoss optmization automatic local interfaces and were ahead of the 2.0 curve. - Original Message - From: "Ignacio Coloma" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 10:22 AM Subject: RE: [JBoss-dev] Optimized EJB calls in catalina > Hi, I am not sure, but looking in the EJB spec (draft version), for two > times it specifically forbid the optimized EJB calls made in JBoss. Citing > the draft: > > > The enterprise bean's remote home and remote interfaces are remote > interfaces in the Java RMI sense. > The Container must ensure the Java RMI argument passing semantics. > Non-remote objects must be > passed by value across these interfaces. > > Specifically, the EJB Container is not allowed to pass objects by reference > on inter-enterprise bean invocations > of methods on the enterprise bean's remote home and remote interface when > the calling and > called enterprise beans are collocated in the same JVM. Doing so could > result in the multiple beans > sharing the state of a Java object, which would break the enterprise bean's > semantics. > > EJB 2.0 entity beans and session beans support local and local home > interfaces. The arguments of the > methods of these interfaces are passed by reference, and the local clients > of such beans must be collocated > in the same JVM. Such beans must be coded to assume that the state of any > Java object that is > passed as an argument or result is shared by caller and callee. > > > > > -Mensaje original- > > De: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]En nombre de Scott > > M Stark > > Enviado el: miércoles, 19 de septiembre de 2001 1:29 > > Para: [EMAIL PROTECTED] > > Asunto: [JBoss-dev] Optimized EJB calls in catalina > > > > > > I looked at integrating the catalina final release with integrated > > security and JNDI and I find that everything works except for optimized > > EJB calls. This occurs for wars that include the EJB interfaces in their > > classes directory. This has been required for wars with JSP pages that > > access EJBs. I have not tested the catalina version of jasper to see if > > this is still required. > > > > The reason EJB calls are not optimized for this scenario is that the > > web container class loader loads classes in WEB-INF/classes before > > asking its parent class loader. This seems to be consistent with the > > 2.3 servlet spec if "container-wide library JARs" is taken to mean > > jars accessible by the container parent class loaders. > > > > If the EJB interfaces are not in the war then call optimization works as > > before. > > > > > > SRV.9.7.2 Web Application Classloader > > > > The classloader that a container uses to load a servlet in a WAR > > must allow > > the > > > > developer to load any resources contained in library JARs within the WAR > > > > following normal J2SE semantics using getResource. It must not > > allow theWAR > > to > > > > override J2SE or Java servlet API classes. It is further recommended that > > the loader > > > > not allow servlets in theWAR access to the web container's implementation > > classes. > > > > It is recommended also that the application class loader be implemented so > > > > that classes and resources packaged within the WAR are loaded in > > preference > > to > > > > classes and resources residing in container-wide library JARs. > > > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/connector/ejb EJBConnector.java
User: schaefera
Date: 01/09/19 10:55:05
Modified:src/main/org/jboss/jmx/connector/ejb EJBConnector.java
Log:
Some small fixes.
Revision ChangesPath
1.4 +24 -13jboss/src/main/org/jboss/jmx/connector/ejb/EJBConnector.java
Index: EJBConnector.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/connector/ejb/EJBConnector.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- EJBConnector.java 2001/09/15 03:06:49 1.3
+++ EJBConnector.java 2001/09/19 17:55:05 1.4
@@ -85,7 +85,7 @@
* and the EJB-Adaptor (meaning the EJB-Container).
*
* @author Andreas Schaefer ([EMAIL PROTECTED])
-* @version $Revision: 1.3 $
+* @version $Revision: 1.4 $
**/
public class EJBConnector
implements JMXConnector, EJBConnectorMBean
@@ -225,6 +225,8 @@
{
try {
Context lJNDIContext = null;
+ // The Adaptor can be registered on another JNDI-Server therefore
+ // the user can overwrite the Provider URL
if( mJNDIServer != null ) {
Hashtable lProperties = new Hashtable();
lProperties.put( Context.PROVIDER_URL, mJNDIServer );
@@ -232,9 +234,6 @@
} else {
lJNDIContext = new InitialContext();
}
- System.out.println( "JNDI Context properties: " +
lJNDIContext.getEnvironment() +
-", JNDI name: " + pJNDIName
- );
Object aEJBRef = lJNDIContext.lookup( pJNDIName );
AdaptorHome aHome = (AdaptorHome)
PortableRemoteObject.narrow( aEJBRef, AdaptorHome.class );
@@ -652,19 +651,24 @@
// NotificationListener directly a MBean must be loaded
// and then added as new listener
try {
+ // Create the remote Notification listener (from server view: sender)
Listener lRemoteListener = new Listener(
pListener,
pHandback,
pName
);
+ // Export the RMI object to become a callback object
UnicastRemoteObject.exportObject( lRemoteListener );
+ // Register the listener as MBean on the remote JMX server
ObjectName lName = createMBean(
"org.jboss.jmx.connector.notification.RMINotificationListener",
new ObjectName( "EJBAdaptor:id=" + lRemoteListener.getId() ),
new Object[] { lRemoteListener },
new String[] { RMINotificationSender.class.getName() }
).getObjectName();
+ // Add this MBean now as listener on the server
mAdaptor.addNotificationListener( pName, lName, pFilter,
lRemoteListener.getHandback() );
+ // Add this listener on the client to remove it when the client goes
down
mListeners.addElement( lRemoteListener );
}
catch( Exception e ) {
@@ -679,14 +683,20 @@
break;
case NOTIFICATION_TYPE_JMS:
try {
- // Get the JMX QueueConnectionFactory from the J2EE server
+ // Get the JMS QueueConnectionFactory from the J2EE server
QueueConnection lConnection = getQueueConnection( mOptions[ 0 ] );
+ // Create JMS Session and create temporary Queue
QueueSession lSession = lConnection.createQueueSession( false,
Session.AUTO_ACKNOWLEDGE );
Queue lQueue = lSession.createTemporaryQueue();
+ // Create "remote" listener and register on the JMX server through
the adaptor
JMSNotificationListener lRemoteListener = new
JMSNotificationListener( mOptions[ 0 ], lQueue );
mAdaptor.addNotificationListener( pName, lRemoteListener, pFilter,
null );
+ // Create JMS message receiver, create local message listener and
set it as message
+ // listener to the receiver
QueueReceiver lReceiver = lSession.createReceiver( lQueue, null );
lReceiver.setMessageListener( new JMSClientNotificationListener(
pListener, pHandback ) );
+ // Add the listener as registered listener to enable the connector
to remove it
+ // when going down or the client request to remove it
mListeners.addElement( new JMSListenerSet( pName, pListener,
lRemoteListener ) );
}
catch( Exception e ) {
@@ -936,16 +946,18 @@
}
/**
- * Listener wrapper around the remote RMI Notification Listener
+ * RMI Sender Instance working as listener to retrieve the
+ * notifications from the remote server and handing over to
+ * the clients listener.
+ *
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/adaptor/ejb EJBAdaptorBean.java
User: schaefera
Date: 01/09/19 10:55:05
Modified:src/main/org/jboss/jmx/adaptor/ejb EJBAdaptorBean.java
Log:
Some small fixes.
Revision ChangesPath
1.3 +24 -17jboss/src/main/org/jboss/jmx/adaptor/ejb/EJBAdaptorBean.java
Index: EJBAdaptorBean.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/adaptor/ejb/EJBAdaptorBean.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EJBAdaptorBean.java 2001/09/13 07:38:15 1.2
+++ EJBAdaptorBean.java 2001/09/19 17:55:04 1.3
@@ -1,11 +1,9 @@
-//
-// File: EJBAdaptorBean.java
-// Copyright ( c ) 2001 JBoss Group. All rights reserved.
-// Version: $Revision: 1.2 $
-// Last Checked In: $Date: 2001/09/13 07:38:15 $
-// Last Checked In By: $Author: schaefera $
-//
-
+/*
+* JBoss, the OpenSource J2EE webOS
+*
+* Distributable under LGPL license.
+* See terms of license at gnu.org.
+*/
package org.jboss.jmx.adaptor.ejb;
import java.util.ArrayList;
@@ -21,7 +19,6 @@
import javax.ejb.RemoveException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
-// import javax.management.;
import javax.management.Attribute;
import javax.management.AttributeList;
import javax.management.AttributeNotFoundException;
@@ -53,7 +50,7 @@
* MBean Server.
*
* @author Andreas Schaefer
-* @version $Revision: 1.2 $
+* @version $Revision: 1.3 $
*
* @ejb:ejb-name jmx/ejb/Adaptor
* @ejb:stateless-session
@@ -118,6 +115,20 @@
}
/**
+ * Instantiate the given class on the remote MBeanServer and returns a Object
+ * Handler you can use to register it as a MBean with {@link #registerMBean
+ * registerMBean()} or as a parameter to createMBean() or instantiate()
+ * method which takes it as a parameter.
+ *
+ * @param pClassName Class name of the class to be loaded and instantiated
+ * @param pLoaderName Name of the classloader to be used to
+ *load this class
+ *
+ * @return Object handler. Please use this handler to register it as MBean
+ * or as a parameter in the other methods as a parameter. The
+ * server-side connector will look up for an object handler parameter
+ * and then replace the object handler by the effective object.
+ *
* @ejb:remote-method
**/
public ObjectHandler instantiate(
@@ -178,6 +189,8 @@
pParams,
pSignature
);
+ // Instantiate the Object on the Server and then create and return the
+ // remote reference
return assignObjectHandler(
mServer.instantiate(
pClassName,
@@ -420,12 +433,8 @@
NotCompliantMBeanException,
RemoteException
{
- if( !( pObjectHandler instanceof ObjectHandler ) ) {
- throw new IllegalArgumentException(
-"You can only register local objects referenced by ObjectHandler"
- );
- }
return mServer.registerMBean(
+ // Replace the Remote Reference by the actual object
checkForObjectHandler( pObjectHandler ),
pNameToAssign
);
@@ -814,8 +823,6 @@
InstanceNotFoundException,
RemoteException
{
- System.out.println( "EJBAdaptorBean.addNotificationListener(), name: " +
pName.getCanonicalName() +
- ", listener: " + pListener.getCanonicalName() );
mServer.addNotificationListener( pName, pListener, pFilter, pHandback );
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jmx/connector/notification JMSClientNotificationListener.java JMSNotificationListener.java RMINotificationListener.java
User: schaefera
Date: 01/09/19 10:55:05
Modified:src/main/org/jboss/jmx/connector/notification
JMSClientNotificationListener.java
JMSNotificationListener.java
RMINotificationListener.java
Log:
Some small fixes.
Revision ChangesPath
1.2 +3 -10
jboss/src/main/org/jboss/jmx/connector/notification/JMSClientNotificationListener.java
Index: JMSClientNotificationListener.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/connector/notification/JMSClientNotificationListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JMSClientNotificationListener.java2001/09/15 03:06:50 1.1
+++ JMSClientNotificationListener.java2001/09/19 17:55:05 1.2
@@ -12,21 +12,12 @@
import javax.jms.Message;
import javax.jms.MessageListener;
import javax.jms.ObjectMessage;
-/*
-import javax.jms.Queue;
-import javax.jms.QueueConnection;
-import javax.jms.QueueConnectionFactory;
-import javax.jms.QueueReceiver;
-import javax.jms.QueueSender;
-import javax.jms.QueueSession;
-import javax.jms.Session;
-*/
import javax.management.Notification;
import javax.management.NotificationListener;
/**
-* Local JMX Listener to receive the message and send to the listener
+* Local JMS Listener to receive the message and send to the listener
**/
public class JMSClientNotificationListener implements MessageListener {
@@ -43,6 +34,8 @@
public void onMessage( Message pMessage ) {
try {
+ // Unpack the Notification from the Message and hand it over to the clients
+ // Notification Listener
Notification lNotification = (Notification) ( (ObjectMessage) pMessage
).getObject();
mLocalListener.handleNotification( lNotification, mHandback );
}
1.2 +3 -0
jboss/src/main/org/jboss/jmx/connector/notification/JMSNotificationListener.java
Index: JMSNotificationListener.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/connector/notification/JMSNotificationListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- JMSNotificationListener.java 2001/09/12 01:49:07 1.1
+++ JMSNotificationListener.java 2001/09/19 17:55:05 1.2
@@ -35,6 +35,9 @@
implements NotificationListener, Serializable
{
+ // JMS Queue Session and Sender must be created on the server-side
+ // therefore they are transient and created on the first notification
+ // call
private transient QueueSender mSender;
private transient QueueSession mSession;
private String mJNDIName;
1.2 +25 -4
jboss/src/main/org/jboss/jmx/connector/notification/RMINotificationListener.java
Index: RMINotificationListener.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/jmx/connector/notification/RMINotificationListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RMINotificationListener.java 2001/09/12 01:49:07 1.1
+++ RMINotificationListener.java 2001/09/19 17:55:05 1.2
@@ -42,8 +42,6 @@
*
* @param pNotificationSender The Notification Sender using RMI to
*transport
-*
-* @
**/
public RMINotificationListener( RMINotificationSender pNotificationSender ) {
mRemoteSender = pNotificationSender;
@@ -59,8 +57,6 @@
*
* @param pNotification NotificationEvent
* @param pHandback Handback object
- *
- * @throws RemoteException If a Remote Exception occurred
*/
public void handleNotification(
Notification pNotification,
@@ -72,5 +68,30 @@
catch( RemoteException re ) {
re.printStackTrace();
}
+ }
+
+ /**
+ * Test if this and the given Object are equal. This is true if the given
+ * object both refer to the same local listener
+ *
+ * @param pTestOther object to test
if equal
+ *
+ * @return True if both are of
same type and
+ * refer to the
same local listener
+ **/
+ public boolean equals( Object pTest ) {
+ if( pTest instanceof RMINotificationListener ) {
+ return mRemoteSender.equals(
+( (RMINotificationListener) pTest).mRemoteSender
+ );
+ }
+ return false;
[JBoss-dev] Anyone has tried to make a non-hypersonic connection pool?
Anyone has the xxx-service.xml for a database that is not enhydra? I have coded one, but doesn't work. It could be a bug but since I'm not 100% sure of the config parameters I don't dare to post it as a bug yet. > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En nombre de Sacha > Labourey > Enviado el: miércoles, 19 de septiembre de 2001 18:15 > Para: [EMAIL PROTECTED] > Asunto: RE: [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless > Session Beans? > > > I can take a look at it tomorrow (except if someone wants to correct this > before) > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Scott M Stark > > Envoyé : mercredi, 19 septembre 2001 19:15 > > À : [EMAIL PROTECTED] > > Objet : [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session > > Beans? > > > > > > We should restore pooling of stateless session beans and message driven > > beans. If such beans perform any non-trivial initialization > > during ejbCreate > > for use across stateless methods we are killing the performance > > of the bean > > and wasting these resources. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Optimized EJB calls in catalina
Hi, I am not sure, but looking in the EJB spec (draft version), for two times it specifically forbid the optimized EJB calls made in JBoss. Citing the draft: The enterprise beans remote home and remote interfaces are remote interfaces in the Java RMI sense. The Container must ensure the Java RMI argument passing semantics. Non-remote objects must be passed by value across these interfaces. Specifically, the EJB Container is not allowed to pass objects by reference on inter-enterprise bean invocations of methods on the enterprise beans remote home and remote interface when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise beans semantics. EJB 2.0 entity beans and session beans support local and local home interfaces. The arguments of the methods of these interfaces are passed by reference, and the local clients of such beans must be collocated in the same JVM. Such beans must be coded to assume that the state of any Java object that is passed as an argument or result is shared by caller and callee. > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En nombre de Scott > M Stark > Enviado el: miércoles, 19 de septiembre de 2001 1:29 > Para: [EMAIL PROTECTED] > Asunto: [JBoss-dev] Optimized EJB calls in catalina > > > I looked at integrating the catalina final release with integrated > security and JNDI and I find that everything works except for optimized > EJB calls. This occurs for wars that include the EJB interfaces in their > classes directory. This has been required for wars with JSP pages that > access EJBs. I have not tested the catalina version of jasper to see if > this is still required. > > The reason EJB calls are not optimized for this scenario is that the > web container class loader loads classes in WEB-INF/classes before > asking its parent class loader. This seems to be consistent with the > 2.3 servlet spec if "container-wide library JARs" is taken to mean > jars accessible by the container parent class loaders. > > If the EJB interfaces are not in the war then call optimization works as > before. > > > SRV.9.7.2 Web Application Classloader > > The classloader that a container uses to load a servlet in a WAR > must allow > the > > developer to load any resources contained in library JARs within the WAR > > following normal J2SE semantics using getResource. It must not > allow theWAR > to > > override J2SE or Java servlet API classes. It is further recommended that > the loader > > not allow servlets in theWAR access to the web container's implementation > classes. > > It is recommended also that the application class loader be implemented so > > that classes and resources packaged within the WAR are loaded in > preference > to > > classes and resources residing in container-wide library JARs. > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
No, I'm using the EmbeddedCatalinaSX service that I am writing. The issue is that the catlina WebappClassLoader will preferentially load classes from its WEB-INF/classes directory before asking its parent class loader to load the class. Because of this the test in JRMPContainerInvoker regarding assignability of the EJB home or remote interface classes fails and the call cannot be optimized. - Original Message - From: "Rickard Öberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 10:08 AM Subject: Re: [JBoss-dev] Optimized EJB calls in catalina > Scott M Stark wrote: > > I looked at integrating the catalina final release with integrated > > security and JNDI and I find that everything works except for optimized > > EJB calls. > > Did you use the updated Catalina support that I've added? > > /Rickard > > -- > Rickard Öberg > Software Development Specialist > xlurc - Xpedio Linköping Ubiquitous Research Center > Author of "Mastering RMI" > Email: [EMAIL PROTECTED] > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Bill, Since there is little documentation regarding locking, can you clear up a question? Don't take this as a slam. All of the major commercial vendors have discovered that it is problematic to perform serialization of client access to EJB's in the container. [We can expound upon this, if you feel this is not the case]. WebLogic was the last holdout and since 6.1, they too, have removed serialized access from their container. Does jBoss currently support (in 2.4.1) the opportunity to duplicate instances of entity beans in the container? If so, how do I enable it, and do we run tests against the server in this mode? Also, if so, shouldn't this be enabled as the default...taking the queue from every other app server vendor? thanks, jim ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
In the new locking code, how can one see when a LOCKING-WAITING type of situation occurs? I like to run our system through a stress test every now and again and see which beans are being regularly blocked on. In 2.4.0 I would set the loglevel to DEBUG in log4j and then I could see the LOCKING-WAITING messages on the PK objects. How can I get the system to print a similar message in 2.4.1 for debug purposes? Thanks, Todd On Wed, 19 Sep 2001, Todd Huss wrote: > Thanks Bill, your PLEASE NOTE was indeed my problem. During the upgrade I > didn't replace my standardjboss.xml so the Lock interceptor was > missing which was affecting my BMP entity beans. > > Is the best way to upgrade right now to simply replace my custom conf > directory with the one from default and reedit all the files? > > Thanks, > Todd > > On Wed, 19 Sep 2001, Bill Burke wrote: > > > Todd, > > > > I cannot reproduce this problem. You're going to have to give me a test > > case before I believe you. Also, do you use standardjboss.xml to create > > your Entity Bean configuration? Or do you make your own. If you use > > standardjboss.xml, please attach this to your next reply. > > > > PLEASE NOTE! > > > > There has been an extra interceptor added to the interceptor chain in 2.4.1. > > Please look in the distributed standardjboss.xml that comes with 2.4.1. > > EntityLockInterceptor should be in the interceptor chain, and also a new > > field should be set to QueuedPessmisticEJBLock. > > > > i.e. > > > > > > Standard CMP EntityBean > > false > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker > ontainer-invoker> > > > > > > org.jboss.ejb.plugins.LogInterceptor > > > > org.jboss.ejb.plugins.SecurityInterceptor > > > > org.jboss.ejb.plugins.TxInterceptorCMT > > > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor > > > > org.jboss.ejb.plugins.EntityLockInterceptor > > > > org.jboss.ejb.plugins.EntityInstanceInterceptor > > > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor > ptor> > > > > >org.jboss.ejb.plugins.EntityInstancePool > > > > org.jboss.ejb.plugins.EntityInstanceCache > > > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager > istence-manager> > > >org.jboss.tm.TxManager > > > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > -policy> > > > > > > True > > > > > > > > org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy > olicy> > > > > 50 > > 1000 > > 300 > > 600 > > 400 > > >60 > > >1 > > 0.75 > > > > > > > > 100 > > 10 > > > > A > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > > > Huss > > > Sent: Tuesday, September 18, 2001 8:16 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > > > > > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > > > locking code has changed. I have an entity bean with all methods having > > > the transaction attribute set to "RequiresNew" and works great under JBoss > > > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > > > condition errors in this particular entity bean. > > > > > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > > > calls on the same bean where one of the calls should block until the other > > > one completes (and it does in 2.4.0). I was able to reproduce the race > > > condition and then downgrade to 2.4.0 and everything worked great again > > > with one of the method calls blocking as expected, then upgrading back to > > > 2.4.1 one more time showed the race condition again. > > > > > > Lastly, is there a bugzilla or something similar for JBoss where I can > > > submit bug reports, or is this the best place to do it? > > > > > > Thanks, > > > Todd > > > > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
In the new locking code, how can one see when a LOCKING-WAITING type of situation occurs? I like to run our system through a stress test every now and again and see which beans are being regularly blocked on. In 2.4.0 I would set the loglevel to DEBUG in log4j and then I could see the LOCKING-WAITING messages on the PK objects. How can I get the system to print a similar message in 2.4.1 for debug purposes? Thanks, Todd On Wed, 19 Sep 2001, Todd Huss wrote: > Thanks Bill, your PLEASE NOTE was indeed my problem. During the upgrade I > didn't replace my standardjboss.xml so the Lock interceptor was > missing which was affecting my BMP entity beans. > > Is the best way to upgrade right now to simply replace my custom conf > directory with the one from default and reedit all the files? > > Thanks, > Todd > > On Wed, 19 Sep 2001, Bill Burke wrote: > > > Todd, > > > > I cannot reproduce this problem. You're going to have to give me a test > > case before I believe you. Also, do you use standardjboss.xml to create > > your Entity Bean configuration? Or do you make your own. If you use > > standardjboss.xml, please attach this to your next reply. > > > > PLEASE NOTE! > > > > There has been an extra interceptor added to the interceptor chain in 2.4.1. > > Please look in the distributed standardjboss.xml that comes with 2.4.1. > > EntityLockInterceptor should be in the interceptor chain, and also a new > > field should be set to QueuedPessmisticEJBLock. > > > > i.e. > > > > > > Standard CMP EntityBean > > false > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker > ontainer-invoker> > > > > > > org.jboss.ejb.plugins.LogInterceptor > > > > org.jboss.ejb.plugins.SecurityInterceptor > > > > org.jboss.ejb.plugins.TxInterceptorCMT > > > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor > > > > org.jboss.ejb.plugins.EntityLockInterceptor > > > > org.jboss.ejb.plugins.EntityInstanceInterceptor > > > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor > ptor> > > > > >org.jboss.ejb.plugins.EntityInstancePool > > > > org.jboss.ejb.plugins.EntityInstanceCache > > > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager > istence-manager> > > >org.jboss.tm.TxManager > > > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > -policy> > > > > > > True > > > > > > > > org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy > olicy> > > > > 50 > > 1000 > > 300 > > 600 > > 400 > > >60 > > >1 > > 0.75 > > > > > > > > 100 > > 10 > > > > A > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > > > Huss > > > Sent: Tuesday, September 18, 2001 8:16 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > > > > > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > > > locking code has changed. I have an entity bean with all methods having > > > the transaction attribute set to "RequiresNew" and works great under JBoss > > > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > > > condition errors in this particular entity bean. > > > > > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > > > calls on the same bean where one of the calls should block until the other > > > one completes (and it does in 2.4.0). I was able to reproduce the race > > > condition and then downgrade to 2.4.0 and everything worked great again > > > with one of the method calls blocking as expected, then upgrading back to > > > 2.4.1 one more time showed the race condition again. > > > > > > Lastly, is there a bugzilla or something similar for JBoss where I can > > > submit bug reports, or is this the best place to do it? > > > > > > Thanks, > > > Todd > > > > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session Beans?
I can take a look at it tomorrow (except if someone wants to correct this before) > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Scott M Stark > Envoyé : mercredi, 19 septembre 2001 19:15 > À : [EMAIL PROTECTED] > Objet : [JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session > Beans? > > > We should restore pooling of stateless session beans and message driven > beans. If such beans perform any non-trivial initialization > during ejbCreate > for use across stateless methods we are killing the performance > of the bean > and wasting these resources. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Yes as the standardjboss.xml descriptor HAS to be correct as this defines every EJB containers behavior. - Original Message - From: "Todd Huss" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Bill Burke" <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 9:47 AM Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > Thanks Bill, your PLEASE NOTE was indeed my problem. During the upgrade I > didn't replace my standardjboss.xml so the Lock interceptor was > missing which was affecting my BMP entity beans. > > Is the best way to upgrade right now to simply replace my custom conf > directory with the one from default and reedit all the files? > > Thanks, > Todd > > On Wed, 19 Sep 2001, Bill Burke wrote: > > > Todd, > > > > I cannot reproduce this problem. You're going to have to give me a test > > case before I believe you. Also, do you use standardjboss.xml to create > > your Entity Bean configuration? Or do you make your own. If you use > > standardjboss.xml, please attach this to your next reply. > > > > PLEASE NOTE! > > > > There has been an extra interceptor added to the interceptor chain in 2.4.1. > > Please look in the distributed standardjboss.xml that comes with 2.4.1. > > EntityLockInterceptor should be in the interceptor chain, and also a new > > field should be set to QueuedPessmisticEJBLock. > > > > i.e. > > > > > > Standard CMP EntityBean > > false > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker > ontainer-invoker> > > > > > > org.jboss.ejb.plugins.LogInterceptor > > > > org.jboss.ejb.plugins.SecurityInterceptor > > > > org.jboss.ejb.plugins.TxInterceptorCMT > > > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor > > > > org.jboss.ejb.plugins.EntityLockInterceptor > > > > org.jboss.ejb.plugins.EntityInstanceInterceptor > > > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor > ptor> > > > > org.jboss.ejb.plugins.EntityInstancePool > > > > org.jboss.ejb.plugins.EntityInstanceCache > > > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager > istence-manager> > > org.jboss.tm.TxManager > > > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock > -policy> > > > > > > True > > > > > > > > org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy > olicy> > > > > 50 > > 1000 > > 300 > > 600 > > 400 > > 60 > > 1 > > 0.75 > > > > > > > > 100 > > 10 > > > > A > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > > > Huss > > > Sent: Tuesday, September 18, 2001 8:16 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > > > > > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > > > locking code has changed. I have an entity bean with all methods having > > > the transaction attribute set to "RequiresNew" and works great under JBoss > > > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > > > condition errors in this particular entity bean. > > > > > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > > > calls on the same bean where one of the calls should block until the other > > > one completes (and it does in 2.4.0). I was able to reproduce the race > > > condition and then downgrade to 2.4.0 and everything worked great again > > > with one of the method calls blocking as expected, then upgrading back to > > > 2.4.1 one more time showed the race condition again. > > > > > > Lastly, is there a bugzilla or something similar for JBoss where I can > > > submit bug reports, or is this the best place to do it? > > > > > > Thanks, > > > Todd > > > > > > > > > > > > > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Optimized EJB calls in catalina
Scott M Stark wrote: > I looked at integrating the catalina final release with integrated > security and JNDI and I find that everything works except for optimized > EJB calls. Did you use the updated Catalina support that I've added? /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of "Mastering RMI" Email: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] How does JBoss do Stateless Session Beans?
We should restore pooling of stateless session beans and message driven beans. If such beans perform any non-trivial initialization during ejbCreate for use across stateless methods we are killing the performance of the bean and wasting these resources. - Original Message - From: "Sacha Labourey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Jboss-Dev" <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 7:23 AM Subject: RE: [JBoss-user] How does JBoss do Stateless Session Beans? > Hello Olivier, > > For various reason, mainly the highly added complexity when synchronising > entity beans, the pool has been modified by ... not pooling i.e. the > pool.free method instead pushes a new fresh instance on the pool stack. > Consequently, the current code will call ejbRemove *only* when your server > is under high load and it needs to free instances that cannot fit on the > stack size. In this case, discard(ctx) is called and make appropriate calls. > > But I agree that the code sould be modified to either: > - really pool SLSB (and only SLSB) > - or correctly call ejbRemove on the SLSB > > Any opinion? > > Cheers, > > > > Sacha > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 17 Successful tests: 15 Errors:2 Failures: 0 [time of test: 19 September 2001 17:56 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > Huss > Sent: Wednesday, September 19, 2001 12:48 PM > To: [EMAIL PROTECTED] > Cc: Bill Burke > Subject: RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > Thanks Bill, your PLEASE NOTE was indeed my problem. During the upgrade I > didn't replace my standardjboss.xml so the Lock interceptor was > missing which was affecting my BMP entity beans. > Cool. That's a big relief on my part Phew! > Is the best way to upgrade right now to simply replace my custom conf > directory with the one from default and reedit all the files? > Yeah, that might be best, but the only config changes I know about between 2.4.0 and 2.4.1 is the new locking stuff. If you have any more problems with locking, let me know. Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Thanks Bill, your PLEASE NOTE was indeed my problem. During the upgrade I didn't replace my standardjboss.xml so the Lock interceptor was missing which was affecting my BMP entity beans. Is the best way to upgrade right now to simply replace my custom conf directory with the one from default and reedit all the files? Thanks, Todd On Wed, 19 Sep 2001, Bill Burke wrote: > Todd, > > I cannot reproduce this problem. You're going to have to give me a test > case before I believe you. Also, do you use standardjboss.xml to create > your Entity Bean configuration? Or do you make your own. If you use > standardjboss.xml, please attach this to your next reply. > > PLEASE NOTE! > > There has been an extra interceptor added to the interceptor chain in 2.4.1. > Please look in the distributed standardjboss.xml that comes with 2.4.1. > EntityLockInterceptor should be in the interceptor chain, and also a new > field should be set to QueuedPessmisticEJBLock. > > i.e. > > > Standard CMP EntityBean > false > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker ontainer-invoker> > > > org.jboss.ejb.plugins.LogInterceptor > > org.jboss.ejb.plugins.SecurityInterceptor > > org.jboss.ejb.plugins.TxInterceptorCMT > metricsEnabled="true">org.jboss.ejb.plugins.MetricsInterceptor > > org.jboss.ejb.plugins.EntityLockInterceptor > > org.jboss.ejb.plugins.EntityInstanceInterceptor > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor ptor> > > >org.jboss.ejb.plugins.EntityInstancePool > > org.jboss.ejb.plugins.EntityInstanceCache > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager istence-manager> > >org.jboss.tm.TxManager > > org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock -policy> > > > True > > > > org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy olicy> > > 50 > 1000 > 300 > 600 > 400 > >60 > >1 > 0.75 > > > > 100 > 10 > > A > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > > Huss > > Sent: Tuesday, September 18, 2001 8:16 PM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > > locking code has changed. I have an entity bean with all methods having > > the transaction attribute set to "RequiresNew" and works great under JBoss > > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > > condition errors in this particular entity bean. > > > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > > calls on the same bean where one of the calls should block until the other > > one completes (and it does in 2.4.0). I was able to reproduce the race > > condition and then downgrade to 2.4.0 and everything worked great again > > with one of the method calls blocking as expected, then upgrading back to > > 2.4.1 one more time showed the race condition again. > > > > Lastly, is there a bugzilla or something similar for JBoss where I can > > submit bug reports, or is this the best place to do it? > > > > Thanks, > > Todd > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Site is down.
> Bill Burke wrote: > > JBoss website is down nope. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Todd, I cannot reproduce this problem. You're going to have to give me a test case before I believe you. Also, do you use standardjboss.xml to create your Entity Bean configuration? Or do you make your own. If you use standardjboss.xml, please attach this to your next reply. PLEASE NOTE! There has been an extra interceptor added to the interceptor chain in 2.4.1. Please look in the distributed standardjboss.xml that comes with 2.4.1. EntityLockInterceptor should be in the interceptor chain, and also a new field should be set to QueuedPessmisticEJBLock. i.e. Standard CMP EntityBean false org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker org.jboss.ejb.plugins.LogInterceptor org.jboss.ejb.plugins.SecurityInterceptor org.jboss.ejb.plugins.TxInterceptorCMT org.jboss.ejb.plugins.MetricsInterceptor org.jboss.ejb.plugins.EntityLockInterceptor org.jboss.ejb.plugins.EntityInstanceInterceptor org.jboss.ejb.plugins.EntitySynchronizationInterceptor org.jboss.ejb.plugins.EntityInstancePool org.jboss.ejb.plugins.EntityInstanceCache org.jboss.ejb.plugins.jaws.JAWSPersistenceManager org.jboss.tm.TxManager org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock True org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy 50 1000 300 600 400 60 1 0.75 100 10 A > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > Huss > Sent: Tuesday, September 18, 2001 8:16 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > locking code has changed. I have an entity bean with all methods having > the transaction attribute set to "RequiresNew" and works great under JBoss > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > condition errors in this particular entity bean. > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > calls on the same bean where one of the calls should block until the other > one completes (and it does in 2.4.0). I was able to reproduce the race > condition and then downgrade to 2.4.0 and everything worked great again > with one of the method calls blocking as expected, then upgrading back to > 2.4.1 one more time showed the race condition again. > > Lastly, is there a bugzilla or something similar for JBoss where I can > submit bug reports, or is this the best place to do it? > > Thanks, > Todd > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Site is down.
JBoss website is down
[JBoss-dev] RE: MethodOnlyLock in 2.4.1?
MethodOnlyLock is there, but the read-only special case has not been put in yet. But, You can use the entity instance per transaction interceptors I wrote. Unfortunately there is a stupid bug in them in the 2.4.1 release, but you can get latest from the CVS Branch_2_4 to get my fixes. With "entity instance per transaction", entities are not locked into a transaction, but instead an instance per entity bean is created per transaction. To use this do the following: 1. Either change standardjboss.xml or create your own configuration as follows. 2. Edit the Standard CMP EntityBean (and/or BMP) 3. Search for and switch it from QueuedPessimisticEJBLock to MethodOnlyLock. 4. Change EntityInstanceInterceptor to EntityMultiInstanceInterceptor 5. Change EntitySynchronizationInterceptor to EntityMultiInstanceSynchronizationInterceptor 6. Change to B or C. Regards, BIll > -Original Message- > From: Jeffrey Wescott [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 18, 2001 6:21 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: MethodOnlyLock in 2.4.1? > > > Did MethodOnlyLock for read-only entity beans make it into 2.4.1? > If so, is > there any documentation on how to use it anywhere? > > ++jeff > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1
Can you give a simple test case? I'll look into this. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Todd > Huss > Sent: Tuesday, September 18, 2001 8:16 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] RequiresNew Locking Bug in JBoss 2.4.1 > > > I just upgraded from JBoss 2.4.0 to JBoss 2.4.1 and noticed some of the > locking code has changed. I have an entity bean with all methods having > the transaction attribute set to "RequiresNew" and works great under JBoss > 2.4.0. As soon as I upgraded to 2.4.1 though, I started getting race > condition errors in this particular entity bean. > > In 2.4.1, RequiresNew methods are currently allowing simultaneous method > calls on the same bean where one of the calls should block until the other > one completes (and it does in 2.4.0). I was able to reproduce the race > condition and then downgrade to 2.4.0 and everything worked great again > with one of the method calls blocking as expected, then upgrading back to > 2.4.1 one more time showed the race condition again. > > Lastly, is there a bugzilla or something similar for JBoss where I can > submit bug reports, or is this the best place to do it? > > Thanks, > Todd > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] VB: [JBoss-user] Help preparing an intro to JBoss
Hi! The same goes for me - the training is a real success :-) To refer to Edwards mail i think that it would be good to have some presentation material from JBoss downloadable, because it is quite often that you have to hold a short presentation of JBoss and its features and why it is a good bet to choose JBoss. Not only internally but also for potential customers. To have a powerpoint presentaion available from JBoss would help a lot. And again, Marc/Juha - thanks for a superb training!!! /Lennart - Original Message - From: Edward Q. Bridges <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 19, 2001 12:13 PM Subject: [JBoss-user] Help preparing an intro to JBoss hi all, i just came back from the training session in London, and found it to be a very rewarding experience (thanks for the dinner marc!). being new to EJB stuff -- and newer to JBoss -- i found it to be both an excellent introduction to the inner workings of JBoss, and how it deals with EJB. to be sure, there was a lot over my head, but it was enough to be exposed to the breadth and depth of it all. one thing i would have found helpful, would have been to have the detailed description of the JBoss architecture presented earlier in the week rather than friday. but, it was useful and insightful anyway. i am planning on giving a one hour or so presentation to my co-workers (senior and mid level java) introducing them to JBoss. they are mostly familiar with Weblogic (5&6), and most of them are more experienced with JSP and Servlets than with EJB. i had considered this as a rough outline for the presentation: * intro to jboss.org * description of jboss features and things that differentiate it from the competition * description of jboss config & directory layout * description of jboss architecture * ??? so, my questions are: * has anyone done something of this sort before, and can offer any materials that can help? * can anyone add to the list of talking points, or suggest alternatives? * along those lines, would anyone care to offer some ideas/information/approaches to flesh out each of the talking points? thanks a lot! --e-- ed.q.bridges tel. 089-368179.552 fax 089-368179.79 osterwaldstraße 10 (haus F eingang 21) 80805 münchen ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 17 Successful tests: 15 Errors:2 Failures: 0 [time of test: 19 September 2001 12:53 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.3-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS [details not shown - as this makes the mail too big to reach the sf mailing list] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-user] JBoss training: a must!
Hello, I just come back from the JBoss training in London: *it was a really great training*! During the first two days, Marc and Juha have gone through a deep presentation of J2EE concepts, useful patterns, etc. Furthermore, even you already are an experienced J2EE programer, you will enjoy these first two days: continous references to JBoss related concepts were done. In the next 3 days, we have gone through JBoss internals, very interesting labs, and, last but not least, Rabbit Hole introduction and demonstration! And I can tell you that JBoss 3.0 will be very impressive (is is already)! For example, some of the hot topics have been: - Very interesting JMX presentation done by Mr. JMX: Juha Linfords (whose JMX book will be published soon) - JBossSX security service with Scott Stark material (don't forget to tighten your seat belt for this course! It shakes!) - Classloaders issues - Clustering preview (well, I am not objective here... ;) ) And be sure you won't sleep (at least during the training...): the training is intensive and highly stimulating (and Marc performs a real one-man-show! ;)) You will also receive a "book" containing the whole training material. What ?!? You are not yet registered to the Las Vegas training (or any subsequent training) ?!? Then hurry up before no more seat is available! Be ready to become good! ;) Good training! Sacha ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-dev] [JBossCMP] STUPID AM I !!! REMOVE THAT! W32.Nimda.A@mm worm attack on jbosscmp
OOPS... sorry 8< by sending the warning message I'm afraid I've send you the "readme.exe" file. (it is hard to remark when you send an attachment in outlook) it is not infectious when just reading the mail, but Don't execute this attachment ! I'm really ... sorry... please don't beat me (I can do it myself, and my security officer can help me to) I just hope that out viruswall have intercepted it before, but I'm afraid no, since I've received it back. 8< ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCMP] W32.Nimda.A@mm worm attack on jbosscmp
I've receives this worm attack (below without the infectious attachments !) through the jbossCMP mailing list. It tries to execute a .exe, when you preview the message, even if you open no attachment at all... please beware this is a well known worm http:[EMAIL PROTECTED] exploiting a Win32/MIME/IE5.x bug corrected by recent patches like this one http://www.microsoft.com/windows/ie/downloads/critical/q299618/default.asp (windowsupdate.com propose it ) hope this helps... victims spread the worm through mail or IIS... -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Date: mardi 18 septembre 2001 18:20 À: undisclosed-recipients Objet: [JBossCMP] usamplesamplesampledesktopdesktopsamplesampledesktopsamplesamplesamplesample desktopsampledesktopsampledesktopdesktopdesktopsamplesampledesktopdesktopsam plesampledesktopsampledesktopdesktopdesktopdesktopdesktopdesktopdesktopdeskt opdesktopsampled ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Virus Alert
09/19/2001 10:51:18 - InterScan a detecte un virus TROJ_NIMDA.A dans le fichier readme.exe dans un mail de [EMAIL PROTECTED] vous etant adresse; pour votre securite, le fichier a ete intercepte (Action : quarantined.). Vos autres fichiers sont a priori sains. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBossCMP] W32.Nimda.A@mm worm attack on jbosscmp
I've receives this worm attack (below without the infectious attachments !) through the jbossCMP mailing list. It tries to execute a .exe, when you preview the message, even if you open no attachment at all... please beware this is a well known worm http:[EMAIL PROTECTED] exploiting a Win32/MIME/IE5.x bug corrected by recent patches like this one http://www.microsoft.com/windows/ie/downloads/critical/q299618/default.asp (windowsupdate.com propose it ) hope this helps... victims spread the worm through mail or IIS... -Message d'origine- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Date: mardi 18 septembre 2001 18:20 À: undisclosed-recipients Objet: [JBossCMP] usamplesamplesampledesktopdesktopsamplesampledesktopsamplesamplesamplesample desktopsampledesktopsampledesktopdesktopdesktopsamplesampledesktopdesktopsam plesampledesktopsampledesktopdesktopdesktopdesktopdesktopdesktopdesktopdeskt opdesktopsampled -- Virus Warning Message (on the network) readme.exe is removed from here because it contains a virus. - -- Virus Warning Message (on the network) Found virus TROJ_NIMDA.A in file readme.exe The file readme.exe is moved to /etc/iscan/virus/virSIAUdKg3_. For more information, please contact [EMAIL PROTECTED] -
