Measuring message processing performance

November 25, 2008

Firstly, LiveCycle Data Services 2.6 Developer Guide is amazing. Everything is explained clearly. LCDS team rocks πŸ™‚

LiveCycle Data Services developer guide:

I was going through the document and found a topic which explains how adding a few tags in the services-config.xml file will get lots and lots of metrics regarding processing time of a message. Information regarding message size, server processing time, and network travel time is available to the clients. You can also get information on the server logs. This works for all types of channels. That means you can also measure performance for a Remoting call also. This is available in both BlazeDS and LCDS πŸ™‚

You can find detailed explanation on this mechanism at this URL:

Few metrics I liked the most are message size, server adapter time, server processing time, server send time and total time. There are lot more, you can find a table explaining the metrics in the URL included above.

We will have a look at main steps required to enable gathering metrics with a Remoting sample.

On the server

First you need to tell your channel to send the metrics to the clients. For this you need to add 2 tags in services-config.xml under the channel tag as shown below. Here I am adding it for an AMF channel. I am using this channel for my Remoting Service destinations. In the code snippet below tags in bold are the ones to be added. You have to add the tags for the channel you want the metrics for.


<channel-definition id=”my-amf” class=”mx.messaging.channels.AMFChannel”>

<endpoint url=”http://{}:{server.port}/{context.root}/messagebroker/amf” class=”flex.messaging.endpoints.AMFEndpoint”/>









On the client

MessagePerformanceUtils class will help you to parse the metrics from the message returned from the server. All you need to do is to pass the message to the MessagePerformanceUtils class constructor in the result handler. Once this is done, you will use MessagePerformanceUtils instance to retrieve the metrics.

Please download sample from this URL:

In the function below which is the result handler in the sample code attached, you can see we are passing the message object returned by the server to the MessagePerformanceUtils class. prettyPrint() method of this class returns a formatted string of metrics. You can find more details on MessagePerformanceUtils class at this URL

private function handleServerResponse(event:ResultEvent):void{

remoteObject.removeEventListener(ResultEvent.RESULT, handleServerResponse);

remoteObject.removeEventListener(FaultEvent.FAULT, Β Β Β Β Β Β Β Β Β Β Β Β Β  handleServerFault);

//processing the result

var performanceDetails:MessagePerformanceUtils =

new MessagePerformanceUtils(event.message);

txtOutput.text = performanceDetails.prettyPrint();


Creating Remoting destination and Java class

Please find details on how to invoke Java methods from Flex using Remoting at this URL

All you need to do is to create a Remoting destination with TestingOnly as id and set the source to a Java class with method below.

public String echo(String echoString){return echoString;}

That’s all you need to do πŸ™‚ now you have all metrics required to measure message processing performance.


Adobe Flash Platform it is

November 18, 2008

Adobe Flash Platform

Innovation that stands out, technology that fits in

Excellent branding … Great going Adobe !

Securing BlazeDS destinations using custom Tomcat REALM authentication

September 4, 2008

I was planning to write a post on how to secure BlazeDS/LCDS destination using custom REALM authentication in Tomcat. Before wrting, I searched for articles on this topic and found good articles on how to do the same. I thought of including the URLs to those articles instead of writing a new article.

You can find details on how to create a custom authentication class for Tomcat at this URL

BlazeDS developer guide has a awesome article with sample on how to secure your destinations based on Tomcat Realm authentication. Please find article at this URL


Basic authentication:

Custom authentication:

Secure your destinations πŸ™‚

Sending messages from Java to BlazeDS destinations using MessageBroker

August 14, 2008

We discussed BlazeDS/LCDS messaging samples in which we produce messages from a Flex application and consume that message from another or same Flex application. BlazeDS/LCDS also allows us to publish messages to messaging destinations from a Java class on the server.

As BlazeDS/LCDS allows us to publish messages from a Java class on server, we can build a JSP/Servlet which will invoke this Java class and publish messages to BlazeDS/LCDS messaging destination. We can establish messaging between and Flex and Non-Flex client.

I created a simple sample in which I am sending messages from a JSP page to a Flex client. This is so simple. All you need to do is to create a Java class with one method in it and a JSP which will invoke this Java class. You will also create Flex application which will subscribe to the destination to which we will publish messages from our Java class.

Let’s start coding:)

First we will create the Java class which will publish the message.

We have only one method in this class called sendMessageToClients. In this method we will create a message of the type AsyncMessage and publish that message using MessageBroker. AsyncMessage and MessageBroker class are available with BlazeDS in the flex-messaging-core.jar. You should be adding this jar to your project libraries to compile this class. Download the Java file compile it and deploy it in WEB-INF/classes folder of your web application.

