If anyone else wants to contribute to Performance Tuning documentation
JBAS-8009, lets coordinate our efforts. I would like to do most of the
documentation work with DocBook
later upload to docs.jboss.org. If there is interest in doing the work
online, let me know and I will upload the current content sooner rather
Let me know your interest and I will deal with any coordination. Even
if your not contributing right away, let me know your interest.
I've just updated the AS trunk with new Scanning lib.
It also includes some other MC changes: Reflect, MDR, Kernel, CL, Deployers.
Apart from AnnotationRepository (which was already there with the old code),
I've also hacked around Hibernate's Scanner a bit, so it uses new scanning lib's ScannerImpl.
(the hack is mostly in place due to some impl issues in Hibernate itself, Emmanuel is working on it)
JSF can now use new JBossAnnotationProvider -- let me know how that goes Stan.
And web can use ResourcesIndex from DeploymentUnit -- Remy.
WeldScanningPlugin is currently commented out.
We need to disable one of the deployers in plugin's favor.
Pete, let me know when the new Weld release is coming in,
and I'll enable the plugin + run a few tests.
All in all, if you spot any issues / regressions wrt this change,
let me know, and I'll try to fix the stuff asap.
I'm not aware of a specific JIRA filed for the clustering regressions but
been noting other test regressions since this change here:
JBoss, by Red Hat
----- Original Message -----
From: "Jaikiran Pai" <jpai(a)redhat.com>
To: "JBoss.org development list" <jboss-development(a)lists.jboss.org>
Cc: "Brian Stansberry" <bstansbe(a)redhat.com>
Sent: Monday, June 7, 2010 1:38:18 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jboss-dev] new scanning in AS trunk
Is there a JIRA around this one? We are seeing similar clustering
deployment failures in our EJB3 build environment. I haven't yet looked
into the details to see what exactly causes the issue.
Brian Stansberry wrote:
> Still fails.
> I don't think the problem is on the JPA side -- or at least that's not
> the obvious surface problem. The persistence unit deployment seems to go ok.
> The obvious surface problem is that during the deployment there is no
> logging by any EJB3 related deployers. The session beans the test
> invokes on are not getting deployed.
> On 06/03/2010 03:17 PM, Ales Justin wrote:
>> The JPA has known issues:
>> ALR already fixed this with new jpa.vfs3 release.
>> And Shelly just confirmed this now works as expected.
>> The new jsp.vfs3 lib is already commited into c-m/pom.xml.
>> Can you try it and let us know if this also works for you?
>> On Jun 3, 2010, at 10:07 PM, Brian Stansberry wrote:
>>> The tests artifacts are jars that all have this structure:
>>> ++ MANIFEST.MF (w/ nothing interesting
>>> ++ persistence.xml
>>> where some of the classes are entities and some are annotated EJB3
>>> session beans. No ejb-jar.xml or jboss.xml.
>>> The testsuite/output/lib/clusteredentity-test.jar is a good example.
>>> In some but not all tests the jar is packaged in an ear along with a
>>> There's no EJB3 deployer logging, so perhaps the scanning isn't picking
>>> up the EJB annotations?
>>> On 06/03/2010 03:01 PM, Brian Stansberry wrote:
>>>> Following this commit (r105574), the tests in the
>>>> o.j.t.clustered.clusteredentity package started failing. I brought an
>>>> AS checkout up to the commit before that (r105506) and they pass, but
>>>> with the r105574 commit they start failing.
>>>> The tests deploy ejb3 jars with persistence units included. The tests
>>>> are failing because the EJBs are not bound in JNDI. Looking at the logs
>>>> there are no obvious failures during the artifact deployments. But
>>>> there's no logging from any EJB3 deployers, just from Hibernate.
>>>> On 06/02/2010 08:26 AM, Ales Justin wrote:
>>>>> I've just updated the AS trunk with new Scanning lib.
>>>>> It also includes some other MC changes: Reflect, MDR, Kernel, CL,
>>>>> Apart from AnnotationRepository (which was already there with the
>>>>> old code),
>>>>> I've also hacked around Hibernate's Scanner a bit, so it uses new
>>>>> scanning lib's ScannerImpl.
>>>>> (the hack is mostly in place due to some impl issues in Hibernate
>>>>> itself, Emmanuel is working on it)
>>>>> JSF can now use new JBossAnnotationProvider -- let me know how that
>>>>> goes Stan.
>>>>> And web can use ResourcesIndex from DeploymentUnit -- Remy.
>>>>> WeldScanningPlugin is currently commented out.
>>>>> We need to disable one of the deployers in plugin's favor.
>>>>> Pete, let me know when the new Weld release is coming in,
>>>>> and I'll enable the plugin + run a few tests.
>>>>> All in all, if you spot any issues / regressions wrt this change,
>>>>> let me know, and I'll try to fix the stuff asap.
>>>>> jboss-development mailing list
>>> Brian Stansberry
>>> Lead, AS Clustering
>>> JBoss by Red Hat
>>> jboss-development mailing list
jboss-development mailing list
Is there a way to add maven-driven tests to AS6 build that interact with
AS6? I just have no desire to hack up the beast that is the test module.
JBoss, a division of Red Hat
Ok, I have a clean AS trunk tree plus I deleted the whole of my m2 repo
(to avoid a ridiculous numbers of failed downloads due to checksum
errors -- that's not supposed to happen with maven is it?). I still get
a build error:
does not exist/.
I have been doing some work on profiling and optimizing the jboss-dependency project  for kernel 2.2.0.Alpha6 and it seems to have had a small, but still measurable impact :-)
I did a few startups of AS with jboss kernel 2.2.0.Alpha5 and with a local snapshot. This snapshot contains the work done for Alpha6 with the addition of removing the break in the resolveContexts loop as mentioned in the forum thread.
The startups were done on a freshly rebooted machine with nothing else running. The startup orders are given in brackets, so I started Alpha5 twice, then SNAPSHOT twice and so on.
One strange thing is that the first time I started each server they took loads longer than the other times, does somebody know the reason for that?
Ignoring those initial times leaves me with average start times of:
I'm going to have a final look at jboss-dependency to see if there are any other obvious and easy fixes before moving on to have a look at jboss-kernel.
We've currently got a failing build in our AS/trunk Hudson runs due to a
regression in the Embedded module.
In order to cut build time by default, I'd initially made the profile
which executes the Embedded integration suite disabled by default. It
is, however, a prerequisite to commit that we run this locally first.
For the sake of keeping the builds clean, I'm thinking it might make
more sense to enable these tests by default, and optionally skip them if
you provide a sysprop at the command-line:
mvn install -DskipEmbedded=true
Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat