Sunday, May 10, 2009

AppEngine & BlazeDS (Messaging)

Hello!
I added a simple messaging test drive to existing flex PoC app, this time I updated Spring version from 2.5.5 to 3.0.0M2 and from flexM1 to flex-1.0.0.RC1 with my already existing 'slight-hacked' core.jar from my previous blog , it went pretty well and here are the results:
Note that Spring changed @ web-application-config.xml to new 'remoting-destination' ->
   
   
      
       
   
   
Here's a snippet flex client set up ->

 



And finally this is my new list of libraries/dependencies deployed to the cloud for your reference->
martin@martin-ubuntu9 ~/projs/blazeappengine/war/WEB-INF/lib
$ ls -1
antlr-3.0.1.jar
aopalliance.jar
appengine-api-1.0-sdk-1.2.0.jar
asm-3.1.jar
aspectjrt.jar
backport-util-concurrent.jar
cfgatewayadapter.jar
cglib-2.2.jar
commons-beanutils.jar
commons-collections-3.1.jar
commons-fileupload-1.2.1.jar
commons-lang.jar
commons-logging-1.1.jar
concurrent.jar
datanucleus-appengine-1.0.0.final.jar
datanucleus-core-1.1.0.jar
datanucleus-jpa-1.1.0.jar
flex-messaging-common.jar
flex-messaging-core.jar
flex-messaging-opt.jar
flex-messaging-proxy.jar
flex-messaging-remoting.jar
geronimo-jpa_3.0_spec-1.1.1.jar
geronimo-jta_1.1_spec-1.1.1.jar
jackson-core-asl-0.9.9-6.jar
jdo2-api-2.3-SNAPSHOT.jar
org.springframework.aop-3.0.0.M2.jar
org.springframework.aspects-3.0.0.M2.jar
org.springframework.beans-3.0.0.M2.jar
org.springframework.context-3.0.0.M2.jar
org.springframework.context.support-3.0.0.M2.jar
org.springframework.core-3.0.0.M2.jar
org.springframework.expression-3.0.0.M2.jar
org.springframework.flex-1.0.0.RC1.jar
org.springframework.transaction-3.0.0.M2.jar
org.springframework.web-3.0.0.M2.jar
org.springframework.web.servlet-3.0.0.M2.jar
xalan.jar
Give it a try, subscribe to pre-determined dest+topic and emulate a msg push from server, you'll see there an asynch msg received by the client consumer, better yet launch 2 or 3 browsers, subscribe from all and send msgs from only one browser isntance, you'll see all consumers being published since they all subscribe to same predetermined topic.... ;-)
Cheers.

13 comments:

Alex said...

Did you tried with other channel support ? Sounds like you'll quickly waste/exceed GAE quota with a polling channel.
Long polling could be better (using the 30s servlet response time limit of GAE) or what do you think?

Martin Zoldano said...

Hello Alex, thanks for reminding me of that detail, I was actually concentrating on getting it to work on a restricted runtime, I guess I left it at few secs polling interval so a user gets almost instant gratification from receiving an async msg pushed from svr, I just checked the free quotas once again:
request duration - 30 seconds
simultaneous dynamic requests - 30
and I checked the logs and a user average shows up every couple hrs or so, but yes if on peek time I have more than 30 usrs polling will be an issue, I'll probably extend the polling to more time or set up the long polling channel if it's necessary.
Again this is a small PoC.....but thanks for the heads-up!

Martin Zoldano said...

Good to see more apps being born on GAE/J such as this one

http://groups.google.com/group/google-appengine-java/browse_thread/thread/84fbdde59d9aa008/c35afc1ed3e97d28?lnk=gst&q=blazeds#c35afc1ed3e97d28

Ron said...

Hi Martin,

Motivated by your comments I also tried messaging with polling. It works great with normal polling! I then tried long polling, but unfortunately that does not work - nor does it even revert to normal polling. Have you had any luck with long polling?

Thanks,
Ron

Martin Zoldano said...

Hello Ron,
No I only used the regular polling so far for that small test drive, I'll take a look when I get a chance and let you know, cheers.

