BlazeDS & Flex & LiveCycle DS & Tutorials 23 May 2008 05:41 am

BlazeDS Message Channels

BlazeDS Message Service is a simple publisher-subscriber model. The service configuration could be boiled down to two parts: channels and destinations. In networking terms, destination is the message hub and channel is the transport protocol.

BlazeDS Message Service

BlazeDS does not support RTMP and the default channel type is client-polling. This has created a lot of confusion over whether BlazeDS support real-time messaging. The short answer is “yes, it does”. In fact, BlazeDS has a full spectrum of channel types ranging from simple polling, to near-real-time polling, to real-time streaming. This article will explore the different channels types in BlazeDS. It should also be applicable to LiveCycle DS.

Simple Polling vs. Long Polling

Polling is the fool-proof messaging protocol that’s guaranteed to work in most scenarios, but it’s also the slowest and least efficient. The default messaging protocol in BlazeDS uses the simple polling technique. As demonstrated in this diagram, the client pings the server on a regular interval. An empty acknowledgment is returned if there’re no messages for the client,

message polling

To achieve near-real-time messaging, there’s a option called “long polling”. Instead of acknowledging right away, the server could hold the polling request until there’s a message for the client. This ensure the messages are delivered to the client as soon as they become available,

BlazeDS Long-Polling

To add a long polling channel to BlazeDS, open WEB-INF/flex/services-config.xml. Under the channels node, add the channel definition as follows,
[code lang="xml"]

true -1

100 50

[/code]

  • wait-interval-millis dictates how long the server should wait before returning a polling request. The default is 0. By setting it to -1, we are telling it to wait indefinitely until a message is to be routed to the client.
  • polling-interval-millis is the time interval between polling requests. Since we no longer need to pace the requests, we could safely set the interval to 0.
  • max-waiting-poll-requests caps the number of long polling clients. Since the server is not ackowleging right away during long polling, each client hogs one server thread. Once the cap is reached, any new clients fall back to simple polling clients.

The caveat for using long-polling is the thread limitation in most application servers. At this moment, BlazeDS could not support more than a few hundred long-polling clients on most application servers. However, this problem could be resolved once servers like Tomcat start to support asynchronos, non-blocking connection threads.

Polling vs. Streaming

BlazeDS supports real-time message streaming over AMF and HTTP. Unlike long polling, which closes and reopens the connection upon receiving a message, streaming keep the connection open at all times.

BlazeDS message streaming

To add a streaming channel to BlazeDS, open WEB-INF/flex/services-config.xml. Under the channels node, add the channel definition as follows,
[code lang="xml"]

0
10
5000

[/code]

  • max-streaming-clients controls the number of concurrent streaming connections on the server. Streaming suffers from the same thread blocking issue as long polling. A cap must be set so the server is not hang by idle threads.
  • idle-time-minutes boots off long idling clients to free up threads. This could help alleviate the threading issue and help prevent misuse.

Which Channel to Use?

With the slew of channel types available, which one should you choose? Fortunately, you could leave that decision to the run-time environment. The Flex client could be configured with a set of channels types. It will go through the list one at a time until a successful connection could be made. The following code example creates a channel set for the consumer object,
[code lang="actionscript"]
var channSet:ChannelSet = new ChannelSet();

var streamChann:AMFChannel = new AMFChannel("myStreamChann", "http://localhost:9090/blazeds/messagebroker/amfstreaming");
var longpollChann:AMFChannel = new AMFChannel("myLongPoll", "http://localhost:8080/blazeds/messagebroker/amflongpolling");

channSet.addChannel(streamChann);
channSet.addChannel(longpollChann);

producer.channelSet = channSet;
consumer.channelSet = channSet;



[/code]

  • In the code above, the client tries the streaming AMF connection first
  • If the streaming AMF fails, it falls back to long polling
  • If long-polling fails, it falls back to simple polling

One last thing I need to clear up is the terminology confusion over the AMF channels and HTTP channels. In the context of BlazeDS channels, AMF refers to binary RPC protocol. HTTP refers to XML RPC protocol. They BOTH run on top of HTTP.

Want to make a cool Obama poster with your own photo? Check out the Citrify Photo Editor.

