[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 10-January-2003
JBoss daily test results SUMMARY Number of tests run: 1050 Successful tests: 1042 Errors:7 Failures: 1 [time of test: 2003-01-10.08-22 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-01-10.08-22 for the junit report of this test. 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 Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file, from XMLMetaData: java.io.FileNotFoundException: http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_0.dtd; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file, from XMLMetaData: java.io.FileNotFoundException: http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_0.dtd)) - Suite: JarInSarJSR77UnitTestCase Test: testFakeParentCreatedAndRemoved(org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: fakeApp jsr-77 mbean is still present - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/usr/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: java.lang.NullPointerException Message: - Suite: MDBUnitTestCase Test:testQueue(org.jboss.test.mdb.test.MDBUnitTestCase) Type:error Exception: org.jboss.mq.SpyJMSException Message: Cannot get a client ID; - nested throwable: (javax.jms.JMSSecurityException: The login id has an assigned client id. That client id is already connected to the server!) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
This change appears to have broken the org.jboss.test.mdb.test.MDBUnitTestCase as seen
in the latest 3.2 test results. Look into this testcase please.
Suite: MDBUnitTestCase
Test:testQueue(org.jboss.test.mdb.test.MDBUnitTestCase)
Type:error
Exception: org.jboss.mq.SpyJMSException
Message: Cannot get a client ID; - nested throwable:
(javax.jms.JMSSecurityException: The login id has an assigned client
id. That client id is already connected to the server!)
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Igor Fedorenko" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 2:01 PM
Subject: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
> User: igorfie
> Date: 03/01/08 14:01:43
>
> Modified:src/main/org/jboss/ejb/plugins/jms Tag: Branch_3_2
> JMSContainerInvoker.java
> Log:
> Use ejb-name as a default for client-id, if mdb does durable topic subsction.
>
> Revision ChangesPath
> No revision
>
>
> No revision
>
>
> 1.50.2.1 +12 -3
>jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
>
> Index: JMSContainerInvoker.java
> ===
> RCS file:
>/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
> retrieving revision 1.50
> retrieving revision 1.50.2.1
> diff -u -r1.50 -r1.50.2.1
> --- JMSContainerInvoker.java 28 Jul 2002 04:14:38 - 1.50
> +++ JMSContainerInvoker.java 8 Jan 2003 22:00:42 - 1.50.2.1
> @@ -54,7 +54,7 @@
>/**
> * EJBProxyFactory for JMS MessageDrivenBeans
> *
> - * @version $Revision: 1.50 $
> + * @version $Revision: 1.50.2.1 $
> * @author mailto:[EMAIL PROTECTED]";>Peter Antman .
> * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
> * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
> @@ -458,9 +458,18 @@
> connection = tConnection;
>
> // Fix: ClientId must be set as the first method call after connection
>creation.
> - // Fix: ClientId is necessary for durable subscriptions.
> -
> + // Fix: ClientId must be unique among all applications.
> +
> String clientId = config.getClientId();
> + // ClientId is necessary for durable subscriptions.
> + if (clientId == null
> +&& config.getSubscriptionDurability() ==
>MessageDrivenMetaData.DURABLE_SUBSCRIPTION)
> + {
> +// use MDB ejb-name as default clientId
> +// Fix: ejb-name is not unique among all applications. Note however,
> +// it is not any worse then client id from jboss.xml.
> +clientId = config.getEjbName();
> + }
> log.debug("Using client id: " + clientId);
> if (clientId != null && clientId.length() > 0)
>connection.setClientID(clientId);
>
>
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> jboss-cvs-commits mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] One thing I like about the Apache thing
The important thing is to not put half of the GUI into Java classes, like most MVC frameworks. I took a look at Struts, but I assumed that it will create far too many classes and require restarting the web app over and over again (to reload the classes and/or the configuration file). A lot of my co-workers use Perl or PHP for their web pages and they would laugh their asses off. Pressing F5 must be enough. I'm using JSTL, writing both views and controller as JSPs (and a very limited number of helper beans). The model is all SLSBs/EBs in Jboss. That's enough stratification. Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Adam Heath Sent: Friday, January 10, 2003 03:51 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] One thing I like about the Apache thing On Thu, 9 Jan 2003, marc fleury wrote: > I was not aware of this. > > marcf > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of > > Scott M Stark > > Sent: Thursday, January 09, 2003 6:00 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] One thing I like about the Apache thing > > > > > > It is already there. Many times I have gone in and edited the > > jboss.org site content in the unpacked war to pick it changes. Its > > not even a redeployment. The web container watches the timestamps on > > the web content. We use symlinks. the web.war is a symlink to www in the development folder. We never have to redeploy, just to update some silly jsp. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] PHP
Hi, Is there some sort of benchmarking on the site as it is currently? It'd be cool to see a before and after picture. I'm not making any point or anything, its purely intellectual curiosity. -Andy marc fleury wrote: holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet <[EMAIL PROTECTED]> Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann <[EMAIL PROTECTED]> Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB> just found it: HB> XLVIII. Java HB> There are two possible ways to bridge PHP and Java: you can either integrate HB> PHP into a Java Servlet environment, which is the more stable and efficient HB> solution, or integrate Java support into PHP. The former is HB> provided by a SAPI module that interfaces with the Servlet server, HB> the latter by the Java HB> extension. HB> at: http://php.benscom.com/manual/kr/ref.java.php HB> bax Von: Holger Baxmann <[EMAIL PROTECTED]> Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: <[EMAIL PROTECTED]> Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the wor
RE: [JBoss-dev] Re: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Scott,
It looks like my change collided with change to MDBUnitTestCase made by ejort (Fix the
testsuite so that the cache is empty after the run). I'll try to fix this asap.
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 4:51 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Re: [jboss-cvs]
jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
This change appears to have broken the org.jboss.test.mdb.test.MDBUnitTestCase as seen
in the latest 3.2 test results. Look into this testcase please.
Suite: MDBUnitTestCase
Test:testQueue(org.jboss.test.mdb.test.MDBUnitTestCase)
Type:error
Exception: org.jboss.mq.SpyJMSException
Message: Cannot get a client ID; - nested throwable:
(javax.jms.JMSSecurityException: The login id has an assigned client
id. That client id is already connected to the server!)
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Igor Fedorenko" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 2:01 PM
Subject: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
> User: igorfie
> Date: 03/01/08 14:01:43
>
> Modified:src/main/org/jboss/ejb/plugins/jms Tag: Branch_3_2
> JMSContainerInvoker.java
> Log:
> Use ejb-name as a default for client-id, if mdb does durable topic subsction.
>
> Revision ChangesPath
> No revision
>
>
> No revision
>
>
> 1.50.2.1 +12 -3
>jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
>
> Index: JMSContainerInvoker.java
> ===
> RCS file:
>/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
> retrieving revision 1.50
> retrieving revision 1.50.2.1
> diff -u -r1.50 -r1.50.2.1
> --- JMSContainerInvoker.java 28 Jul 2002 04:14:38 - 1.50
> +++ JMSContainerInvoker.java 8 Jan 2003 22:00:42 - 1.50.2.1
> @@ -54,7 +54,7 @@
>/**
> * EJBProxyFactory for JMS MessageDrivenBeans
> *
> - * @version $Revision: 1.50 $
> + * @version $Revision: 1.50.2.1 $
> * @author mailto:[EMAIL PROTECTED]";>Peter Antman .
> * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
> * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
> @@ -458,9 +458,18 @@
> connection = tConnection;
>
> // Fix: ClientId must be set as the first method call after connection
>creation.
> - // Fix: ClientId is necessary for durable subscriptions.
> -
> + // Fix: ClientId must be unique among all applications.
> +
> String clientId = config.getClientId();
> + // ClientId is necessary for durable subscriptions.
> + if (clientId == null
> +&& config.getSubscriptionDurability() ==
>MessageDrivenMetaData.DURABLE_SUBSCRIPTION)
> + {
> +// use MDB ejb-name as default clientId
> +// Fix: ejb-name is not unique among all applications. Note however,
> +// it is not any worse then client id from jboss.xml.
> +clientId = config.getEjbName();
> + }
> log.debug("Using client id: " + clientId);
> if (clientId != null && clientId.length() > 0)
>connection.setClientID(clientId);
>
>
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> jboss-cvs-commits mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits
>
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: [JBoss-user] CMP on 3.0.4 with BLOB fields - has anyone seen it working?
The beans which worked on 3.0.2 and failed on 3.0.4 also fails on 3.0.5rc1 – I just tested that. I am forced to go back to 3.0.2 until the bug related to fields of type java.lang.Object is fixed. Randahl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Randahl Fink Isaksen Sent: 10. januar 2003 10:34 To: [EMAIL PROTECTED] Subject: [JBoss-user] CMP on 3.0.4 with BLOB fields - has anyone seen it working? I am wondering if anyone has got an EJB working on 3.0.4 with a property which is stored as a serialized java object. Even the EJBs that worked for me on 3.0.2 do no longer work on 3.0.4 if they have a property which is of some Serializable type which is converted to BLOB. I am using Sap DB. My previous post contains the exceptions I get on 3.0.4. Randahl
[JBoss-dev] RE: [JBoss-user] CMP on 3.0.4 with BLOB fields - has anyone seen it working?
That sure is a constructive suggestion. I currently use the default mapping which stores serialized java.lang.Object instances as LONG BINARY - is there a relevant alternative? Again, the mapping worked fine under 3.0.2 - what changed in 3.0.4? Would somebody please care to comment on that? Randahl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alex Loubyansky Sent: 10. januar 2003 11:02 To: Randahl Fink Isaksen Subject: Re: [JBoss-user] CMP on 3.0.4 with BLOB fields - has anyone seen it working? Hello Randahl, there are BLOB tests in the testsuit that pass successfully. So, I think your problem is a mapping. Have you tried different mapping? alex Friday, January 10, 2003, 11:34:19 AM, you wrote: RFI> I am wondering if anyone has got an EJB working on 3.0.4 with a property RFI> which is stored as a serialized java object. Even the EJBs that worked RFI> for me on 3.0.2 do no longer work on 3.0.4 if they have a property which RFI> is of some Serializable type which is converted to BLOB. I am using Sap RFI> DB. RFI> My previous post contains the exceptions I get on 3.0.4. RFI> Randahl --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 3.0.5: jbossweb-ejb.jar for datasources with name differentfrom DefaultDS
I am playing with JBoss 3.0.5 from CVS and have found that if I use the datasource name different from DefaultDS, I have to modify jaws.xml and jbosscmp-jdbc.xml inside the jbossweb-ejb.jar. Should we distribute this as directory instead of archive? Or better is it possible to remove/comment these default values from this jar and use default values from /conf directory? Vlad --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Paul Morris (rpmorris) Date: 2003-01-10 11:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 16:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663934 ] IllegalStateException in AbstractInstanceCache
Bugs item #663934, was opened at 2003-01-07 19:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Reich (sreich) >Assigned to: Adrian Brock (ejort) Summary: IllegalStateException in AbstractInstanceCache Initial Comment: When I run ECperf with a txrate of 20 on Jboss 3.0.RC2, the following exception pops up every once in a while: 18:55:19,504 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = 1041562119833 at org.jboss.ejb.plugins.AbstractInstanceCache.insert(AbstractInstanceCache.java:222) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSessionFilePersistenceManager.java:199) at org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441) at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessionContainer.java:763) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:128) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:62) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129) at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368) at org.jboss.ejb.Container.invoke(Container.java:730) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:554) -- >Comment By: Adrian Brock (ejort) Date: 2003-01-10 16:43 Message: Logged In: YES user_id=9459 Can you try this again with latest CVS. It should be fixed now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665870 ] Memory Leak...somewhere...
Bugs item #665870, was opened at 2003-01-10 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665870&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Leak...somewhere... Initial Comment: JBoss3.0.5 RC1 I do a lot of hot deployments. I'm in the final stages of my project and am making a lot of little minor changes to the html and webapp in tons of different areas so i'm doing 150-200 deployments per day. My ear contains 2 wars a bunch of support jars and an ejb jar with 40-50 beans, entity, statelesssession, mdbs and one sar. I leave jboss running all the time, with the amount of deployments i'm doing JBoss gets an OutOfMemoryError about once a day. I have not changed the default memory setting. I guess the problem could be anywhere in jboss because i hit many, many areas...but it seams to be brought out by the number of deployments i do. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665870&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [jboss-group] varia broken in the 3_0 branch.
I just updated and its building find. Post the error your seeing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Greg Wilkins" <[EMAIL PROTECTED]> To: "jboss-dev" <[EMAIL PROTECTED]> Sent: Friday, January 10, 2003 4:07 AM Subject: [jboss-group] varia broken in the 3_0 branch. > > The head of the 3_0 branch has been broken for a couple of > hours with compile erros in varia. > > -- > Greg Wilkins<[EMAIL PROTECTED]> Phone/fax: +44 7092063462 > Mort Bay Consulting Australia and UK. http://www.mortbay.com --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
or
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
or
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- Comment By: Michael Kloster (mikekloster) Date: 2003-01-10 19:03 Message: Logged In: YES user_id=685435 Scott M Stark, You wrote: "If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that." I have a a sample web application that can reproduce this problem (over time). The application consists only of JSP pages and images and has no dynamic content (unless you count the use of server side jsp includes). If I can show that this web application runs fine under Tomcat 4.x alone or JBoss 2.4, but does have the cause the submitters problem in JBoss 3.0.x will that satify your above stated requirement that this must be shown, in fact, to be a JBoss issue? If so, I will take the time to create and document this senario for you. thank you for your time and effort. Jboss is a wonderful product! Michael Kloster -- Comment By: Paul Morris (rpmorris) Date: 2003-01-10 16:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 21:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 20:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 20:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.N
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Scott M Stark (starksm) Date: 2003-01-10 11:31 Message: Logged In: YES user_id=175228 That should be fine. -- Comment By: Michael Kloster (mikekloster) Date: 2003-01-10 11:03 Message: Logged In: YES user_id=685435 Scott M Stark, You wrote: "If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that." I have a a sample web application that can reproduce this problem (over time). The application consists only of JSP pages and images and has no dynamic content (unless you count the use of server side jsp includes). If I can show that this web application runs fine under Tomcat 4.x alone or JBoss 2.4, but does have the cause the submitters problem in JBoss 3.0.x will that satify your above stated requirement that this must be shown, in fact, to be a JBoss issue? If so, I will take the time to create and document this senario for you. thank you for your time and effort. Jboss is a wonderful product! Michael Kloster -- Comment By: Paul Morris (rpmorris) Date: 2003-01-10 08:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 13:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.)
Re: [JBoss-dev] PHP
In the early days of Java, I read that a large retailer had about 70 Java programmers because it was "a business decision". It was the only tool available that they could use to integrate their systems. Most likely, Marc's decision to use PHP on the website is a business decision as well. The website has to be fluid, functional, and professional, require a mininum of time and attention, and it all has to be done Now. So Marc found a ready-made solution that will solve 80% of his requirements. The 20% that's missing is that it's not J2EE. JSP is relatively new compared to PHP, and JSP/JSTL is significantly more complex. It sounds like Mark has both an immediate plan and a vision for the future all based on real-world requirements and recent practical experience wrestling with the forums. It would be "nice" to see everything pure java. Marc says "we'll get there." He's got us this far, hasn't he? So having had our say (from the perspective of ones not paying the bills), I suggest we all just get back to work. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] PHP
Title: RE: Re[2]: [JBoss-dev] PHP +1. Very Nice. -Original Message- From: Adam Heath [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 6:04 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] PHP On Thu, 9 Jan 2003, marc fleury wrote: > Nukes on JBoss is going to be SUCH A GREAT PROJECT. Finally > ENTERPRISE CMS for the MASSES. Well, we have been playing with OFBiz(www.ofbiz.org) lately. It uses it's own entity engine(which I know you guys don't like), but their GenericValue objects are really easy to work with(no code to write). However, they have a very nice admin interface, and CMS. It's a full fledged shopping cart system. Products, categories, orders, tracking, warehousing, shipping. 450+ tables. Web template code, service engine, tons of stuff. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
I pulled out my changes. Sorry for the troubles.
-Original Message-
From: Igor Fedorenko
Sent: Friday, January 10, 2003 9:45 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Re: [jboss-cvs]
jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
Scott,
It looks like my change collided with change to MDBUnitTestCase made by ejort (Fix the
testsuite so that the cache is empty after the run). I'll try to fix this asap.
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 4:51 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Re: [jboss-cvs]
jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
This change appears to have broken the org.jboss.test.mdb.test.MDBUnitTestCase as seen
in the latest 3.2 test results. Look into this testcase please.
Suite: MDBUnitTestCase
Test:testQueue(org.jboss.test.mdb.test.MDBUnitTestCase)
Type:error
Exception: org.jboss.mq.SpyJMSException
Message: Cannot get a client ID; - nested throwable:
(javax.jms.JMSSecurityException: The login id has an assigned client
id. That client id is already connected to the server!)
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: "Igor Fedorenko" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 08, 2003 2:01 PM
Subject: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
> User: igorfie
> Date: 03/01/08 14:01:43
>
> Modified:src/main/org/jboss/ejb/plugins/jms Tag: Branch_3_2
> JMSContainerInvoker.java
> Log:
> Use ejb-name as a default for client-id, if mdb does durable topic subsction.
>
> Revision ChangesPath
> No revision
>
>
> No revision
>
>
> 1.50.2.1 +12 -3
>jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
>
> Index: JMSContainerInvoker.java
> ===
> RCS file:
>/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java,v
> retrieving revision 1.50
> retrieving revision 1.50.2.1
> diff -u -r1.50 -r1.50.2.1
> --- JMSContainerInvoker.java 28 Jul 2002 04:14:38 - 1.50
> +++ JMSContainerInvoker.java 8 Jan 2003 22:00:42 - 1.50.2.1
> @@ -54,7 +54,7 @@
>/**
> * EJBProxyFactory for JMS MessageDrivenBeans
> *
> - * @version $Revision: 1.50 $
> + * @version $Revision: 1.50.2.1 $
> * @author mailto:[EMAIL PROTECTED]";>Peter Antman .
> * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
> * @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
> @@ -458,9 +458,18 @@
> connection = tConnection;
>
> // Fix: ClientId must be set as the first method call after connection
>creation.
> - // Fix: ClientId is necessary for durable subscriptions.
> -
> + // Fix: ClientId must be unique among all applications.
> +
> String clientId = config.getClientId();
> + // ClientId is necessary for durable subscriptions.
> + if (clientId == null
> +&& config.getSubscriptionDurability() ==
>MessageDrivenMetaData.DURABLE_SUBSCRIPTION)
> + {
> +// use MDB ejb-name as default clientId
> +// Fix: ejb-name is not unique among all applications. Note however,
> +// it is not any worse then client id from jboss.xml.
> +clientId = config.getEjbName();
> + }
> log.debug("Using client id: " + clientId);
> if (clientId != null && clientId.length() > 0)
>connection.setClientID(clientId);
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Broken links - Re: [JBoss-dev] PHP problems
On Thu, 9 Jan 2003, marc fleury wrote: > [snip] Hmm. There broken links on the site. Some stale .jsp(team.jsp(from the front page) is a 404). --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 13:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Bill Burke (patriot1burke)
Date: 2003-01-10 17:30
Message:
Logged In: YES
user_id=176497
This is simulated XA dude.You can use ANY jdbc driver. The
XADataSourceLoader wraps a plain old JDBC driver and
simulates an XA resource.
AGAIN. YOU MUST USE XADataSourceLoader if you want
transaction support with your Entity Beans Just use it. IT
WILL WORK!
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 18:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 13:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Broken links - Re: [JBoss-dev] PHP problems
We are fixing them ASAP. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Adam > Heath > Sent: Friday, January 10, 2003 4:14 PM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: Broken links - Re: [JBoss-dev] PHP problems > > > On Thu, 9 Jan 2003, marc fleury wrote: > > > [snip] > > Hmm. There broken links on the site. Some stale > .jsp(team.jsp(from the front > page) is a 404). > > > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 15:46
Message:
Logged In: YES
user_id=51762
I'm trying to use the XA method, but now I get a ton of these:
[15:41:13,994,XAConnectionFactory] XAConnectionImpl:
org.jboss.pool.jdbc.xa.wrapper.XAConnectionImpl@c0f2e5 has
no current tx!
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-10 14:30
Message:
Logged In: YES
user_id=176497
This is simulated XA dude.You can use ANY jdbc driver. The
XADataSourceLoader wraps a plain old JDBC driver and
simulates an XA resource.
AGAIN. YOU MUST USE XADataSourceLoader if you want
transaction support with your Entity Beans Just use it. IT
WILL WORK!
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 10-January-2003
JBoss daily test results SUMMARY Number of tests run: 1012 Successful tests: 1006 Errors:5 Failures: 1 [time of test: 2003-01-10.14-55 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-10.14-55 for details of this test. 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 Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: HttpsUnitTestCase Test:testHttpsURL(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.io.IOException Message: Failed to get SSLContext for TLS algorithm - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBossMQ
Your kinda right. the loop is there for the case where the destination is
queue based (p2p and durable subs). The polling happens when the queue is
full. Now when the queue is not full (or in the pub sub case, there is no
queue), then the thread goes into asynch mode and it waits for the message
to get delivered async via the ClientIL.receive method. I'll comment the
code a little:
// gets the next message in queue or registers us for asynch delivery
if none available.
mes = session.connection.receive( subscription, 0 );
if ( mes == null ) // should always be null for pub-sub case.
{
// start waiting for the message to get delivered asynch
waitingForMessage = true;
while ( ( messages.isEmpty() && !closed ) || ( !session.running ) )
{
try
{
// messages gets signaled once ClientIL.receive finishes
processing the message.
messages.wait();
} catch ( InterruptedException e )
{
}
}
if ( closed )
{
waitingForMessage = false;
break outer;
}
// the message sent via ClientIL.receive should now be sitting in
messages
mes = ( SpyMessage )messages.removeFirst();
waitingForMessage = false;
}
I hope that helped! I think the XIL is great idea! We might even be able
to develop a c base API to access mq services (important in the integration
space).
Regards,
Hiram
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of John
> Fawcett
> Sent: Thursday, January 09, 2003 8:09 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] JBossMQ
>
>
> Hi,
>
> I am working on a new invocation layer (IL) for JbossMQ that encodes all
> communication in Xml (XIL). I've got the IL pretty near completion, and
> I am working on a C# jbossmq client. I am trying to develop the
> TopicSubsciber, which is an extension of MessageConsumer. In reviewing
> the code in the jbossmq java sources, it looks to me like the client to
> a topic actually runs a loop sending receive requests to the server
> regularly.
>
> Is this really necessary? Once the connection has been established, why
> can't the server just invoke the ClientIL.receive method (which actually
> sends the message to the client) when a message arrives at the
> destination?
> It looks to me like the current implementation is not truly
> asynchronous...
> What am I missing?
>
> Thanks,
> fawce
>
>
> -
> John Fawcett
> CTO, Tamale Software, LLC
> 26 Fox Road
> Waltham, MA 02451
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == Finished 'most' in module 'console'. == == _module-console-most: [copy] Copying 5 files to /home/jboss/jbossci/jboss-head/build/output/testbuild/bin [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/server/all/lib [copy] Copying 2 files to /home/jboss/jbossci/jboss-head/build/output/testbuild/server/all/deploy == == == Executing 'most' in module 'security'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-parsers: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/security/output/parsers/org/jboss/security/auth/login [javacc] Java Compiler Compiler Version 2.0 (Parser Generator) [javacc] Copyright (c) 1996-2000 Sun Microsystems, Inc. [javacc] Copyright (c) 1997-2000 Metamata, Inc. [javacc] (type "javacc" with no arguments for help) [javacc] Reading from file /home/jboss/jbossci/jboss-head/security/src/main/org/jboss/security/auth/login/SunConfigParser.jj . . . [javacc] File "TokenMgrError.java" does not exist. Will create one. [javacc] File "ParseException.java" does not exist. Will create one. [javacc] File "Token.java" does not exist. Will create one. [javacc] File "ASCII_CharStream.java" does not exist. Will create one. [javacc] Parser generated successfully. compile-classes-jdk13: [echo] Compiling for JDK1.3 do-compile: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/security/output/classes [unjar] Expanding: /home/jboss/jbossci/jboss-head/server/output/lib/jboss-security.jar into /home/jboss/jbossci/jboss-head/security/output/classes [javac] Compiling 138 source files to /home/jboss/jbossci/jboss-head/security/output/classes /home/jboss/jbossci/jboss-head/security/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java:229: cannot resolve symbol symbol : method getValidKeys () location: class org.jboss.util.TimedCachePolicy validPrincipals = tcache.getValidKeys(); ^ 1 error BUILD FAILED file:/home/jboss/jbossci/jboss-head/security/build.xml:162: Compile failed; see the compiler error output for details. Total time: 1 minute 53 seconds --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] unsubscribe
- Original Message -
From: "Scott M Stark" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 3:21 PM
Subject: [JBoss-dev] Re: [jboss-cvs]
jboss/src/main/org/jboss/ejb/plugins/jms JMSContainerInvoker.java
> This change appears to have broken the
org.jboss.test.mdb.test.MDBUnitTestCase as seen
> in the latest 3.2 test results. Look into this testcase please.
>
> Suite: MDBUnitTestCase
> Test:testQueue(org.jboss.test.mdb.test.MDBUnitTestCase)
> Type:error
> Exception: org.jboss.mq.SpyJMSException
> Message: Cannot get a client ID; - nested throwable:
(javax.jms.JMSSecurityException: The login id has an assigned client
> id. That client id is already connected to the server!)
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
> - Original Message -
> From: "Igor Fedorenko" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 08, 2003 2:01 PM
> Subject: [jboss-cvs] jboss/src/main/org/jboss/ejb/plugins/jms
JMSContainerInvoker.java
>
>
> > User: igorfie
> > Date: 03/01/08 14:01:43
> >
> > Modified:src/main/org/jboss/ejb/plugins/jms Tag: Branch_3_2
> > JMSContainerInvoker.java
> > Log:
> > Use ejb-name as a default for client-id, if mdb does durable topic
subsction.
> >
> > Revision ChangesPath
> > No revision
> >
> >
> > No revision
> >
> >
> > 1.50.2.1 +12 -3
jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.java
> >
> > Index: JMSContainerInvoker.java
> > ===
> > RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jms/JMSContainerInvoker.
java,v
> > retrieving revision 1.50
> > retrieving revision 1.50.2.1
> > diff -u -r1.50 -r1.50.2.1
> > --- JMSContainerInvoker.java 28 Jul 2002 04:14:38 - 1.50
> > +++ JMSContainerInvoker.java 8 Jan 2003 22:00:42 - 1.50.2.1
> > @@ -54,7 +54,7 @@
> >/**
> > * EJBProxyFactory for JMS MessageDrivenBeans
> > *
> > - * @version $Revision: 1.50 $
> > + * @version $Revision: 1.50.2.1 $
> > * @author mailto:[EMAIL PROTECTED]";>Peter Antman .
> > * @author mailto:[EMAIL PROTECTED]";>Rickard
Öberg
> > * @author mailto:[EMAIL PROTECTED]";>Sebastien
Alborini
> > @@ -458,9 +458,18 @@
> > connection = tConnection;
> >
> > // Fix: ClientId must be set as the first method call after
connection creation.
> > - // Fix: ClientId is necessary for durable subscriptions.
> > -
> > + // Fix: ClientId must be unique among all applications.
> > +
> > String clientId = config.getClientId();
> > + // ClientId is necessary for durable subscriptions.
> > + if (clientId == null
> > +&& config.getSubscriptionDurability() ==
MessageDrivenMetaData.DURABLE_SUBSCRIPTION)
> > + {
> > +// use MDB ejb-name as default clientId
> > +// Fix: ejb-name is not unique among all applications.
Note however,
> > +// it is not any worse then client id from
jboss.xml.
> > +clientId = config.getEjbName();
> > + }
> > log.debug("Using client id: " + clientId);
> > if (clientId != null && clientId.length() > 0)
> >connection.setClientID(clientId);
> >
> >
> >
> >
> >
> > ---
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > ___
> > jboss-cvs-commits mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits
> >
>
>
>
> ---
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
