Bootstrap times
by Adrian Brock
After Sacha's "the AS is hanging" thread
last week, I've created some simple stats
to show the times spent in deployers
and the microcontainer state transfers.
See attached for the full stats
(this is the default configuration).
DEPLOYERS
For the deployers you can see
the big hits are in the expected
bean and jmx deployers which do
most of the work.
Other hits include annotation scanning,
classloader creation and surprisingly
the ejb3 deployer (there are no ejb3 deployments? :-).
ANNOTATION DEPLOYER
Drilling down in the annotation scanning,
you can see most time is spent in
jbossweb.sar, console-mgr.sar and jbossws.sar
Making these metadata complete would knock
something like 7-8 seconds off the bootstrap time.
CLASSLOADER DEPLOYER
Most of the time in the classloader bucket
is spent processing conf/jboss-service.xml
so this is a function of the number of jars
in server/default/lib, i.e. determining
what packages they contain.
EJB3 DEPLOYER
A lot of time in the EJB3 bucket is taken on
jbossweb.sar (nearly a second?), but
there are others where it is taking upto
a quarter of second.
RAR PARSER DEPLOYER
Although, it doesn't take much time,
this looks less efficient than the other
parsers. I'd guess there is some inefficiency
due it using the old ObjectModelFactory
instead of annotations? e.g. maybe it
is reconstructing the schema binding on
every request or parsing the schema?
KERNEL
The kernel reports show more details
of the stages for beans/jmx and more
of a summary for the deployers (i.e.
it shows the deployment stages rather
than individual deployers).
A quick guide to the states:
Real = Real deployers
PostClassLoader = annotation scanning
Start = bean/jmx.start()
Described = bean/jmx metadata analysis
Instantiated = object construction
Parse = Parsing deployers
ClassLoader = ClassLoading deployers
Create = bean/jmx.create()
etc.
REAL
The biggest hit is the Real stage.
But there will be some double
counting here. e.g. the real stage
of a bean/jmx will also show up in
Instantiated/Create/Start/etc.
Also, the times will include dependencies.
e.g. the starting of the transaction
manager will start a lot of other services.
Creating some of the deployers is showing
more time than I would expect?
jboss-jca is obviously slow since it is the
only one using JAXB instead of JBossXB,
so it has to load all those classes,
but why does aop, ejb3, web take more than
one second to just create the deployers?
POSTCLASSLOADER
This is the annotation scanning again
START
This is obviously where a lot of
services do things, but again the
WARDeployer is showing as quite high up?
DESCRIBED
There is nothing in here that is
very big, but it does include
the aop annotation scanning for beans,
so there are lots of small bits
that add up.
TODO
I'll let you look at the numbers
yourselves, in particular the parts
you are responsible for and see
whether you can explain it,
you're happy with it or there
is something strange going on.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 6 months
Remoting shutdown errors and warnings
by Adrian Brock
This has been around for over a week without anybody fixing it,
so I guess whoever is responsible doesn't know about it?
The errors are logged when you shutdown the server
so it isn't validated by the testsuite.
15:15:34,249 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=bisocket,host=127.0.0.1,port=4457,JBM_clientMaxPoolSize=200,clientLeasePeriod=10000,clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper,dataType=jms,marshaller=org.jboss.jms.wireformat.JMSWireFormat,numberOfCallRetries=1,numberOfRetries=10,pingFrequency=214748364,pingWindowFactor=10,socket.check_connection=false,stopLeaseOnFailure=true,timeout=0,unmarshaller=org.jboss.jms.wireformat.JMSWireFormat is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
15:15:34,302 WARN [StartStopLifecycleAction] Error during stop for
org.jboss.ejb3.RemotingConnector
java.lang.NoSuchFieldError: m_map
at
org.jboss.remoting.transport.socket.LRUPool.getContents(LRUPool.java:81)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.cleanup(SocketServerInvoker.java:437)
at
org.jboss.remoting.transport.socket.SocketServerInvoker.stop(SocketServerInvoker.java:404)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1111)
15:15:38,353 ERROR [Connector] invalid Object Name
javax.management.InstanceNotFoundException:
jboss.remoting:service=invoker,transport=socket,host=127.0.0.1,port=4446,dataType=invocation,enableTcpNoDelay=true,marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller is not registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at
org.jboss.remoting.util.SecurityUtility.unregisterMBean(SecurityUtility.java:538)
at
org.jboss.remoting.transport.Connector.stop(Connector.java:1103)
at
org.jboss.remoting.transport.Connector.destroy(Connector.java:1167)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 6 months
Re: Inappropriate proxying of subscription only mailing list WAS Re: [JBoss-dev] jmx clustering
by Adrian Brock
Ok, thanks for the information.
So nabble isn't serving as proxy, but it is by
far the biggest source of off-topic posts.
On Mon, 2008-09-08 at 21:19 -0700, Nabble Support wrote:
> No, the user will have to subscribe to the list in order to post to
> it. If the list requires subscription, and if the user does not
> subscribe, his post will be rejected as non-subscriber post.
>
> Regards,
> support
>
> On Mon, Sep 8, 2008 at 1:03 AM, Adrian Brock <abrock(a)redhat.com> wrote:
> > On your website you allow your users to post
> > to the jboss-development(a)lists.jboss.org mailing list.
> >
> > You must be subscribed to this mailing list to post to it.
> >
> > Why are you allowing people that have not subscribed
> > to this mailing list to post to it via your website?
> > http://www.nabble.com/JBoss---Dev-f2633.html
> >
> > We are now being "spammed" by many posts from your
> > website that would be more appropriate on
> > jboss-user(a)lists.jboss.org or the user forums:
> > http://www.jboss.com/index.html?module=bb&op=main&c=5
> >
> > Please make this forum "read only" on your
> > website or if that is not possible, remove it.
> >
> > jnl1 - the above is not aimed at you.
> > But the developer's mailing list for the jboss appserver
> > is not the appropriate place for your question, try the user forums
> > linked above.
> >
> > On Sun, 2008-09-07 at 16:23 -0700, jnl1 wrote:
> >> hi all...question on clustering. currently, i have a jmx process that
> >> handles processing of jobs. for example a report. right not, it's running
> >> in a single node, single jboss instance. we're moving to a multi node
> >> configuration and was wondering what impacts there might be.
> >>
> >> for example...if i submit a report and it's running, how does the other
> >> nodes know that the report is already being processed. i'm thinking in a
> >> multi node env, the different jmx processes will 'crash' into each other.
> >> looking around, it looks like i could use a singleton. but, wasn't sure if
> >> i'm off base.
> >>
> >> can someone point me down the right path..documentation, examples on what's
> >> different in a clustered env for jmx processes.
> >>
> >> thx in adv
> >>
> >>
> > --
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Adrian Brock
> > Chief Scientist
> > JBoss, a division of Red Hat
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 6 months
jmx clustering
by jnl1
hi all...question on clustering. currently, i have a jmx process that
handles processing of jobs. for example a report. right not, it's running
in a single node, single jboss instance. we're moving to a multi node
configuration and was wondering what impacts there might be.
for example...if i submit a report and it's running, how does the other
nodes know that the report is already being processed. i'm thinking in a
multi node env, the different jmx processes will 'crash' into each other.
looking around, it looks like i could use a singleton. but, wasn't sure if
i'm off base.
can someone point me down the right path..documentation, examples on what's
different in a clustered env for jmx processes.
thx in adv
--
View this message in context: http://www.nabble.com/jmx-clustering-tp19319061p19319061.html
Sent from the JBoss - Dev mailing list archive at Nabble.com.
14 years, 6 months
where is this source 1.3 coming from?
by Scott Stark
I'm not able to compile the jboss-man project currently because
something is pulling in a -source 1.3 setting which does not work with
annotations.
[531][valkyrie: trunk]$ mvn compile
[INFO] Scanning for projects...
[INFO] NOTE: Using release-pom:
/Users/svn/JBossAS/projects/jboss-man/trunk/release-pom.xml in reactor
build.
[INFO] NOTE: Using release-pom:
/Users/svn/JBossAS/projects/jboss-man/trunk/metatype/release-pom.xml in
reactor build.
[INFO] NOTE: Using release-pom:
/Users/svn/JBossAS/projects/jboss-man/trunk/managed/release-pom.xml in
reactor build.
[INFO] NOTE: Using release-pom:
/Users/svn/JBossAS/projects/jboss-man/trunk/build/release-pom.xml in
reactor build.
[INFO] Reactor build order:
[INFO] JBoss Metatype
[INFO] JBoss Managed
[INFO] JBoss Managed Distribution Build
[INFO] JBoss Managed Parent POM
[INFO]
------------------------------------------------------------------------
[INFO] Building JBoss Metatype
[INFO] task-segment: [compile]
[INFO]
------------------------------------------------------------------------
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 53 source files to
/Users/svn/JBossAS/projects/jboss-man/trunk/metatype/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/Users/svn/JBossAS/projects/jboss-man/trunk/metatype/src/main/java/org/jboss/metatype/api/annotations/CompositeKey.java:[35,1]
annotations are not supported in -source 1.3
(try -source 1.5 to enable annotations)
@Target({ElementType.METHOD})
/Users/svn/JBossAS/projects/jboss-man/trunk/metatype/src/main/java/org/jboss/metatype/plugins/types/DefaultMetaTypeFactory.java:[91,72]
generics are not supported in -source 1.3
14 years, 6 months
Re: [jboss-dev] Towards AS5 CR2
by Alexey Loubyansky
There are a few issues left in metadata.
This one is assigned to Dimitris:
JBMETA-63 jboss-metadata imports deprecated jboss-jaxws.jar artifact
And this one is assigned to Scott:
JBMETA-39 jboss-client_5_0.xsd element order should not be required as
its inconsistent with previous dtds
I can have a look into JBMETA-39. Other issues are minor. So, as soon as
these are done/postponed, metadata can be released.
Alexey
Sacha Labourey wrote:
> Then does it mean we can do the other releases earlier i.e.
>
> First Scott has to do this:
>> jboss-managed/metatype (scott)
>
> Then Adrian could do this:
>> jboss-vfs (ales)
>> jboss-deployers (ales)
>> jboss-microcontainer (ales)
>
> Then, as soon as Paul has refactored, Adrian or Ales can do this:
>> jboss-reflect (ales)
>> jboss-mdr (ales)
>
> Could Scott, Alexey and Andrew comment on when they think this could be
> released?
>> jboss-classloading (scott)
>> jboss-metadata (alexey)
>> jboss-aspects (andrew)
>> ejb3 (carlo)
>
> I am very much impatient as you can see :)
>
>
>> -----Original Message-----
>> From: jboss-dev-all-bounces(a)redhat.com [mailto:jboss-dev-all-
>> bounces(a)redhat.com] On Behalf Of Kabir Khan
>> Sent: mercredi, 3 septembre 2008 11:58
>> To: Adrian Brock
>> Cc: JBoss AS; R&D All; JBoss.org development list
>> Subject: Re: [jboss-dev] Towards AS5 CR2
>>
>>> the main issue remaining is Kabir closing (or deferring) the
>>> long standanding AOP integration task:
>>> https://jira.jboss.org/jira/browse/JBMICROCONT-75
>>> which depends upon some open AOP issues:
>>> https://jira.jboss.org/jira/browse/JBAOP-88
>>> https://jira.jboss.org/jira/browse/JBAOP-230
>> Closed
>
14 years, 7 months
How do you split your classes?
by Sacha Labourey
Team,
I am interesting in better understanding how you take decisions when
splitting classes between JARs. Let me be more accurate...
Ideally, each macro-service (Tomcat, WS, EJB3, etc.) would have its own
MyService.sar file/directory in /deploy (or better, /deploy/system/). This
SAR would contain all required implementation classes, services definition,
etc. and would also list its dependencies in one of its jboss-services.xml
<depends> tags. Then, if for some reasons this service needed to share some
API classes with other services AND it was using some separate unified
classloader, it could "pollute" the AS at large by putting these classes in
the /lib folder of the AS. The outcome of this is that it would be very easy
to remove a service: simply drop its folder from /deploy and that's it
(modulo the potential pollution taking place in /lib).
Now, we all know this is NOT how it happens in real-life. Hence, my
question: WHY? What leads you to do things differently? I'd like to
understand it better so we can potentially improve things.
It is worth mentioning that this is the pre-AS5 situation. With AS5 and its
new classloaders à la OSGI, it is going to be possible to put EVERYTHING in
specific directories in /deploy thanks to the import/export features Adrian
has implemented. Consequently, outside of core services (specific deployers
or any bootstrap code à la VFS, etc.), no JAR should be needed in /lib.
Thanks for your feedback. Cheers,
sacha
14 years, 7 months
Fixing JBAS-5908 on trunk
by Galder Zamarreno
Hi,
Re: https://jira.jboss.org/jira/browse/JBAS-5908
To fix this in trunk, I need to modify ServerVMClientUserTransaction in
projects/integration/, commit it, get a new release of integration for
inclusion in trunk and then commit ClientUserTransactionObjectFactory
changes in trunk.
Who do I need to coordinate with to get this done?
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 7 months