Download this Java file from this URL:

public void sendMessageToClients(String messageBody)


AsyncMessage msg = new AsyncMessage();


msg.setTimestamp(new Date().getTime());

//you can create a unique id


//destination to which the message is to be sent


//set message body

msg.setBody(messageBody != null?messageBody:””);

//set message header

msg.setHeader(“sender”, “From the server”);

//send message to destination

MessageBroker.getMessageBroker(null).routeMessageToService(msg, null);



Download the JSP from this URL:

In this JSP file we will just invoke the Java class created above.


In this MXML file we will be subscribing to the destination and also act as a producer for the same destination. You can find more details on messaging in Flex at this URL

Download this MXML file from this URL:


This is file in which we will configure our destination to which we are publishing messages and subscribing to get messages. Β Just add the XML tag below as a child to <service> tag in messaging-config.xml file in your BlazeDS configured web application under Web-INF/flex folder. Please make sure you have default channel set in the messaging-config.xml.

<destination id=”TestingDestination”>


That is all you need to do. Run the Flex application and then try some text and see if you are receiving the messages as the Flex application is acting as both producer and consumer for the same destination. If you are receiving the messages send by you, which means the messaging destination is configured properly. Now just launch the sendmessage.jsp page from the browser, you should be able to see the message sent from the Java class in the Flex client.

That’s it:) Adobe Rocks πŸ™‚

Session data management in Flex Remoting

May 16, 2008

If you are using Flex Remoting to communicate with Java classes on the server, you might want to maintain instance of an object across a user session. For example you might want to store the User object after successful authentication of a user. BlazeDS provides class named FlexContext.

Please visit the BlazeDS Developer guide at this URL for more details on FlexContext class and session data management. BlazeDS Developer Guide

Updated: Free AIR based Tool to generate Flex code for consuming/exposing Java classes as BlazeDS Remoting services. Visit this URL for more details

I created a simple Java class which will add objects to session. It will also retrieve objects from session and modify them. I access this Java class from a Flex application to get the data which is stored in user session. In this sample we will be creating one Java class and one .mxml file.

Pre-requisite: Knowledge on how to invoke Java methods from Flex applications and also have BlazeDS set up on your server. If you have not done this, please visit this URL for details on how to access Java methods from Flex applications. Invoking Java methods from Flex applications

Let’s move into details. First create a Java class as shown below.

Download this file from this URL:

In the constructor I am checking if object already exists in the session and add objects if necessary. We have two objects in the session. One is userName which is object of type java.lang.String and myCounter which is object of type java.lang.Integer and is used to store a counter. We will provide method to increment this counter.

public MySessionHandler()


mySession= FlexContext.getFlexSession();

if(mySession.getAttribute(“myCounter”) == null)


mySession.setAttribute(“myCounter”, new Integer(1));


if(mySession.getAttribute(“userName”) == null)


mySession.setAttribute(“userName”, “Sujit Reddy G”);



In this method we are incrementing the value of the object stored in the session.

public void increaseCounter()


Integer i = (Integer) mySession.getAttribute(“myCounter”);

i = i + 1;

mySession.setAttribute(“myCounter”, i);


You can find more methods in Java file attached. Download the file and place the compiled file into WEB-INF/classes folder of the web application where your BlazeDS is present. You should add flex-messaging-core.jar to your project build path in Eclipse to compile this class.

You should add a destination to your remoting-config.xml. I have added the following under the service tag in my remoting-config.xml.

<destination id=”MySessionHandler” channels=”my-amf”>




<adapter ref=”java-object”/>



Download this file from this URL: SessionSample.mxml

In this Flex application we have three buttons which will invoke methods on the Java class created above to get the results. There are three methods which we will invoke.

getUserName() – this will return the user name stored in the session

getCounter() – this will return the value of the counter

increaseCounter() – this will increment the counter value

You have to map your Flex application to the web application with BlazeDS as described in the pre-requisite for this blog.

That is all you need to do. It’s that easy to manage session data while using Flex Remoting. πŸ™‚

Creating custom messaging adapters

March 10, 2008

You create custom messaging service adapters when you want a functionality which the default adapter is not providing. Default messaging adapter (Action script adapter) shipped with BlazeDS will just broadcast the message, which the producer sends. What if you want change this functionality? You just have to create your own service adapters.

You can create custom service adapter class by extending the class. Other classes which we will use are:

  • flex.messaging.messages.AsyncMessage
  • flex.messaging.messages.Message

MessageService class is used for sending message to all the clients subscribed to the destination. This class provides methods like pushMessageToClients(), using which we can send messages to all the subscribed clients.

AsyncMessage class is used for creating message to send to the users.

The ServiceAdapter class and other classes required are in the flex-messaging-common.jar and flex-messaging-core.jar files. These jar files are bundled with BlazeDS.

Sample application

I have created a simple application in which I am creating a message and sending it to all the clients subscribed to a destination. When the user clicks on a button reading “Ready to bid”, the application will send message to all the subscribed clients. I used custom adapter to modify the message and send it to all the clients.

Note: you can achieve this sample application without using custom adapter also πŸ™‚

Creating sample application


1. Create a custom messaging adapter class

2. Add the adapter to the services-config.xml

3. Create a destination

4. Create Flex application to produce/consume the message

Create custom messaging adapter

In this class, I just modified the message body and sent it to all the clients. You have to override the invoke() method of the ServiceAdapter class. Invoke() method will be called when any client sends a message to the destination. By overriding the invoke() method you get access to the message object, which the client sent.

Download the custom messaging adapter’s Java file

Configure the services-config.xml and creating destination

You have to add your destination and adapter definitions to either services-config.xml or the messaging-config.xml file. Add the destination and the adapter as shown in the code snippet below. I have added the custom adapter, created above to the configuration file using the adapter element. I have also added the destination and mapped it to the adapter.

<service id=”message-service” class=””>


<adapter-definition id=”SujitAdapter” class=”com.adobe.adapter.CustomMessagingAdapter”/>


<destination id=”CustomMessagingAdapter”>

<adapter ref=”SujitAdapter”/>



Create Flex application

We have completed the configuration and the development on the server. We will create a flex application which subscribe to the destination and receive messages from other users. Users can also send messages to other clients on click of a button.

Download the mxml file

That’s it. We have created a custom messaging adapter for BlazeDS. You can create your own messaging adapters and map your destinations to the adapters. There is lots more than just creating custom messaging adapters. You can even manage the list of clients subscribed to a destination yourself, instead of leaving it to BlazeDS πŸ™‚

Adobe Rocks πŸ™‚

BlazeDS and LCDS Performace difference

February 4, 2008

Is there a difference in performance between BlazeDS or LCDS? The answer for this is – Depends on what features you are using. πŸ™‚

PS: Thanks to Seth Hodgson from Adobe for posting these details in the pre-release forums πŸ™‚

Scenarios in which BlazeDS and LCDS provide same performance

If you’re just using RPC services (RemoteObject, HTTPService, WebService) over an AMFChannel from the client to the server, there’s no difference in performance between BlazeDS and LCDS. That’s just traditional HTTP requests/responses between the clients and servers. So you’re limited by OS/hardware specs to some max request per second processing capacity for your box (this limit would also depend on what your RemoteObjects are doing, etc.)

If you application is using messaging (or auto-sync data management), that requires a channel that can get messages from the server down to the client. There’s simple polling, and that behaves the same in BlazeDS and LCDS.

Scenarios in which LCDS performance is better than BlazeDS performance

If your application is using data push, this is where the performance differs. BlazeDS supports long-polling and streaming over HTTP to push data to the client but it manages this through the Servlet API, which has the restriction right now of mandating blocking IO.

Why LCDS performs better

LCDS provides support for the RTMPChannel (direct duplex socket connection between the client and server) as well as non-blocking long-polling and streaming support over HTTP that bypasses the Servlet API and its blocking IO limitation. All of these options in LCDS are built on top of the Java NIO APIs.

Non-blocking IO doesn’t require a thread per connection sitting blocked in a read() call on the underlying socket. So you can have many connections without the expense of a having a thread per connection.

In terms of the total number of connections a BlazeDS or LCDS server will support, back of the envelope estimates are in the hundreds for BlazeDS (because of Servlet blocking IO and the fact that Servlet containers generally don’t have more than hundreds of threads in their request handler thread pool) and in the thousands for LCDS thanks to Java NIO. Whether you’re talking about 5K or 10K depends on your OS, hardware and application. At some point, depending on the number of messages you’re sending and the amount of processing and IO you’re doing you’ll saturate your box.


For traditional request/response style interaction between the client and server, blocking IO is reasonable, but for server data push and messaging, it’s not so good. That is BlazeDS and LCDS performance differs when it comes to server data push and messaging, where you are using Blocking IO, LCDS performs better in these scenarios, because of Java NIO. πŸ™‚