Re: [JBoss-dev] jboss daily test results
Hi, --- Jason Dillon [EMAIL PROTECTED] wrote: Huh? Why did the number of tests drop? Good question - we did seem to hit a memory/number of sockets limit a few weeks back - perhaps there is some variation in the tests that means they sometimes use more resources... Strangely, it went back to 133 passed tests the next day... I thought we went up to 140 tests or so a few weeks back - is this what people are seeing when they test on their own machines? Chris --jason On Sun, 22 Jul 2001 [EMAIL PROTECTED] wrote: JBoss daily test results SUMMARY Number of tests run: 59 Successful tests: 59 Errors:0 Failures: 0 [time of test: 22 July 2001 3:45 GMT] = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] unsuscribe
___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: !!!WHERE IS THIS CLASS?? Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java BMPPersistenceManager.java CMPPersistenceManager.java EntityInstancePool.java LRUEnterpriseContextCachePolicy.java LogInterceptor.java MessageDrivenInstanceInterceptor.java MessageDrivenInstancePool.java MessageDrivenTxInterceptorBMT.java MetricsInterceptor.java SecurityInterceptor.java SecurityProxyInterceptor.java SingletonStatelessSessionInstancePool.java StatefulSessionInstanceInterceptor.java StatefulSessionInstancePool.java StatelessSessionInstancePool.java TxInterceptorBMT.java TxInterceptorCMT.java
A little more investigation shows that jboss-management.jar has this file compiled in but it still isn't in cvs. Why do you check in a jar for classes in the jboss project? Isn't it built whenever you build jboss? Also, where can I find the management package? Did you choose this package name? Is it appropriate? If the source for these is not available would it be more appropriate to have 2 jars one with jboss classes and one with non jboss classes? Thanks david jencks On 2001.07.21 10:22:32 -0400 David Jencks wrote: Andy, I can't find JBossCountStatistic in CVS, so I can't compile jboss. Could you please fix asap? I'd like to check my work against cvs before I submit a patch. Thanks david jencks On 2001.07.20 16:07:16 -0400 Andreas Mad Schaefer wrote: User: schaefera Date: 01/07/20 13:07:16 Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java snip the culprit--- +import org.jboss.management.JBossCountStatistic; snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/metadata FinderMetaData.java JawsApplicationMetaData.java
User: deerwood
Date: 01/07/23 09:28:46
Modified:src/main/org/jboss/ejb/plugins/jaws/metadata
FinderMetaData.java JawsApplicationMetaData.java
Log:
o Indentation and formatting to project standards.
Revision ChangesPath
1.5 +41 -29
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java
Index: FinderMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/FinderMetaData.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- FinderMetaData.java 2001/06/21 21:52:38 1.4
+++ FinderMetaData.java 2001/07/23 16:28:46 1.5
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.ejb.plugins.jaws.metadata;
import org.w3c.dom.Element;
@@ -15,71 +16,82 @@
/**
- * description
- *
- * @see related
- * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @author a href=[EMAIL PROTECTED]danch/a
- * @author a href=[EMAIL PROTECTED]Bill Burke/a
- * @version $Revision: 1.4 $
+ * description
+ *
+ * @see related
+ * @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
+ * @author a href=[EMAIL PROTECTED]danch/a
+ * @author a href=[EMAIL PROTECTED]Bill Burke/a
+ * @version $Revision: 1.5 $
*
* Revisions:
* 20010621 Bill Burke: setReadAhead added.
*
*/
-public class FinderMetaData extends MetaData implements XmlLoadable {
+public class FinderMetaData
+ extends MetaData
+ implements XmlLoadable
+{
// Constants -
-
+
// Attributes
+
private String name;
private String order;
private String query;
-
+
/** do we perform 'read-ahead' of column values? (avoid making n+1 database
hits) */
private boolean readAhead = false;
-
+
// Static
-
+
// Constructors --
+
/** default constructor */
- public FinderMetaData() {
- }
-
- /** constructor used to provide non-defined finders (findAll, BMP style
-* finders) with their metadata. */
- public FinderMetaData(String name) {
+ public FinderMetaData() {}
+
+ /**
+* constructor used to provide non-defined finders (findAll, BMP style
+* finders) with their metadata.
+*/
+ public FinderMetaData(String name)
+ {
this.name = name;
}
-
+
// Public
+
public String getName() { return name; }
-
+
public String getOrder() { return order; }
-
+
public String getQuery() { return query; }
-
+
public boolean hasReadAhead() { return readAhead; }
public void setReadAhead(boolean newval)
{
readAhead = newval;
}
-
+
// XmlLoadable implementation
- public void importXml(Element element) throws DeploymentException {
+
+ public void importXml(Element element)
+ throws DeploymentException
+ {
name = getElementContent(getUniqueChild(element, name));
query = getElementContent(getUniqueChild(element, query));
order = getElementContent(getUniqueChild(element, order));
-
+
// read ahead? If not provided, keep default.
String readAheadStr = getElementContent(getOptionalChild(element,
read-ahead));
if (readAheadStr != null) readAhead =
Boolean.valueOf(readAheadStr).booleanValue();
- }
-
+ }
+
// Package protected -
-
+
// Protected -
-
+
// Private ---
// Inner classes -
1.9 +216 -178
jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsApplicationMetaData.java
Index: JawsApplicationMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/metadata/JawsApplicationMetaData.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- JawsApplicationMetaData.java 2001/06/27 03:55:36 1.8
+++ JawsApplicationMetaData.java 2001/07/23 16:28:46 1.9
@@ -4,6 +4,7 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
+
package org.jboss.ejb.plugins.jaws.metadata;
import
Re: [JBoss-dev] jboss daily test results
Hi, I just switched to the latest IBM jdk1.3 and I now get 145 tests - of which one fails - see http://lubega.com for details. I will try and get the tests to be built and run twice - once using sun and then again using the ibm jdk. Any other 1.3 jdk's / variations under Linux that are worth testing? It is definitely worth trying to solve the problem regarding invisible tests - I thought it was due to some tests failing in startup and not producing any output at all... Chris --- Scott M Stark [EMAIL PROTECTED] wrote: I am seeing 133 tests currently. The resource problem is due to too many processes on linux. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 4:24 AM Subject: Re: [JBoss-dev] jboss daily test results Hi, --- Jason Dillon [EMAIL PROTECTED] wrote: Huh? Why did the number of tests drop? Good question - we did seem to hit a memory/number of sockets limit a few weeks back - perhaps there is some variation in the tests that means they sometimes use more resources... Strangely, it went back to 133 passed tests the next day... I thought we went up to 140 tests or so a few weeks back - is this what people are seeing when they test on their own machines? Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: !!!WHERE IS THIS CLASS?? Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java BMPPersistenceManager.java CMPPersistenceManager.java EntityInstancePool.java LRUEnterpriseContextCachePolic
Hi David First, could you compile now because for it is working fine and I don't have this JAR file modified ? The classes are developed outside of JBoss because they belong to JSR-77. Whenever I make a change I will add the compiled classes in the JAR file update it on CVS. I will also add a HTML docu but not the source but this will come. The package management is not choosen by my. Yes, your right we should have two jar files but right now I want to keep management and org.jboss.management (at least what is an extension of managment) in one jar-file. Whenever the package management (which contains JSR-77 classes) becomes more stable I will separate them. Thanx - Andy -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 9:22 AM To: [EMAIL PROTECTED] Cc: Andreas Schaefer Subject: Re: !!!WHERE IS THIS CLASS?? Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java BMPPersistenceManager.java CMPPersistenceManager.java EntityInstancePool.java LRUEnterpriseContextCachePolic A little more investigation shows that jboss-management.jar has this file compiled in but it still isn't in cvs. Why do you check in a jar for classes in the jboss project? Isn't it built whenever you build jboss? Also, where can I find the management package? Did you choose this package name? Is it appropriate? If the source for these is not available would it be more appropriate to have 2 jars one with jboss classes and one with non jboss classes? Thanks david jencks On 2001.07.21 10:22:32 -0400 David Jencks wrote: Andy, I can't find JBossCountStatistic in CVS, so I can't compile jboss. Could you please fix asap? I'd like to check my work against cvs before I submit a patch. Thanks david jencks On 2001.07.20 16:07:16 -0400 Andreas Mad Schaefer wrote: User: schaefera Date: 01/07/20 13:07:16 Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java snip the culprit--- +import org.jboss.management.JBossCountStatistic; snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss daily test results
I just updated jbosstest and reran it on w2k and I am now seeing 145 tests with 3 failures. The failures are in the readahead test. I'm going to retry the tests on linux with the Sun and IBM jdks. I don't know of any other JDKs worth looking at on linux. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 9:47 AM Subject: Re: [JBoss-dev] jboss daily test results Hi, I just switched to the latest IBM jdk1.3 and I now get 145 tests - of which one fails - see http://lubega.com for details. I will try and get the tests to be built and run twice - once using sun and then again using the ibm jdk. Any other 1.3 jdk's / variations under Linux that are worth testing? It is definitely worth trying to solve the problem regarding invisible tests - I thought it was due to some tests failing in startup and not producing any output at all... Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs howtoejbdoclet.xml
User: ibruell
Date: 01/07/23 11:38:40
Modified:src/docs howtoejbdoclet.xml
Log:
Remarks to the renaming of EJBDoclet to XDoclet.
Revision ChangesPath
1.4 +29 -4 manual/src/docs/howtoejbdoclet.xml
Index: howtoejbdoclet.xml
===
RCS file: /cvsroot/jboss/manual/src/docs/howtoejbdoclet.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- howtoejbdoclet.xml2001/07/13 16:07:13 1.3
+++ howtoejbdoclet.xml2001/07/23 18:38:40 1.4
@@ -2,7 +2,7 @@
!-- brief howto for using ejbdoclet --
section id=howtoejbdoclet
- titleHow to use EJBDoclet/title
+ titleHow to generate Beans with EJBDoclet (XDoclet)/title
subtitleIn work(!)/subtitle
paraAuthor:
@@ -21,8 +21,16 @@
/para
para
EJBDoclet is a OpenSource project initiated by Rickard Oberg which stays at
-ulink url=http://sf.net/projects/ejbdoclet;sourceforge.net/ulink.
+ulink url=http://sourceforge.net/projects/ejbdoclet;
+http://sourceforge.net/projects/ejbdoclet/ulink.
/para
+ para
+EJBDoclet has renamed to XDoclet and a new project with this name was initiated.
+For now no release with the new name is available, but all questions about
+EJBDoclet and in the future for XDoclet goes to the new mailing lists from
+XDoclet hosted at ulink url=http://sourceforge.net/projects/xdoclet;
+http://sourceforge.net/projects/xdoclet/ulink
+ /para
section id=ejbdoclet-requirements
titleRequirements/title
@@ -236,7 +244,7 @@
programlisting![CDATA[
?xml version=1.0 encoding=ISO-8859-1?
!--
- $Revision: 1.3 $ $Date: 2001/07/13 16:07:13 $ $Author: ibruell $
+ $Revision: 1.4 $ $Date: 2001/07/23 18:38:40 $ $Author: ibruell $
--
project name=test default=main basedir=../..
@@ -281,6 +289,7 @@
destdir=${src.dir}
packagenames=test
classpath=${classpath};${basedir}/lib/ejbdoclet.jar
+ ejbspec=1.1
excludedtags=@version,@author
dataobject/
remoteinterface/
@@ -409,12 +418,27 @@
]]/programlisting
/para
para
+ I have splitted the generating beans and creating the application in different
+ tasks. To generate the beans call build buildbeans and to create the
+ application call build.
+/para
+para
+ EJBDoclet throws some Exceptions at the first call, they could be ignored,
+ however.
+/para
+para
The build.xml generates first PrimaryKey and DataObject classes, Home and
Remote Interfaces and ejb-jar.xml, jboss.xml and jaws.xml descriptors. The
java files are then compiled into the build/classes directory. After that the
files would be archived in test.jar in dist/deploy, however. Now the jar file
could be deployed in jboss.
/para
+para
+ If you are using ejbspec=2.0 or nothing (default is 2.0) than it is
+ possible that jboss does not find the dtd's defined in the deployment
+ descriptors just remove this lines or comment them out. For me I have changed
the
+ templates from ejbdoclet so they do not generate these lines.
+/para
/section
@@ -423,7 +447,8 @@
para
A brief explanation of all possible parameters and a complete example
you can find in the ejbdoclet archive, that could be downloaded from
- ulink url=http://sf.net/projects/ejbdoclet;sourceforge/ulink.
+ ulink url=http://sourceforge.net/projects/ejbdoclet;
+ http://sourceforge.net/projects/ejbdoclet/ulink.
/para
/section
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-443893 ] Message-driven-destination is optional
Bugs item #443893, was opened at 2001-07-23 12:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=443893group_id=22866 Category: JBossServer Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Message-driven-destination is optional Initial Comment: The message-driven-destination is optional in ejb-jar_2_0.dtd, but required by JBoss [AutoDeployer] Deployment failed:file:/CVS/jboss/jboss/dist/deploy/server.jar org.jboss.deployment.J2eeDeploymentException: Error while starting server.jar: Could not deploy file:/linux/b/CVS/jboss/jboss/dist/tmp/deploy/Default/server.jar, Cause: org.jboss.ejb.DeploymentException: Could not deploy file:/CVS/jboss/jboss/dist/tmp/deploy/Default/server.jar, Cause: org.jboss.ejb.DeploymentException: Error in ejb-jar.xml for Message Driven Bean MYM: expected one message-driven-destination tag at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:513) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:466) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:209) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.ejb.AutoDeployer.deploy(AutoDeployer.java:381) at org.jboss.ejb.AutoDeployer.run(AutoDeployer.java:220) at java.lang.Thread.run(Thread.java:484) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=443893group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: !!!WHERE IS THIS CLASS?? Re: [JBoss-dev] CVS update: jboss/sr c/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstanceP ool.java BMPPersistenceManager.java CMPPersistenceManager.java EntityInst ancePool.java LRUEnterpriseContextCachePolic
Hi, Yes I can compile if i get the updated jboss-management.jar. Who is developing the management package? Is there a jsr-77 document out? Thanks! david jencks On 2001.07.23 13:29:47 -0400 Schaefer, Andreas wrote: Hi David First, could you compile now because for it is working fine and I don't have this JAR file modified ? The classes are developed outside of JBoss because they belong to JSR-77. Whenever I make a change I will add the compiled classes in the JAR file update it on CVS. I will also add a HTML docu but not the source but this will come. The package management is not choosen by my. Yes, your right we should have two jar files but right now I want to keep management and org.jboss.management (at least what is an extension of managment) in one jar-file. Whenever the package management (which contains JSR-77 classes) becomes more stable I will separate them. Thanx - Andy -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 9:22 AM To: [EMAIL PROTECTED] Cc: Andreas Schaefer Subject: Re: !!!WHERE IS THIS CLASS?? Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java BMPPersistenceManager.java CMPPersistenceManager.java EntityInstancePool.java LRUEnterpriseContextCachePolic A little more investigation shows that jboss-management.jar has this file compiled in but it still isn't in cvs. Why do you check in a jar for classes in the jboss project? Isn't it built whenever you build jboss? Also, where can I find the management package? Did you choose this package name? Is it appropriate? If the source for these is not available would it be more appropriate to have 2 jars one with jboss classes and one with non jboss classes? Thanks david jencks On 2001.07.21 10:22:32 -0400 David Jencks wrote: Andy, I can't find JBossCountStatistic in CVS, so I can't compile jboss. Could you please fix asap? I'd like to check my work against cvs before I submit a patch. Thanks david jencks On 2001.07.20 16:07:16 -0400 Andreas Mad Schaefer wrote: User: schaefera Date: 01/07/20 13:07:16 Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java AbstractInstancePool.java snip the culprit--- +import org.jboss.management.JBossCountStatistic; snip ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss daily test results
How about 1.4beta? Just a thought, but I would like to make use of the new assertion facility as soon as it is stable. --jason On Mon, 23 Jul 2001, Chris Kimpton wrote: Hi, I just switched to the latest IBM jdk1.3 and I now get 145 tests - of which one fails - see http://lubega.com for details. I will try and get the tests to be built and run twice - once using sun and then again using the ibm jdk. Any other 1.3 jdk's / variations under Linux that are worth testing? It is definitely worth trying to solve the problem regarding invisible tests - I thought it was due to some tests failing in startup and not producing any output at all... Chris --- Scott M Stark [EMAIL PROTECTED] wrote: I am seeing 133 tests currently. The resource problem is due to too many processes on linux. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 4:24 AM Subject: Re: [JBoss-dev] jboss daily test results Hi, --- Jason Dillon [EMAIL PROTECTED] wrote: Huh? Why did the number of tests drop? Good question - we did seem to hit a memory/number of sockets limit a few weeks back - perhaps there is some variation in the tests that means they sometimes use more resources... Strangely, it went back to 133 passed tests the next day... I thought we went up to 140 tests or so a few weeks back - is this what people are seeing when they test on their own machines? Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] PrintWriter Resources
The PrintWriter is coming from 5.6 of the J2EE connector spec. Section 5.10.1 lists these logging support methods as required: A resource adapter is required to provide support for basic error logging and tracing by implementing the following methods: . ManagedConnectionFactory.set/getLogWriter . ManagedConnection.set/getLogWriter It is just a portable way to integrate some level of logging into the app server the resource is being used in. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 20, 2001 7:23 PM Subject: [JBoss-dev] PrintWriter Resources Can someone explain to me what the PrintWriter is used for in a resource? Is this meant for portable logging between app servers? Is that important for us? I am getting very frustrated at the JMS RA logging. I would like to move it to Log4j, but I can't seem to find the right way to do it with this PrintWriter bit laying around. Could someone drop a bit of knowledge about this for me? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss daily test results
On a RedHat7.1 system with linux kernel 2.4.3-12 using this Sun VM: build 68java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) I'm seeing 145 tests that all run successfully in 9.25 minutes. Using this IBM VM: build 77/opt/IBMJava2-13/bin/java -version java version 1.3.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0) Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20010502 (JIT enabled: jitc)) I'm seeing 145 tests that all run successfully in 7.5 minutes. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 9:47 AM Subject: Re: [JBoss-dev] jboss daily test results Hi, I just switched to the latest IBM jdk1.3 and I now get 145 tests - of which one fails - see http://lubega.com for details. I will try and get the tests to be built and run twice - once using sun and then again using the ibm jdk. Any other 1.3 jdk's / variations under Linux that are worth testing? It is definitely worth trying to solve the problem regarding invisible tests - I thought it was due to some tests failing in startup and not producing any output at all... Chris --- Scott M Stark [EMAIL PROTECTED] wrote: I am seeing 133 tests currently. The resource problem is due to too many processes on linux. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 4:24 AM Subject: Re: [JBoss-dev] jboss daily test results Hi, --- Jason Dillon [EMAIL PROTECTED] wrote: Huh? Why did the number of tests drop? Good question - we did seem to hit a memory/number of sockets limit a few weeks back - perhaps there is some variation in the tests that means they sometimes use more resources... Strangely, it went back to 133 passed tests the next day... I thought we went up to 140 tests or so a few weeks back - is this what people are seeing when they test on their own machines? Chris ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] client application gets stuck, hangs, freezes, whatever you want to call it
Hello all,
Let's start with the summary of my problem: My client application hangs
after a while when working with CMP Entity beans
Environment:
JBOSS is running on AppServer.mycompany.com (2.4.0.6 Beta) on Sun JDK
1.3.0_03
PostGreSQL 7.1.2 is running on DBServer.mycompany.com
My client application is ALSO running on DBServer.mycompany.com on Sun JDK
1.3.0_03
so it makes a nifty little out-and-back loop ... my client opens up a
connection to JBOSS over the network, then JBOSS contacts the DB via JDBC
over the network ...
Here's the pseudocode of what happens:
void run()
{
//Perform some aggregate operation on the rows in my table
//This is a straight SQL query executed over a direct JDBC connection
ArrayList salesRank = getSalesRankData();
//Get all of the records from my table (~1500 records)
Enumeration beans = myHome.findAll();
while(beans.hasMoreElements())
{
//Get the new value for this row
Float curSalesRank = (Float)salesRank.get(i++);
//Get the remote interface
MyBean curBean = beans.nextElement();
//Set the sales rank
curBean.setSalesRank(curSalesRank);
}
}
The problem is that, without warning, the while() loop gets stuck at the
setSalesRank() call ... I installed OptimizeIt which was able to reveal the
following stack trace:
100.0% - 653169 ms - java.net.SocketInputStream.socketRead()
100.0% - 653169 ms - java.net.SocketInputStream.read()
100.0% - 653169 ms - java.io.BufferedInputStream.fill()
100.0% - 653169 ms - java.io.BufferedInputStream.read()
100.0% - 653169 ms - java.io.DataInputStream.readByte()
100.0% - 653169 ms -
sun.rmi.transport.StreamRemoteCall.executeCall()
100.0% - 653169 ms - sun.rmi.server.UnicastRef.invoke()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke()
100.0% - 653169 ms - $Proxy5.setSalesRank()
100.0% - 653169 ms -
com.mycompany.CatalogItemSalesRankHandler.handleEvent()
100.0% - 653169 ms -
com.mycompany.EventServer.doJob()
100.0% - 653169 ms -
com.mycompany.EventServer.run()
100.0% - 653169 ms -
java.lang.Thread.run()
Back on the JBOSS box, after at least a minute or so, the following
exception shows up:
[Catalog_Item] XAException: tx=XidImpl [FormatId=257,
GlobalId=timqa1.amsnet.com//193493, BranchQual=] errorCode=XA_UNKNOWN(0)
[Catalog_Item] javax.transaction.xa.XAException: Rollback failed: An I/O
error has occured while flushing the output - Exception:
java.io.IOException: Broken pipe
[Catalog_Item] Stack Trace:
[Catalog_Item]
[Catalog_Item] java.io.IOException: Broken pipe
[Catalog_Item] at java.net.SocketOutputStream.socketWrite(Native Method)
[Catalog_Item] at
java.net.SocketOutputStream.write(SocketOutputStream.java:83)
[Catalog_Item] at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
[Catalog_Item] at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130)
[Catalog_Item] at org.postgresql.PG_Stream.flush(PG_Stream.java:414)
[Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:464)
[Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:400)
[Catalog_Item] at
org.postgresql.jdbc2.Connection.rollback(Connection.java:242)
[Catalog_Item] at
org.jboss.pool.jdbc.xa.wrapper.XAResourceImpl.rollback(XAResourceImpl.java:2
17)
[Catalog_Item] at
org.jboss.tm.TxCapsule.rollbackResources(TxCapsule.java:1539)
[Catalog_Item] at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:394)
[Catalog_Item] at
org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:88)
[Catalog_Item] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:343)
[Catalog_Item] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Catalog_Item] at
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:12
7)
[Catalog_Item] at
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:195)
[Catalog_Item] at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:349)
[Catalog_Item] at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPContainerI
nvoker.java:390)
[Catalog_Item] at java.lang.reflect.Method.invoke(Native Method)
[Catalog_Item] at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
[Catalog_Item] at sun.rmi.transport.Transport$1.run(Transport.java:142)
[Catalog_Item] at java.security.AccessController.doPrivileged(Native
Method)
Re: [JBoss-dev] PrintWriter Resources
Do you have any ideas on an good way to use this api to hook up the Log4j or should we just use Log4j directly? --jason On Mon, 23 Jul 2001, Scott M Stark wrote: The PrintWriter is coming from 5.6 of the J2EE connector spec. Section 5.10.1 lists these logging support methods as required: A resource adapter is required to provide support for basic error logging and tracing by implementing the following methods: . ManagedConnectionFactory.set/getLogWriter . ManagedConnection.set/getLogWriter It is just a portable way to integrate some level of logging into the app server the resource is being used in. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 20, 2001 7:23 PM Subject: [JBoss-dev] PrintWriter Resources Can someone explain to me what the PrintWriter is used for in a resource? Is this meant for portable logging between app servers? Is that important for us? I am getting very frustrated at the JMS RA logging. I would like to move it to Log4j, but I can't seem to find the right way to do it with this PrintWriter bit laying around. Could someone drop a bit of knowledge about this for me? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] PrintWriter Resources
Since this is a JBoss adapter I don't the benefit in supporting the PrintWriter interface for logging integration. If there was a reason to support PrintWriter I would use log4j by default in the JmsLogger and expose Category type methods from JmsLogger. If there was no PrintWriter set these would delegate to a category for the jms/ra package. I don't see a reason not to use log4j directly though. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 3:21 PM Subject: Re: [JBoss-dev] PrintWriter Resources Do you have any ideas on an good way to use this api to hook up the Log4j or should we just use Log4j directly? --jason On Mon, 23 Jul 2001, Scott M Stark wrote: The PrintWriter is coming from 5.6 of the J2EE connector spec. Section 5.10.1 lists these logging support methods as required: A resource adapter is required to provide support for basic error logging and tracing by implementing the following methods: . ManagedConnectionFactory.set/getLogWriter . ManagedConnection.set/getLogWriter It is just a portable way to integrate some level of logging into the app server the resource is being used in. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 20, 2001 7:23 PM Subject: [JBoss-dev] PrintWriter Resources Can someone explain to me what the PrintWriter is used for in a resource? Is this meant for portable logging between app servers? Is that important for us? I am getting very frustrated at the JMS RA logging. I would like to move it to Log4j, but I can't seem to find the right way to do it with this PrintWriter bit laying around. Could someone drop a bit of knowledge about this for me? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Let's finish and stabilize the 2.* series. This will need to go in the new 3.* series where we can rethink locking and clustering. A locking that will support distribution and multiple instances will be interesting. If you mean synchronizing bean access in the container across multiple instances of the container, I would ask why? If I misinterpreted, I apologize. I currently know of *no* EJB container that can synch EJB instances across distributed containers. Gemstone (brokat now) may be able to, but only because they have a persistent cache architecture which is really a distributed database, and it is external to their container anyways. The other guys (and you guys) may be able to do it by throwing enough resources at it, but it would still be very difficult. In the end, I scratch my head and wonder why? I can't even think of a good reason to synch access to beans in a *single* container. No one really does it anymore besides jBoss. It has been proven to be contrary to performance and can be prone to deadlock issues. I'll stop there until I figure out if I understood the proposed direction correctly. :-) jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
Hi Maybe also wrong but I think the distributed locking/synchr. will be necessary when you run EJBs in a clustered environment where there is not one EJB Container but several of them able to serve and transparent to the client. On the other hand I know that IBM WebSphere uses an external DB for the same reason as well. Andy -Original Message- From: James Cook [mailto:[EMAIL PROTECTED]] Sent: Monday, July 23, 2001 4:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new wait(1000) not good -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Let's finish and stabilize the 2.* series. This will need to go in the new 3.* series where we can rethink locking and clustering. A locking that will support distribution and multiple instances will be interesting. If you mean synchronizing bean access in the container across multiple instances of the container, I would ask why? If I misinterpreted, I apologize. I currently know of *no* EJB container that can synch EJB instances across distributed containers. Gemstone (brokat now) may be able to, but only because they have a persistent cache architecture which is really a distributed database, and it is external to their container anyways. The other guys (and you guys) may be able to do it by throwing enough resources at it, but it would still be very difficult. In the end, I scratch my head and wonder why? I can't even think of a good reason to synch access to beans in a *single* container. No one really does it anymore besides jBoss. It has been proven to be contrary to performance and can be prone to deadlock issues. I'll stop there until I figure out if I understood the proposed direction correctly. :-) jim ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Cook Sent: Monday, July 23, 2001 7:55 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new wait(1000) not good -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Let's finish and stabilize the 2.* series. This will need to go in the new 3.* series where we can rethink locking and clustering. A locking that will support distribution and multiple instances will be interesting. If you mean synchronizing bean access in the container across multiple instances of the container, I would ask why? If I misinterpreted, I apologize. Our app is a perfect example. We have one large database server and 3-4 smaller App servers each running Jetty/JBoss. We need to synchronize some entity beans across JBoss instances so we use select...for update. I firmly believe though that the datastore should be doing all the synchronization in a clustered environment. I currently know of *no* EJB container that can synch EJB instances across distributed containers. Gemstone (brokat now) may be able to, but only because they have a persistent cache architecture which is really a distributed database, and it is external to their container anyways. The other guys (and you guys) may be able to do it by throwing enough resources at it, but it would still be very difficult. In the end, I scratch my head and wonder why? I can't even think of a good reason to synch access to beans in a *single* container. No one really does Read about commit option A. I think synching access in the container for 'A' is a perfectly viable solution. Although, using something like select...for update would make the current JBoss code base much more simple. The question is, does something like select...for update exist for all DBs? probably not. it anymore besides jBoss. It has been proven to be contrary to performance and can be prone to deadlock issues. I agree, but synching is perfectly viable for commit option A. Option B and C is another story. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ditch entity locking in favor of select-for-update
The recents questions posted by James Cook got me thinking. Maybe we should ditch the current entity locking scheme in favor of using select-for-update. It would greatly simplify the entity/cache locking mechanism, thus probably making it much more robust than it currently is. Of course, we'd have to improve select-for-update so that it worked across a greater range of databases and keep the old entity/cache locking for databases that didn't. Also, what about BMP? Does the spec allow for the container to pass on synchronization responsibities to the Bean Developer? I'll have to check. Bill
Re: [JBoss-dev] ditch entity locking in favor of select-for-update
isn't SELECT FOR UPDATE an Oracle-ism? instead of either entity locking or S-F-U, why not use an optimistic concurrency scheme, with verified updates? there was recently a nice catfight on the EJB-INTEREST mailing list between several vendors on this subject, the result of which seemed to be that this would be the approach which maximized both performance and portability. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ditch entity locking in favor of select-for-update
There is an article on JavaWorld about an application level example that uses JBoss: http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.html - Original Message - From: Joseph Dane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 23, 2001 7:49 PM Subject: Re: [JBoss-dev] ditch entity locking in favor of select-for-update isn't SELECT FOR UPDATE an Oracle-ism? instead of either entity locking or S-F-U, why not use an optimistic concurrency scheme, with verified updates? there was recently a nice catfight on the EJB-INTEREST mailing list between several vendors on this subject, the result of which seemed to be that this would be the approach which maximized both performance and portability. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] client application gets stuck, hangs, freezes, whatever you want to call it
Well these are just several wild guesses, but I am curious.
If you generate the SalesRank arraylist without reference to the db, like
from random numbers, do you _ever_ get the hang?
I assume getSalesRankData closes whatever resultsets and statements it
uses? How about the connection?
I don't know much about postgres but have heard rumors it has snapshot
isolation/versioning similar to firebird/interbase. If so, have you
committed after your (presumably read only) query in getSalesRankData?
Thanks
david jencks
On 2001.07.23 17:37:50 -0400 David Esposito wrote:
Hello all,
Let's start with the summary of my problem: My client application hangs
after a while when working with CMP Entity beans
Environment:
JBOSS is running on AppServer.mycompany.com (2.4.0.6 Beta) on Sun JDK
1.3.0_03
PostGreSQL 7.1.2 is running on DBServer.mycompany.com
My client application is ALSO running on DBServer.mycompany.com on Sun
JDK
1.3.0_03
so it makes a nifty little out-and-back loop ... my client opens up a
connection to JBOSS over the network, then JBOSS contacts the DB via JDBC
over the network ...
Here's the pseudocode of what happens:
void run()
{
//Perform some aggregate operation on the rows in my table
//This is a straight SQL query executed over a direct JDBC
connection
ArrayList salesRank = getSalesRankData();
//Get all of the records from my table (~1500 records)
Enumeration beans = myHome.findAll();
while(beans.hasMoreElements())
{
//Get the new value for this row
Float curSalesRank = (Float)salesRank.get(i++);
//Get the remote interface
MyBean curBean = beans.nextElement();
//Set the sales rank
curBean.setSalesRank(curSalesRank);
}
}
The problem is that, without warning, the while() loop gets stuck at the
setSalesRank() call ... I installed OptimizeIt which was able to reveal
the
following stack trace:
100.0% - 653169 ms - java.net.SocketInputStream.socketRead()
100.0% - 653169 ms - java.net.SocketInputStream.read()
100.0% - 653169 ms - java.io.BufferedInputStream.fill()
100.0% - 653169 ms - java.io.BufferedInputStream.read()
100.0% - 653169 ms - java.io.DataInputStream.readByte()
100.0% - 653169 ms -
sun.rmi.transport.StreamRemoteCall.executeCall()
100.0% - 653169 ms - sun.rmi.server.UnicastRef.invoke()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invoke()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invokeContainer()
100.0% - 653169 ms -
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke()
100.0% - 653169 ms - $Proxy5.setSalesRank()
100.0% - 653169 ms -
com.mycompany.CatalogItemSalesRankHandler.handleEvent()
100.0% - 653169 ms -
com.mycompany.EventServer.doJob()
100.0% - 653169 ms -
com.mycompany.EventServer.run()
100.0% - 653169 ms -
java.lang.Thread.run()
Back on the JBOSS box, after at least a minute or so, the following
exception shows up:
[Catalog_Item] XAException: tx=XidImpl [FormatId=257,
GlobalId=timqa1.amsnet.com//193493, BranchQual=] errorCode=XA_UNKNOWN(0)
[Catalog_Item] javax.transaction.xa.XAException: Rollback failed: An I/O
error has occured while flushing the output - Exception:
java.io.IOException: Broken pipe
[Catalog_Item] Stack Trace:
[Catalog_Item]
[Catalog_Item] java.io.IOException: Broken pipe
[Catalog_Item] at java.net.SocketOutputStream.socketWrite(Native Method)
[Catalog_Item] at
java.net.SocketOutputStream.write(SocketOutputStream.java:83)
[Catalog_Item] at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
[Catalog_Item] at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130)
[Catalog_Item] at org.postgresql.PG_Stream.flush(PG_Stream.java:414)
[Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:464)
[Catalog_Item] at org.postgresql.Connection.ExecSQL(Connection.java:400)
[Catalog_Item] at
org.postgresql.jdbc2.Connection.rollback(Connection.java:242)
[Catalog_Item] at
org.jboss.pool.jdbc.xa.wrapper.XAResourceImpl.rollback(XAResourceImpl.java:2
17)
[Catalog_Item] at
org.jboss.tm.TxCapsule.rollbackResources(TxCapsule.java:1539)
[Catalog_Item] at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:394)
[Catalog_Item] at
org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:88)
[Catalog_Item] at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.
java:343)
[Catalog_Item] at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:99)
[Catalog_Item] at
Re: [JBoss-dev] ditch entity locking in favor of select-for-update
select for update is also available in firebird/interbase. Thanks for the pointer to the optimistic discussion. david jencks On 2001.07.23 22:49:16 -0400 Joseph Dane wrote: isn't SELECT FOR UPDATE an Oracle-ism? instead of either entity locking or S-F-U, why not use an optimistic concurrency scheme, with verified updates? there was recently a nice catfight on the EJB-INTEREST mailing list between several vendors on this subject, the result of which seemed to be that this would be the approach which maximized both performance and portability. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ditch entity locking in favor of select-for-update
The recents questions posted by James Cook got me thinking. Maybe we should ditch the current entity locking scheme in favor of using select-for-update. It would greatly simplify the entity/cache locking mechanism, thus probably making it much more robust than it currently is. Of course, we'd have to improve select-for-update so that it worked across a greater range of databases and keep the old entity/cache locking for databases that didn't. Also, what about BMP? Does the spec allow for the container to pass on synchronization responsibities to the Bean Developer? I'll have to check. Note that not all Entities are backed by DBMS's. In the app I'm working on currently they almost never are. Instead, I'm using XML files as the backing store, so using select-for-update is not an option. /Rickard ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
