MX and Spark Font Embedding, Fun for the whole Family!

Oh joyous Flex. Spark was a great addition to MX components. Much more flexible and extensible as well as many more skinning options. However I ran into an issue where some fonts were not liked by one side or the other. Gotta love family members that bicker...

If you see a "warning incompatible embedded font" error, a trick that I came up with was to embed the font twice. Efficient? Not entirely, but saves from having to load another font after it launches. Here is an example from the CSS that shows the embedding and setting for Spark and MX components. It works pretty well and you can specify any font you wish.

@font-face {

src: url("assets/fonts/arial.ttf");

fontFamily: ArialSpark;

fontStyle: Normal;

fontWeight: Normal;

advancedAntiAliasing: true;

embed-as-cff:true;

}

@font-face {

src: url("assets/fonts/arial.ttf");

fontFamily: Arial;

fontStyle: Normal;

fontWeight: Normal;

advancedAntiAliasing: true;

embed-as-cff:false;

}

mx|Label {

fontFamily: Arial;

}

s|Label {

fontFamily: ArialSpark;

}

Same font file just embedded two different ways for the different components. This will be great for a system wide default font for an application. It will work for multiple fonts and components as well.

Flex, BlazeDS, and an ELB walk into a bar....

Adobe Flex and BlazeDS make a great pair. Both can communicate well and all in all get along extremely well. Both can speak a variety of languages (like XML for example) and BlazeDS can even serve as a translator from Java to Flex objects. Well the fun really begins when you run BlazeDS on a clustered environment. You may ask: Whats so special about a clustered environment and BlazeDS? BlazeDS on a clustered environment works great on its own, the fun begins when you put a Load Balancer in front of it.

All Load Balancers are definitely not created equally. There are 2 that I have used myself: HAProxy (http://haproxy.1wt.eu/) and the ELB from Amazon (http://aws.amazon.com/elasticloadbalancing/). HAProxy is a great load balancer that runs on a server and it is fairly robust, easy to configure and setup, and runs on very little resources. It makes a good load balancer for multiple box environments however I have not used on clusters with more than 5 boxes so I am not sure about any more than that. The ELB from Amazon is the one currently being used and is software (assumed) based as well. It nice and has some good performance metrics, I have not worked with it directly yet but others have been using it and it seems to be good for what it does. Both Load balancers that we have been using are on a Round Robin algorithm that is on a per-call basis. All is fine normally, but we ran into a odd problem with this error:

Was expecting mx.messaging.messages.AcknowledgeMessage, but received null

Bit of a puzzling error to get thats for sure. Basically it means that on a service call (in our case we use Remote Objects with BlazeDS and call the methods on those services) the remote object did not get back anything from the server (ie the connection was closed without being given anything). Kind of like going to a hot dog stand, ordering a hot dog, paying, then getting the "We're Closed" sign slammed right in front of your face without getting the hot dog. After a long (looooonnnnnnggggg) time of digging and trying to figure this one out I stumbled upon something interesting in our log files (we set BlazeDS logging to all, not the best option but we needed to know). I noticed that around the times we hit the error that on the same box we were getting calls for multiple service methods at the same time. As it turns out, we were using an asynchronous model for calling our service methods (ie firing off multiple calls to get/perform multiple ops at the same time) and they were going to the same box. Now in a normal, single box environment this normally wouldnt be an issue. However since we are in a cluster and multiple calls should be routed to different boxes this turns out to be a big issue. 

From what I summarized, when multiple calls are performed at the same time (this from a Flex application) BlazeDS combines them into one call connection and both go to the same place. When one of the calls finishes before the other the connection closes and the other method is left with nothing returned. The solution to this was to track down the areas we were making async calls and change them over to a sync model to make sure that each call happened independently from the others. The solution worked and we have not run into the problem since. Now, this message can show for other reasons so this is only one of the possibly dozens of reasons out there. If you are using BlazeDS in a clustered environment with a Load balancer set to Round Robin you should try this out first. 

Did you run into another issue that produced this error as well? Post about it to help others out that may have the same issue.

Log Off

- David

Time to Blog

First blog I've had in a while.

I created this blog to talk about Adobe Flex and Air things that I have run into over time that has either intrigued me greatly or irked me to no end. It will be a place to share ideas that I have had about Flex components and also provide a place for others to contribute. I am always looking forward to help from others, this is just another avenue to get that going :).

Time to start flexin...

Log Off