Small boottime improvement
by Kabir Khan
I have been doing some work on profiling and optimizing the jboss-dependency project [1] 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.
2.2.0-Alpha5
----------------------
37s:247ms (1)
20s:573ms (2)
20s:275ms (5)
20s:127ms (7)
20s:433ms (9)
20s:329ms (10)
20s:890ms (13)
2.2.0-SNAPSHOT
------------------------
29s:563ms (3)
19s:965ms (4)
19s:821ms (6)
20s:332ms (8)
19s:618ms (10)
19s:905ms (12)
19s:900ms (14)
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:
Alpha5: 20s437ms
SNAPSHOT: 19s923ms
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.
[1] http://community.jboss.org/message/525047#525047
14 years, 9 months
VFS3 Integration in JBoss AS Trunk
by John Bailey
As discusses previously, the VFS3 integration in JBoss AS is planned for for Monday, March 1st. At this point we have all the dependent projects released with the necessary VFS3 changes integrated. So we should be all set to start the integration on Monday.
There will be a lot of changes to merge in, so I ask that all commits to AS trunk be suspended durning the integration. So if you could please have all outstanding changes committed by 4PM UTC on Monday. The goal is to have changes to the trunk suspended no more than 48 hours. I will send out a notice as soon as it is available, which hopefully will be earlier than planned.
Also, I have created a job on the hudson server to run the AS testsuite against the VFS3 integration branch. There are currently around 30 test failures. I will get the job results published to the hudson.jboss.org site so all can see the failures. I have identified the root cause of several of the failures, but I would appreciate it if everyone can take a look and see if anything jumps out.
Let me know if you have any questions or concerns.
Thanks,
--
John Bailey
JBoss by Red Hat
--
15 years
Refactoring packaging/packages to reduce "signed jar groups"
by Mike Clark
Hey folks,
The general purpose of this note is to explore refactoring some of our
jars to reduce some problems that have come about due to our signing of
jars.
So, let me start with a description of the problem. Essentially, the
core issue is around the simple replacement of an EAP signed jar with an
unsigned jar. While we have a system in place to have QE get one-off
patches signed in a relatively responsive manner, we are still left with
cases such as a diagnostic jar created by support to track down
problems, or a customer that, understanding that it would not be
supported, wishes to make a change for their system (one of the
advantages of OSS, of course).
The problem with such a substitution is the fact that a classloader will
not load classes from a packages that appear in differently signed
jars. So, for example, even though class org.jboss.A may only occur in
an unsigned A.jar, loading it will cause a security exception if class
org.jboss.B was loaded from a signed B.jar. Now, the first step to
resolve this would be to replace both A.jar and B.jar with unsigned
versions. But, we then often run into a transitive entanglement. B.jar
may contain classes from package org.jboss, but also org.hibernate. So,
you have to have unsigned versions of C.jar and D.jar that contain the
hibernate packages. But, they have an org.apache package, and so on.
Using TattleTale with some custom reports, I generated "signed jar
groups" identifying clusters of jars that would need to all be replaced
as unsigned if any one is unsigned. For the largest group, I created a
graph of the dependencies shown in
http://community.jboss.org/wiki/SignedJarDependenciesExample
(getopt_jar_Group.png, named by the first jar listed in the group from
the report.)
The figure shows the jars with a line connecting them if they have one
or more packages in common (I also generate detailed plots with a
labelled line for each package in common if anyone wants to see them,
but for the "getopt" group, the detailed plot is quite large and hard to
read.) Clearly, lots of unrelated jars are wound up in this group.
But, we can chip away at this with a bit of analysis. I'll give three
examples.
First, consider the set of jar files just to the right of the center
grouped around jboss-ejb3-core.jar. This set of jars is tied into the
rest of the graph through the connection between
jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them is
org.jboss.as.javaee. In this case there appears to be only two classes
involved. In jboss.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
jboss-as-ejb3-deployer.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
class). So, in this case, we can break off a chunk of the signed jar
group by, for example, changing a package name:
org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
Next, from the graph, we can see that there is a group of jar files on
the far left that is tied in by a connection between the
jboss-system-jmx.jar and the jboss.jar. In this case, the package is
org.jboss.deployment. There are several classes in jboss.jar and a
handful in jboss-system-jmx.jar that are in this package. So, options
might include renaming the package for the classes in the
jboss-system-jmx.jar, moving them to jboss.jar, or separating the
org.jboss.deployment classes between them into a new jar:
jboss-deployment.jar.
Finally, staying on the far left of the graph we see that run.jar and
shutdown.jar are tied into some third party jars such as getopt.jar,
hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
default package. Further, the default package is included because the
contents of the getopt.jar are incorporated into run.jar and
shutdown.jar. So, this connection to third party jars can be broken out
by removing the GetOpt related classes from run.jar and shutdown.jar and
relying on the Class-Path: attribute in their manifests.
So, in the end, it would seem to be beneficial to refactor package
locations such that there is not such widespread entanglement. From the
signed jar perspective, it would be best if each package only appeared
in one jar. Of course, there are often engineering reasons to separate
classes in the same package into different jars. However, I think it's
not unreasonable that these should be relatively small in number and
they should be functionally coherent. At any rate, it would appear to
be something we could attack incrementally as indicated by the three
examples above.
Originally, when discussing this with other folks, we thought perhaps we
should just open jiras to address the problem. But, on considering
that, it seemed that perhaps a discussion on a larger game plan would be
a better approach, even if it just ended up with the original plan of
opening some jiras to "chip away" at the problem.
So, I apologize for a long, dense note. For those of you that made it
through, any thoughts, suggestions?
Cheers,
Mike C.
15 years
M3 Planning and Timeline
by Jason T. Greene
Hello everyone,
Thanks again for all the hard work on M2. Now that it's out the door,
it's time to look at our plan/goals for M3.
The tentative code/component freeze date for M3 is March 22. Please let
me know what updates you feel comfortable including in this release.
Ideally we would be able to deliver:
- Completed HornetQ Integration
- Remoting 3 Integration
- Various major EJB 3.1 features
Let me know your thoughts on this.
Thanks!
--
Jason T. Greene
JBoss, a division of Red Hat
15 years, 1 month
Community wiki and linking to anchors
by Vladimir Blagojevic
Hi,
Any idea how to create html links to an anchor across different articles on our community wiki? Do you have an example?
Cheers,
Vladimir
15 years, 1 month
Byteman 1.2.2 release now available
by Andrew Dinn
The 1.2.2 Byteman release is now available for download. It includes a
small number of bug fixes as well as a few interesting additional
features, most notably:
the problem which was causing rule injection into superclasses to fail
intermittently (BYTEMAN-80) has been resolved. more importantly, the fix
has avoided adding significant costs to class loading. So it is still
possible to inject rule code through interfaces and down class
hierarchies without seriously perturbing execution of the original
application.
expressions in rule scripts may now employ the new operator(BYTEMAN-85)
and the assignment (=) operator (BYTEMAN-81), with the usual Java syntax
and semantics. assignment can be used to modify the value of all rule
bindings
* variables introduced in the BINDS clause
* trigger method local variables: $i, $myString etc
* trigger method parameters: $1, $myParam (but not $this/$0 which
is implicitly final)
* the stacked trigger method return value: $! (only available in AT
EXIT rules)
note also that in the latter three cases assignment does not just reset
the value used to resolve references in subsequent rule expressions. it
also updates the local state of the trigger method. the assigned values
will be employed on resumption of the method to resolve references to
local or parameter variables or to supply the result returned to its caller.
regards,
Andrew Dinn
-----------
15 years, 1 month
Re: [jboss-dev] Remoting behavior on error (Re: Possible blocker with jboss-cl 2.2.0.Alpha1)
by Jaikiran Pai
The mailing list doesn't allow me to attach anything more than 500KB. So
the log has been sent to Ron and the rest of the reply follows:
I don't think it's going to be too useful because the log level is set
to INFO and as i mentioned in the earlier part of the mail - the logging
itself seems to be a bit messed up. I haven't yet been able to reproduce
this locally. The test run on our build setup reproduces this
consistently, so we can enable DEBUG level logging of remoting, the next
time we start the test run.
One thing to note is that the ServerThread catches a "Exception" and
later down the flow closes the socketwrapper:
processInvocation(socketWrapper, inputStream, outputStream);
}
catch (Exception ex)
{
if (running)
{
log.error(this + " exception occurred during first
invocation", ex);
running = false;
}
else
{
log.debug(this + " exception occurred during first
invocation", ex);
}
}
....// some more code
log.debug(this + " closed socketWrapper: " + desc);
The closing of the socketwrapper will be skipped in case of "Error" like
the NCDFE.
regards,
-Jaikiran
>
> Ron Sigal wrote:
>> In fact, ServerThread should close the socket when the attempt to
>> write generates an exception.
>>
>> Jaikiran, do you have a server.log? It should have the output of
>>
>> log.debug(this + " closed socketWrapper: " + desc);
>>
>> -Ron
>>
>> Carlo de Wolf wrote:
>>> I also want to raise how Remoting should behave when it encounters
>>> such an error.
>>> I would like to see it close the socket outright, because now the
>>> client goes into a hang state.
>>>
>>> Carlo
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
15 years, 1 month
Weird boolean expressions
by David M. Lloyd
Every now and then I'll see a commit go by with code looking like this:
if (some.methodCall().foo() == false)
or
boolean something = Foo.bar() ? true : false
What is the point of these silly redundant expressions? This is beyond
code style and into the realm of superstition or something. We are all
professional programmers, and should have a thorough understanding of
boolean expressions at this point. Java is the common language that we all
speak - I don't think we need to dumb it down to this degree.
Everyone has their own preferences when it comes to formatting,
arrangement, even some coding techniques or patterns, but this is a bit
silly, wouldn't you say?
- DML
15 years, 1 month
Renaming server/web to server/jbossweb-standalone
by Jason T. Greene
In order to prevent confusion between server/web and the EE web profile,
I would like to rename server/web to be jbossweb-standalone, since this
is what it is currently being used for.
Any objections?
--
Jason T. Greene
JBoss, a division of Red Hat
15 years, 1 month
