[Fwd: Re: Possible blocker with jboss-cl 2.2.0.Alpha1 [WAS]: Hudson Jobs Hanging]
by Adrian Brock
This should be on the dev-list.
Please stop sending me private e-mails about opensource
development.
-------- Forwarded Message --------
From: Adrian Brock <abrock(a)redhat.com>
To: Brian Stansberry <brian.stansberry(a)redhat.com>
Cc: Thomas Diesler <thomas.diesler(a)jboss.com>, Jason T. Greene
<jason.greene(a)redhat.com>, Ales Justin <ajustin(a)redhat.com>, Thomas
Diesler <tdiesler(a)redhat.com>, Jason Greene <jgreene(a)redhat.com>, Carlo
de Wolf <cdewolf(a)redhat.com>
Subject: Re: [jboss-dev] Possible blocker with jboss-cl 2.2.0.Alpha1
[WAS]: Hudson Jobs Hanging
Date: Tue, 09 Feb 2010 11:50:10 +0100
On Mon, 2010-02-08 at 22:02 -0600, Brian Stansberry wrote:
> We need the EJB3 testsuite to run so we can validate the current
> Hibernate integration, and it's unable to run properly due to this
> problem. So, I've reverted AS trunk back to 2.0.8. If we can get a
> jboss-cl release that doesn't have the problem we can look at upgrading.
>
> Carlo said he'd have some cycles to look at this tomorrow if you need help.
>
> I don't have an opinion re: 2.0.x vs 2.2.x; you folks know better than I.
>
This behaviour hasn't changed between 2.0.x and 2.2.x
In both cases you'd be trying to load a class from a classloader that
has been shutdown.
The only thing I can think has changed is previously BaseClassLoader
was incorrectly throwing IllegalStateException instead of
ClassNotFoundException.
https://jira.jboss.org/jira/browse/JBCL-138
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-cl/trun...
There is however a change in behaviour since jboss-4.2.x in that
you could always load java.lang.* classes even when the classloader
was shutdown.
This was because of a shortcut in the old UCL classloader:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/Branch_4_2/jm... to workaround this problem:
https://jira.jboss.org/jira/browse/JBAS-4536
which doesn't exist with the new classloader when correctly configured.
I can restore the 4.2.x behaviour, but I don't think it
is the real problem?
In both examples on JBAS-7688, it would still fail if it tried to
load a common/lib class at that point, e.g. javax.ejb.*
or any other class not in the classloader that is shutdown.
--
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx
15 years, 11 months
Possible blocker with jboss-cl 2.2.0.Alpha1 [WAS]: Hudson Jobs Hanging
by Brian Stansberry
Thanks, Jaikiran. I'm forwarding this to the jboss-dev list for greater
visibility.
The EJB3 team is seeing consistent failures where a server thread is
unable to load classes from rt.jar. These occur in a test where a remote
client makes requests against a service that is concurrently being
undeployed. Failure is quite similar to what is seen at
https://jira.jboss.org/jira/browse/JBAS-7688 and previously mentioned on
this list.[1]
I've elevated JBAS-7688 to Blocker; we'll have to get comfortable early
next week that this isn't due to the jboss-cl 2.2.0.Alpha1 upgrade, fix
jboss-cl 2.2.0, or roll back AS trunk to 2.0.8.GA.
[1]
http://lists.jboss.org/pipermail/jboss-development/2010-February/015693.html
On 02/06/2010 09:24 AM, Jaikiran Pai wrote:
> I switched one of the jobs (which i have been using for testing) on Mike
> to 2.0.8.GA of jbcl and haven't seen this hang in those. However, the
> other job which is using 2.2.0.Alpha1 is consistently hanging with the
> same exception being thrown. I have tried to reproduce this locally, but
> haven't been able to do so (i.e. the test runs fine with 2.2.0.Alpha1 on
> my local setup).
>
> The exception stacktrace (as Carlo posted earlier) seems to be
> originating from a remoting thread which is doing some marshalling and
> running into CNFE (all these CNFE classes so far have been the ones
> residing in rt.jar). I took a thread dump of the server, at the time
> when Mike was hung during this testcase - couldn't find anything useful
> in there. Perhaps, i should be taking a thread dump of the JVM on the
> client (the JUnit testcase), to see what it is waiting on. At the same
> time, David mentions[1] that:
>
> "I hypothesize that the classloader is (sometimes) being destroyed
> before the thread gets going, causing it to be unable to load anything
> at all."
>
> I'll see if i can figure out:
>
> 1) Whether that statement applies to this testcase too
> 2) Why this happens specifically in this testcase
>
>
>
> [1]
> http://lists.jboss.org/pipermail/jboss-development/2010-February/015694.html
>
>
> regards,
> -Jaikiran
> Brian Stansberry wrote:
>> On 02/04/2010 12:18 PM, Jaikiran Pai wrote:
>>> Mike is running into this again
>>> http://mike.lab.bos.redhat.com:8380/hudson/job/EJB3_1-1.0.3-JBoss-AS-6.x-...
>>>
>>>
>>>
>>> The https://jira.jboss.org/jira/browse/EJBTHREE-1982 has linked
>>> JBKERNEL-86 as one of the problems. JBKERNEL-86 is marked as fixed in
>>> 2.2.0.alpha-4 of MC kernel. The current AS trunk has 2.2.0-alpha-5. But
>>> we are still seeing the same hang. So i guess there's more to it.
>>> Looking at the logs (attached) i don't see an explicit OOM, but i do see
>>> signs of it (like CNFE on a com.sun.* class after numerous deploys).
>>
>> On the face of it that sounds like a different problem. Occam's razor
>> say's it's not, but a CNFE seems like a different beast than a memory
>> leak.
>>
>> Possibly the CNFE is due to the jboss-cl upgrade to 2.2.0.Alpha1? See
>> https://jira.jboss.org/jira/browse/JBAS-7688 for another issue where
>> after that change classes in rt.jar weren't available.
>>
>> The AS should run fine w/ it's jboss-cl moved back to 2.0.8.GA, so
>> this theory is testable.
>
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 11 months
JBossOSGi 1.0.0.Beta6 Released
by Thomas Diesler
I am happy to announce the release of JBossOSGi-1.0.0.Beta6
<http://jbossosgi.blogspot.com/2010/02/jbossosgi-100beta6-released.html>.
The release comes with improvements in the following areas
* Initial support for fragments.
* Initial support for Bundle.update().
* Initial support for native code libraries.
* Support for R3 bundles.
* Support for bundle header localization.
* Improved Blueprint support, using Apache Aries Blueprint.
For details please have a look at the latest version of our User Guide
<http://jbmuc.dyndns.org/jboss-osgi-1.0.0.Beta6/userguide/html/>.
cheers
-thomas
PS: I'm also happy to tell you that with Beta5 we had 4800+ downloads in
just under 8 weeks.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
15 years, 11 months
VFS Abstraction Work in EJB 3.0
by John Bailey
I just wanted to make sure we are all on the same page with regard to the development of the VFS abstraction in EJB 3.0. After our discussions last week, I was under the impression I would be doing the development of the abstraction. This morning there was an initial commit from Carlo. Am I still correct in assuming I will be working on this?
--
John Bailey
JBoss by Red Hat
--
15 years, 11 months
AS localhost:8080
by Kabir Khan
When you start up AS trunk and go to localhost:8080 you get a page with links:
--------------
JBoss Online Resources
• JBoss AS Documentation
• JBoss Wiki
• JBoss JIRA
• JBoss Forums
JBoss Management
• Tomcat status (full) (XML)
• JMX Console
-----------------
I think admin-console should be added to this list
15 years, 11 months
Shrinkwrap in AS testsuites
by Jaikiran Pai
Hello everyone,
In most of the testcases that i have been introducing in EJB3
components, these days i usually use Shrinkwrap
http://www.jboss.org/shrinkwrap to skip the ant scripts. I was thinking
of doing the same in AS testusite. If no one has any objection, i will
add this as a dependency to the testsuite, the next time i write a test
there. By the way, those of you who would want to continue using Ant
scripts can still do so - Shrinkwrap usage would be optional.
regards,
-Jaikiran
15 years, 11 months
M2 is approaching!
by Brian Stansberry
The scheduled release date for AS 6.0.0.M2 is Monday Feb 15. This is
fundamentally a time-boxed release, so I want to stick to that. So, to
have time to get the release out, please plan on having any work for M2
done by Thur Feb 11 at 1 PM EST.
JIRA shows 60 open issues sheduled for M2.[1] I doubt all those will be
completed; please have a look at any assigned to you and reschedule any
that you won't complete. If there are any critical or blocker issues you
won't complete, please let me know ASAP.
Also, a call for help! The redesignation last fall of 5.1.0 as 6.0.0.M1
and 6.0.0.Alpha1 as 6.0.0.M3 has left a bit of a mess in JIRA. There are
183 issues closed with Fix Version 6.0.0.M3.[2] That's obviously
incorrect; these were issues fixed over the months on trunk and closed
against the old 6.0.0.Alpha1. I've manually fixed quite a few and will
fix as many as I can, but if folks can spend a couple minutes and fix a
few you personally worked, that will help me a lot. I've tried to get a
mass fix done in the database, but so far without result.
[1]
https://jira.jboss.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hi...
[2] https://jira.jboss.org/jira/browse/JBAS/fixforversion/12312794
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 11 months
AS testsuite -- shutdown.sar fails to stop 'minimal'
by Brian Stansberry
Adrian,
Today the AS testsuite runs on hudson are starting to fail
intermittently[1] due to the jboss-minimal-tests target's shutdown.sar
not stopping the AS. There seems to be a classloading problem when
ExitOnShutdown's anonymous Runnable tries to execute.[2]
I looked at a successful run going back a month and the WARN in the
logging below was there, so that's not new.
JIRA for this is https://jira.jboss.org/jira/browse/JBAS-7688
[1] https://hudson.jboss.org/hudson/job/JBoss-AS-6.0.x-testSuite-sun16/537/
https://hudson.jboss.org/hudson/job/JBoss-AS-6.0.x-testSuite-sun16/539/
[2]
2010-02-02 04:58:17,623 DEBUG
[org.jboss.test.jmx.shutdown.ExitOnShutdown] (HDScanner) Stopping
jboss.test:name=ExitOnShutdown
2010-02-02 04:58:17,624 WARN
[org.jboss.virtual.plugins.context.AbstractVirtualFileHandler]
(HDScanner) No such existing handler, falling back to old root + path:
vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/org/jboss/test/jmx/shutdown/ExitOnShutdown$1.class
2010-02-02 04:58:17,636 DEBUG
[org.jboss.test.jmx.shutdown.ExitOnShutdown] (HDScanner) Stopped
jboss.test:name=ExitOnShutdown
2010-02-02 04:58:17,636 DEBUG [org.jboss.system.ServiceController]
(HDScanner) destroying service: jboss.test:name=ExitOnShutdown
2010-02-02 04:58:17,637 DEBUG [org.jboss.system.ServiceController]
(HDScanner) removing service: jboss.test:name=ExitOnShutdown
2010-02-02 04:58:17,637 DEBUG [org.jboss.system.ServiceCreator]
(HDScanner) Removing mbean from server: jboss.test:name=ExitOnShutdown
2010-02-02 04:58:17,642 DEBUG
[org.jboss.deployers.structure.spi.helpers.AbstractDeploymentContext]
(HDScanner) Removed component jboss.test:name=ExitOnShutdown from
vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/
2010-02-02 04:58:17,647 DEBUG
[org.jboss.aop.asintegration.jboss5.RegisterModuleCallback] (HDScanner)
Removing module VFSDeploymentClassLoaderPolicyModule shutdown.sar:0.0.0
2010-02-02 04:58:17,647 DEBUG
[org.jboss.classloader.spi.base.BaseClassLoaderDomain] (HDScanner)
ClassLoaderDomain@1f8bd0d{DefaultDomain} unregisterClassLoader
BaseClassLoader@8c1852{vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/}
2010-02-02 04:58:17,648 DEBUG
[org.jboss.mx.loading.UnifiedLoaderRepository3] (HDScanner)
UnifiedLoaderRepository removed(false) null
2010-02-02 04:58:17,649 DEBUG
[org.jboss.classloader.spi.base.BaseClassLoaderPolicy] (HDScanner)
VFSClassLoaderPolicy@190ed52{vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/}
shutdown!
2010-02-02 04:58:17,649 DEBUG
[org.jboss.classloader.spi.base.BaseClassLoader] (HDScanner)
BaseClassLoader@8c1852{vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/}
shutdown!
2010-02-02 04:58:17,650 DEBUG
[org.jboss.classloading.spi.dependency.Domain] (HDScanner)
org.jboss.classloading.spi.dependency.Domain@3a6e5c{DefaultDomain}
remove module VFSDeploymentClassLoaderPolicyModule shutdown.sar:0.0.0
2010-02-02 04:58:17,650 DEBUG
[org.jboss.deployers.vfs.plugins.classloader.InMemoryClassesDeployer]
(HDScanner) Removing dynamic class root for
vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/
2010-02-02 04:58:17,658 DEBUG
[org.jboss.deployers.plugins.deployers.DeployersImpl] (HDScanner) Fully
Undeployed
vfszip:/mnt/hudson_workspace/workspace/JBoss-AS-6.0.x-testSuite-sun16/JBossAS/build/target/jboss-6.0.0-SNAPSHOT/server/minimal/deploy/shutdown.sar/
2010-02-02 04:58:17,674 ERROR [STDERR] (ExitOnShutdown) Exception in
thread "ExitOnShutdown" java.lang.NoClassDefFoundError: java/lang/System
2010-02-02 04:58:17,675 ERROR [STDERR] (ExitOnShutdown) at
org.jboss.test.jmx.shutdown.ExitOnShutdown$1.run(ExitOnShutdown.java:52)
2010-02-02 04:58:17,676 ERROR [STDERR] (ExitOnShutdown) at
java.lang.Thread.run(Thread.java:619)
2010-02-02 04:58:17,676 ERROR [STDERR] (ExitOnShutdown) Caused by:
java.lang.ClassNotFoundException: Class not found java.lang.System
2010-02-02 04:58:17,676 ERROR [STDERR] (ExitOnShutdown) at
org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:892)
2010-02-02 04:58:17,677 ERROR [STDERR] (ExitOnShutdown) at
org.jboss.classloader.spi.base.BaseClassLoader.doLoadClass(BaseClassLoader.java:522)
2010-02-02 04:58:17,677 ERROR [STDERR] (ExitOnShutdown) at
org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:467)
2010-02-02 04:58:17,677 ERROR [STDERR] (ExitOnShutdown) at
java.lang.ClassLoader.loadClass(ClassLoader.java:252)
2010-02-02 04:58:17,678 ERROR [STDERR] (ExitOnShutdown) at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
2010-02-02 04:58:17,678 ERROR [STDERR] (ExitOnShutdown) ... 2 more
2010-02-02 04:59:47,314 INFO
[org.jboss.bootstrap.impl.base.server.AbstractServer] (Thread-5)
Stopping: JBossAS [6.0.0.SNAPSHOT (build: SVNTag=JBoss_6.0.0-SNAPSHOT
date=r100244)]
2010-02-02 04:59:47,314 DEBUG
[org.jboss.bootstrap.impl.as.lifecycle.AbstractKernelEventLifecycleEventHandler]
(Thread-5) Fired:
AbstractEvent@a801b0{source=org.jboss.kernel.plugins.event.AbstractEventManager(a)1fe0816
type=org.jboss.system.server.stopped seq=0 time=1265104787314
context=1265104787314}
2010-02-02 04:59:47,314 DEBUG
[org.jboss.bootstrap.impl.base.server.AbstractServer] (Thread-5) Sent
JMX Notification: org.jboss.system.server.stopped
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat
15 years, 11 months
Javaee Spec Jars
by Paul Gier
Hi everyone,
There was some discussion about naming conventions and svn structure for the
javaee api spec projects this morning. There is also more info in jira [1].
Here is the plan at this point.
GroupId: org.jboss.spec.<sun groupId>
ArtifactId: <spec name>_<spec version>_spec
Version: Standard OSGI versions starting with 1.0.0
For example:
<dependency>
<groupId>org.jboss.spec.javax.servlet</groupId>
<artifactId>servlet-api_2.5_spec</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
The structure in svn will look similar to the structure that the geronimo
project uses for their spec jars [2]. Meaning that each spec version will have
a separate trunk and a separate release cycle.
In addition to deploying the spec jars (and pom) to the Maven repository, there
will also be an aggregate pom, but not an aggregate jar. The aggregate pom will
be a project with packaging "pom" and will list each included spec in the
dependencyManagement and dependencies sections. This will allow the app server
build to declare a single dependency on the combined javaee pom and it will
automatically get all the individual spec jars added to the dependency tree.
Going forward, we would like to have all spec jars in same area in svn, and each
will have it's own release lifecycle and projects that need the spec jars can
either depend on the individual jars or on the aggregator pom.
[1]https://jira.jboss.org/jira/browse/JBEE-15
[2]http://svn.apache.org/repos/asf/geronimo/specs/trunk/
15 years, 11 months