16 Responses to “BlazeDS Message Channels”

  1. on 23 May 2008 at 7:33 am 1.FlexLive.net » LiveCycle DS / BlazeDS Message Service said …

    [...] on the server. Channel is the communication protocol between server and client. There are a variety of protocols you could use based on your infrastructure and project [...]

  2. on 27 May 2008 at 12:50 am 2.Satish said …

    >this problem could be resolved once servers like Tomcat start to support asynchronos, non-blocking connection threads.

    Does that mean this problem will be resolved If you use Tomcat 6 or Jetty 6 with BlazeDS, because Tomcat 6 and Jetty 6 supports non-blocking IO connectors.

    Have a look at following URL
    http://docs.codehaus.org/display/JETTY/Introduction+to+Jetty6
    http://people.apache.org/~fhanik/http.html

    Thanks.

  3. on 30 Jun 2008 at 9:20 am 3.Matthieu said …

    Hi

    I came accross your great postings.

    I have a flex app using BalzeDS Remoting running on Amazon EC2

    I have the following issue:

    When running locally on jboss and accessed through http://localhost:8080/alpha, the application loads and i can do server requests (login/create account) with Safari firefox and IE7.

    When running on EC2 at http://www.mydomain.com/mycontextroot/,

    When accessing via Safari: it loads but will display the following error message when making server call (create Account/login)
    FAULT: faultCode:Client.Error.MessageSend faultString:’Send failed’ faultDetail:’Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed: url: ‘http://www.mydomainname.com/mycontextroot/messagebroker/amf”

    When accessing via IE7 it works (loads and i can do server calls)
    when accesssing via firefox, Flex loads but it hangs when making server calls (create account/ login)

    Would you know what’s going on?
    I don’t have a proxy-config.xml and crossdomain.xml
    Not sure i need them since i use BlazeDs-Remoting

    Thank you

  4. on 10 Jul 2008 at 4:38 pm 4.Etienne said …

    Does anybody have an idea when Blaze will be using NIO? Tomcat6 and Jetty supports NIO since a while now.

  5. on 20 Jul 2008 at 8:46 am 5.Steven Lin said …

    Maybe BlazeDS won’t use NIO Endpoint.
    because NIO channels has included in LCDS 2.6.

  6. on 05 Aug 2008 at 10:58 pm 6.Marty said …

    Yep, I’m having the same issue that Matthieu is having – works great locally, but throws a “not found” error for remote location “samples/messagebroker/amf”. However, I cannot get it to work on Internet Explorer 7 either, unlike Matthieu has been able to do. Bottom line: works locally, doesn’t work remotely. Anyone running BlazeDS applications remotely with success? Thanks to a great community!

  7. on 13 Oct 2008 at 10:28 pm 7.Blazeds « It’s all about RIA said …

    [...] Zee Yang :: BlazeDS Message Channels [...]

  8. on 14 Oct 2008 at 1:21 am 8.BlazeDS « Flex Generation Weblog said …

    [...] Zee Yang :: BlazeDS Message Channels [...]

  9. on 22 Jan 2009 at 6:31 pm 9.Solution Hacker - Streaming data to your grid said …

    [...] have learnt from this article that you can create a channel set in client side. So Flex can fail-over to other channels until it [...]

  10. on 18 Feb 2009 at 12:20 am 10.현의 관심 이거저거 said …

    BlazeDS, Polling , Streaming …….

    BlazeDS에서는 RMTP프로토콜이 지원이 안됩니다. 대신 Polling과 Pushing 을 위해서 PollingAMF 와 StreamingAMF가 존재 합니다. 이에 대한 차이점에 대한 글 포스트입니다. 자세한건 -> 여기 …

  11. on 22 Apr 2009 at 8:28 am 11.lrc said …

    what is the max client can be supported by blazeds streaming? thx

  12. on 15 May 2009 at 8:00 am 12.Ankur said …

    Do you know whether long polling could be implemented in a flex-ruby environment?

  13. on 12 Jun 2009 at 3:11 am 13.Dan said …

    Hi, you can also configure failover in services-config.xml by putting more than one channel definition into your default channels element, or you can do this for a specific remote object.

    For those who are having problems connecting to remote BlazeDS, have you tried just putting the URL in your browser address bar, or telnet to the url 8080 (or whatever port you are using) ?

  14. on 30 Nov 2009 at 7:30 am 14.Esref Atak said …

    Hi.

    Is it possible to programatically adding Destination and Channel? In our case, all of system is database driven, so, we must create all destination and channels on OS startup.

    Is it possible and is there any example to show me how do I.

    Thanks.

  15. on 12 Jan 2010 at 4:25 am 15.John said …

    Hello,

    I just want to know the eventual problems of “send failed” error message provoqued by the producer when sending a message(AsyncMessage) to the server.

    Regards

  16. on 26 Jan 2010 at 10:46 pm 16.jolly said …

    Hi 2 all….

    I want to ask that can i use my asp.net web services for this particular architecture…

    reply asap..

    Thanks & Regards

    Jolly

Trackback This Post | Subscribe to the comments through RSS Feed

Leave a Reply