[JBoss Microcontainer Development] New message: "Optimizing aop lifecycle"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Optimizing aop lifecycle":
http://community.jboss.org/message/518307#518307
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
My original plan was to just hard-code the annotation plugins on startup, but I then realised that we probably still want to be able to deploy them. So, when this is parsed:
<lifecycle-configure
name="LifecycleCallback"
class="org.jboss.test.microcontainer.support.LifecycleCallbackWithBeanDependency"
classes="@org.jboss.test.microcontainer.support.Lifecycle">
</lifecycle-configure>
A bean called LifecycleCallback implemented by LCWDB is installed (as before), and an instance of LifecycleAnnotationPlugin handling @Lifecycle is added by the LifecycleBinding bean.
Previously instead of LAPlugin the LifecycleBinding bean installed a lifecycle pointcut to the AspectManager, and pointcut matching was done as part of AOPDependencyBuilder using the info from the AspectManager. AOPDepBuilder would create a LifecycleAspectDependencyBuilderListItem which would set up the correct dependencies and set up the lifecycle callback items in the matching context's dependency info. Lifecycle calbacks would then be invoked by AbstractController.handleLifecycleCallbacks().
Now instead of the AOPDepBuilder doing fancy and heavy pointcut matching to determine lifecycle callbacks, the LifecycleAnnotationPlugin is invoked as part of DescibeAction.applyAnnotations() -> BeanAnnotationAdapter.applyAnnotations().
If we deploy a bean that has the @Lifecycle annotation BAA picks that up and it is handled by LifecycleAnnotationAdapter which uses LifecycleAspectDependencyBuilderListItem to set up the dependencies and dependency info as before. I just used LADBLI since the code was already there, but am planning to refactor that somehow
Anyway, the question I really had was: am I ok to expose the add/removeAnnotationPlugin() methods in the BeanAnnotationAdapter interface?
Code from LifecycleBinding:
public void start() throws Exception
{
.....
if (!classes.startsWith("@"))
throw new IllegalArgumentException("Could not parse '" + classes + " into an annotation. (It must start with '@')");
String annotationName = classes.substring(1);
Class<Annotation> clazz = null;
try
{
clazz = (Class<Annotation>)SecurityActions.getContextClassLoader().loadClass(annotationName);
}
catch (Exception e)
{
throw new IllegalArgumentException("An error occurred loading '" + classes + "'", e);
}
LifecycleAspectDependencyBuilderListItem item = new LifecycleAspectDependencyBuilderListItem(callbackBean, state, installMethod, uninstallMethod);
plugin = new LifecycleAnnotationPlugin<Annotation>(clazz, item);
getBeanAnnotationAdapter().addAnnotationPlugin(plugin);
}
public void stop() throws Exception
{
if (plugin != null)
getBeanAnnotationAdapter().removeAnnotationPlugin(plugin);
}
@SuppressWarnings("unchecked")
private CommonAnnotationAdapter<AnnotationPlugin<?, ?>, MetaDataVisitor> getBeanAnnotationAdapter()
{
BeanAnnotationAdapter adapter = BeanAnnotationAdapterFactory.getInstance().getBeanAnnotationAdapter();
if (adapter instanceof CommonAnnotationAdapter == false)
throw new IllegalArgumentException("Adapter is not an instance of CommonAnnotationAdapter");
return (CommonAnnotationAdapter<AnnotationPlugin<?,?>, MetaDataVisitor>)adapter;
}
public class LifecycleAnnotationPlugin<C extends Annotation> extends ClassAnnotationPlugin<C> implements CleanablePlugin
{
Logger log = Logger.getLogger(LifecycleAnnotationPlugin.class);
private final DependencyBuilderListItem item;
private final Set<KernelControllerContext> handledContexts = new ConcurrentSet<KernelControllerContext>();
public LifecycleAnnotationPlugin(Class<C> annotation, DependencyBuilderListItem item)
{
super(annotation);
if (item == null)
throw new IllegalArgumentException("Null dependency builder list item");
this.item = item;
}
@Override
protected List<? extends MetaDataVisitorNode> internalApplyAnnotation(ClassInfo info, MetaData retrieval, C annotation, KernelControllerContext context) throws Throwable
{
item.addDependency(context);
handledContexts.add(context);
return null;
}
@Override
protected void internalCleanAnnotation(ClassInfo info, MetaData retrieval, C annotation, KernelControllerContext context) throws Throwable
{
item.removeDependency(context);
handledContexts.remove(context);
}
public void clean()
{
for (KernelControllerContext context : handledContexts)
{
try
{
internalCleanAnnotation(null, null, null, context);
}
catch(Throwable t)
{
log.warn("An error occurred cleaning " + context, t);
}
}
}
}
The clean() method is called by CommonBeanAnnotationAdapter.removeAnnotationPlugin() to make sure that we remove the dependency from the contexts affected by the annotation.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518307#518307
14 years, 3 months
New password
by do-not-reply＠jboss.com
Your new passsword: *dexdxEf
14 years, 3 months
[JBoss Remoting Development] Document updated/added: "R3.1 Remote Protocol Specification"
by David Lloyd
JBoss development,
The document "R3.1 Remote Protocol Specification", was updated Jan 4, 2010
by David Lloyd.
To view the document, visit:
http://community.jboss.org/docs/DOC-14535#cf
Document:
--------------------------------------------------------------
h1. Remote Protocol Specification
h2. Table of Contents
*
#Remote_Protocol_Specification
**
#Table_of_Contents
**
#Overview
**
#Message_Format
***
#Framing
***
#Header
****
#First_and_Last_Markers
****
#End_of_Data_Marker
***
#Flow_Control
**
#Negotiation
**
#Security
***
#Confidentiality
***
#Authentication
**
#Remoting_Clients
**
#Remoting_Requests_And_Replies
h2. Overview
The "remote" protocol is the protocol by which two Remoting 3 endpoints may be connected to communicate with one another. The protocol requirements are:
1. Security: provide authentication and confidentiality support for clients and servers
2. Concurrency: allow multiple clients and requests to be active concurrently
3. Streaming: allow embedded streams
4. Efficiency: Make requests as compact as possible.
5. Performance: Provide equivalent or better latency characteristics than Remoting 2.
h2. Message Format
h3. Framing
Since the "remote" protocol is a message-oriented protocol, and TCP is a stream-oriented protocol, an additional level of framing is required. The "remote" protocol uses a simple length-data framing scheme.
Bit #:
7 6 5 4 3 2 1 0
Byte# +---+---+---+---+---+---+---+---+
0 | Length (MSB) |
+-------------------------------+
1 | Length (LSB) |
+-------------------------------+
2+ | Data ... |
| |
: :
. .
Since every message has a predetermined length, the TCP_NODELAY socket option should *always* be employed to minimize message transmission latency on send.
h3. Header
All regular messages in the "remote" protocol have a common structure. They are all preceded by a message header, which associates the message with a specific request, client, or stream channel.
Bit #:
7 6 5 4 3 2 1 0
Byte# +---+---+---+---+---+---+---+---+
0 | L | F | A | X | L.Ch.ID (MSB) |
+---+---+---+---+---+---+---+---+
1 | Local Channel ID (LSB) |
+---+---+---+---+---+---+---+---+
2 | X | X | D | E | R.Ch.ID (MSB) |
+---+---+---+---+---+---+---+---+
3 | Remote Channel ID (LSB) |
+-------------------------------+
4 | Data... |
: :
. .
The meaning of each field is as follows:
* *X* - Reserved, set to 0 for forward compatibility.
* *L* - "Last", indicates that this message will be the last in the stream; once
* *F* - "First", indicates that this message is the first message in this direction for a channel pair.
* *A* - "Acknowledge", indicates that a previously received message should be acknowledged (see *flow control* for more information).
* *D* - "Data", a marker which indicates that the message contains a data message (with a length of zero or more).
* *E* - "End-of-data", a marker which indicates the end of a substream.
* *Source Channel ID* - the channel ID of the sender.
* *Destination Channel ID* - the channel ID of the recipient.
A subchannel is uniquely identified by a source/destination channel ID pair, not unlike how unique TCP connections are identified. This means that more than one source channel ID can be connected to a destination channel ID, and there can be more than one connection with the same source ID, so long as the destination channel ID is different between each connection.
h4. First and Last Markers
The First and Last markers on a message delineate the beginning and ending of a connection. Once a Last marker is read on the remote side, no further data will be received on the channel. When a Last marker is both sent and received, the associated channel ID pair becomes free for reuse.
h4. End of Data Marker
The End-of-data marker does not have a significance to the overall protocol; it is used by the transport to mark the end of a message. The bit will be set on the last packet of such a message.
h3. Flow Control
Flow control is accomplished by two mechanisms. The first is a negotiated limit on the number of allowed concurrent subchannels. When this limit is reached, the peer interested in establishing a new subchannel is forced to wait. If the peer ignores the subchannel limit, the connection may be terminated immediately.
The second mechanism is a fixed window size associated with each subchannel. For a subchannel with a window size of +N+, each peer may send up to +N+ messages on that subchannel without waiting for an "acknowledge" reply. Further messages may not be sent until a message is received with the "A" bit set, at which time exactly one message is considered to be acknowledged. If the window size for a subchannel is disregarded, the connection may be terminated immediately.
Such an acknowledgement may be sent in conjunction with a data message travelling in the opposite direction, or it may be sent as a standalone (dataless) message.
h2. Negotiation
In order to reach agreement on what features should be available on the connection (selecting a marshaller, agreeing on parameters such as class tables and so forth), a negotiation phase is employed after authentication completes but before requests may be transferred.
h2. Security
h3. Confidentiality
Confidentiality protection is implemented via TLS. All TLS authentication options are supported, including but not limited to client authentication via TLS. These connection parameters may be specified as options when the connection is created.
h3. Authentication
Server authentication occurs naturally via the TLS server certificate validation process. While clients may also be authenticated via this process, SASL-based authentication is also performed by the server. If, for some reason, client authentication is not desired via SASL, then a NULL SASL mechanism should be selected. If both client and server authentication is desired via SASL, then an appropriate mechanism supporting both should be chosen.
h2. Remoting Clients
h2. Remoting Requests And Replies
--------------------------------------------------------------
14 years, 3 months
New password
by do-not-reply＠jboss.com
Your new passsword: bDs9aLkg
14 years, 3 months
[JBoss Build System Development] New message: "Remove ejb3/build.xml in AS trunk?"
by jaikiran pai
JBoss development,
A new message was posted in the thread "Remove ejb3/build.xml in AS trunk?":
http://community.jboss.org/message/518159#518159
Author : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran
Message:
--------------------------------------------------------------
In the current AS trunk, i see that we are moving away from the build.xml and instead using the pom.xml to manage packaging of modules. For example, the ejb3/pom.xml http://anonsvn.jboss.org/repos/jbossas/trunk/ejb3/pom.xml has this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>create-output</id>
<goals>
<goal>run</goal>
</goals>
<phase>package</phase>
<configuration>
<tasks>
<mkdir dir="target/etc"/>
<copy todir="target/etc" filtering="yes">
<fileset dir="src/etc">
<include name="**"/>
</fileset>
</copy>
<mkdir dir="target/resources"/>
<copy todir="target/resources" filtering="yes">
<fileset dir="src/resources">
<include name="**"/>
</fileset>
</copy>
<unjar src="${maven.dependency.org.jboss.ejb3.jboss-ejb3-core.jar.path}" dest="target/resources">
<patternset>
<include name="*.xml" />
<exclude name="META-INF/*.xml" />
<include name="META-INF/*.properties" />
</patternset>
</unjar>
<mkdir dir="target/ejb3.deployer"/>
<copy todir="target/ejb3.deployer">
<fileset dir="target">
<include name="jboss-as-ejb3-deployer.jar"/>
</fileset>
<fileset dir="target/resources">
<include name="META-INF/ejb3-deployers-jboss-beans.xml"/>
<include name="META-INF/jpa-deployers-jboss-beans.xml"/>
</fileset>
<fileset dir="target/resources">
<include name="META-INF/persistence.properties"/>
</fileset>
</copy>
<copy todir="target">
<fileset dir="target/resources">
<include name="ejb3-container-jboss-beans.xml"/>
<include name="ejb3-connectors-jboss-beans.xml"/>
<include name="ejb3-interceptors-aop.xml"/>
</fileset>
</copy>
</tasks>
</configuration>
</execution>
Would it be better to just delete the ejb3/build.xml to avoid the confusion? I learnt the hard way that the build.xml was no longer being used.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518159#518159
14 years, 3 months
[JBoss ESB Development] New message: "Performance: XMLBeans vs JAXB"
by Daniel Bevenius
JBoss development,
A new message was posted in the thread "Performance: XMLBeans vs JAXB":
http://community.jboss.org/message/518147#518147
Author : Daniel Bevenius
Profile : http://community.jboss.org/people/beve
Message:
--------------------------------------------------------------
I've been looking into startup and deployment time as part of the ongoing performance work that David and I are working on.
I wanted to see if replacing XMLBeans, which is used for the internal configuration model (jboss-esb.xml), with JAXB would help improve our startup and deployment time.
First lets look at the startup time, and begin with the existing XMLBeans version
Below are the XMLBeans entries that showed up as hotspot when starting the application server with the default JBoss ESB services (i.e no custom .esb archives deployed). You can find the jprofiler results http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/performance/p....
Startup of JBoss ESB on JBoss AS 4 using XMLBeans:
>
> org.apache.xmlbeans.impl.values.TypeStore.find_element_user(org.apache.xmlbeans.QNameSet, int) 241 ms (0 %) 45 invocations
> org.apache.xmlbeans.impl.values.TypeStore.find_element_user(javax.xml.namespace.QName, int) 205 ms (0 %) 237 invocations
> org.apache.xmlbeans.XmlBeans.getContextTypeLoader 172 ms (0 %) 15 invocations <-- soapui is responsible for the most of this time.
> org.apache.xmlbeans.impl.values.TypeStore.find_attribute_user 32,079 µs (0 %) 1 invocation
>
Total time ≈ 446 ms
Now, lets take a look at the same but this time using JAXB.
Below are the JAXB entries that showed up as hotspot when starting the application server with the default JBoss ESB services (i.e no custom .esb archives deployed). You can find the jprofiler results http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/performance/p....
Startup of JBoss ESB on JBoss AS 4 using jaxb:
> javax.xml.bind.JAXBContext.newInstance 1,016 ms (2 %) 1 invocation
Total time = 1016 ms
We can see that using JAXB actually increases the startup time, though please note that there is only a single invocation to create a JAXBContext, whereas the calls to the XMLBeans classes are multiple and would happen for deployments as well. What I mean is that if we have more .esb archives deployed this would also effect the startup time for the XMLBeans version. It would probably do the same for the JAXB version too but it does not register as a hotspot.
Now, lets take a look a deploying a quickstart and compare the two solutions.
Again, we start with XMLBeans and the results can be found http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/performance/p... l.
Deployment of helloworld quickstart on JBoss AS 4 using XMLBeans:
> org.apache.xmlbeans.impl.values.TypeStore.find_element_user(org.apache.xmlbeans.QNameSet, int) 3,696 µs (0 %) 90 µs 41
> org.apache.xmlbeans.SchemaTypeLoader.parse 2,926 µs (0 %) 1,463 µs 2
> org.jboss.soa.esb.listeners.config.xbeanmodel101.impl.ListenerImpl.getIsGateway 707 µs (0 %) 50 µs 14
> org.apache.xmlbeans.impl.values.TypeStore.find_element_user(javax.xml.namespace.QName, int) 584 µs (0 %) 6 µs 89org.apache.xmlbeans.impl.values.TypeStore.find_attribute_user 498 µs (0 %) 3 µs 137
>
Total time = 8411 µs
Now, lets take a look at the same but this time using JAXB. The results can be found http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/performance/p... 6.html.
Deployment of helloworld quickstart on JBoss AS 4 using JAXB:
> javax.xml.bind.Unmarshaller.unmarshal 2,670 µs (0 %) 1,335 µs 2
>
Total time = 2670 µs
While using JAXB actually adds to our startup time using the default configured esb services it might not make that much difference when user created .esb archives are deployed. I've not looked into this though but might be worth investigating.
But for the deployment (after startup that is) there are some improvements to be made when using JAXB.
Any thoughts on this?
Regards,
/Daniel
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/518147#518147
14 years, 3 months