Alex said...

Ron, I haven't tried long polling but came to believe it will not work. You can read in GAE doc that the response content will get buffered - so long polling that relies on sending back content chunck as it comes will not work properly.
Note that due to the 30 simultaneous request quota you'd be also limited to 30 users with long polling.
I expect something better by end of year given JEE 6 Servlet 3 and Jetty 7 support of this - although HTML 5 webSocket will also become a requirement for GAE to support in some form pretty soon as well... so far I am prototyping with a 5 sec polling and we'll see how it goes.

Martin Zoldano said...

Thanks Alex and Ron for saving me time, I guess for now we can then prototype extending accordingly [polling-interval-seconds] on regular polling amf channel....at least that much is functional, things will mature with time....
thx

Dishman said...

Hey Martin,

When i used the producer class on my client side to send a message. I experienced problems. What happened was though i used producer.send(msg) once, there were two consecutive messages sent at a gap of one second. i used the network monitor of flash builder to find out what the problem is and this is what the raw view of the REQUEST portion of the msgs showed.
1st msg
ServiceRequest: subscribe; MessageService; subscribe
(mx.messaging.messages::CommandMessage)
body=(Object)#0
clientId=(null)
correlationId=""
destination="pollmess"
headers=(Object)#0
DSSelector = "AssigneeID = 'man'"
messageId="C6410BCD-A188-E5CC-ECD9-9D46F73CE22E"
operation="subscribe"
timeToLive=0
timestamp=0

2nd msg
ServiceRequest: ; MessageService;
(mx.messaging.messages::AsyncMessage)#0
body = (Employee)#1
groupid = 1001
name = "Anirudh"
clientId = (null)
correlationId = ""
destination = ""
headers = (Array)#2
[AssigneeID] "man"
messageId = "1BCB61B4-7B8E-CCB4-8884-9D46FA582A15"
timestamp = 0
timeToLive = 0


The value of the destination,along with a lot of other details which were there in the first msg seem to be missing in the second one. It goes to the fault handler of the producer and fault detail string is as shown
Channel.Connect.Failed error NetConnection.Call.Failed: HTTP: Failed: url: 'http:/{appname}.appspot.com/messagebroker/amfpolling'

But when i try the url on the browser, there doesn seem to be anything amiss. Please offer ur insights.

Martin Zoldano said...

Dishman, thx for sharing, it's been a while but I remember that it was a bit tricky to get it to work, from my test drive you can open a black and green pop-up which dumps raw msg contents, that'll help you see what's going on thru the wire, based on your issue, the only thing that surfaces to the top of my head is that when client subscribes:
private function subscribe():void {
if (!consumer.subscribed ) {

emulateDummyReqMsg();
consumer.subscribe();

}
}
the only way I got it to work was with emulating a dummy push msg from server prior to client invoking subscribe(),
did not spend too much time figuring out why (my hunch is perhaps it needs to bootstrap server side messaging), try that just to see what happens, and then investigate further, hope that helps!, cheers

Luke said...

Hello, Martin!

I'd love to get ahold of the fixed flex-messaging-core.jar file. I suspect the alternative will involve half a day of banging my head against a wall and I'm far happier on the path of least resistance!

Elfwine said...

Hello. I was following your work and I'm kinda lost with the implementation of messaging in GAE.
I will appreciate so much if I can get a copy of your source code. You can send it on my mail, alvin.carrasca at gmail.com.

Thanks a lot. Your articles helps people like me.
More power,
Alvin

Martin Zoldano said...

Server side msg sample:
MessageBroker msgBroker = MessageBroker.getMessageBroker("_messageBroker");
AsyncMessage msg = new AsyncMessage();
msg.setDestination( dest );
msg.setHeader("DSSubtopic", topic );
msg.setClientId( cid );
msg.setMessageId( id );
msg.setTimestamp( System.currentTimeMillis() );
msg.setBody( body );
msgBroker.routeMessageToService(msg,null);

Manu Dhanda said...

Great job Martin. Any possibility to publish the source code for this app? OR in case if you can share it on my mail manuraj.dhanda@gmail.com
Thanks.