Hi Seth, This is awesome information. I didn't know player batch them up and send in one post. I learned something today. I digged through Blaze source code and found out that "BatchProcessFilter" is responsible for processing those messages . I am wondering is there any way, I can write our own batch process filter and plug that in instead of default one. What I am thinking is to process those messages in parallel on server then response to the client in one response. Basically, it would cut down the time server has to wait to finish processing all those messages sequentially.
Any thoughts or insight info would be appreciated. Thanks, Jay --- In flexcoders@yahoogroups.com, "Seth Hodgson" <[EMAIL PROTECTED]> wrote: > > There is a single thread that advances through SWF frames and runs your > ActionScript code and event handlers, but network calls are performed by > separate background threads concurrently. > > In order to have calls processed concurrently on the server, they need > to arrive as separate requests. In the case of AMF, if you make a series > of calls quickly chances are good/excellent that the Player will batch > them up and send them to the server in the body of a single HTTP POST. > When this happens, the server must unpack them and process them serially > and then pack the results for all these calls back up in the body of a > single HTTP response. Because we're dealing with a single request and > response, there's no way to send back results for individual calls > separately. When these results get back to the browser and are passed > back into the Player, they are dispatched to your ActionScript handling > code as asynchronous events. There's not a good way to force calls to be > sent as separate requests, and even if you could, browsers impose limits > on the number of concurrent connections they'll open to a server, so > this really isn't the right way to solve your scenario. Also, in the > case of RTMP all traffic between the client and server happens over a > single connection and is ordered serially. > > > > If you want to process calls/messages/data asynchronously on the server > the proper way, it requires a bit of work on your part to accomplish at > this point. Rather than running your current logic in your RemoteObject > directly when it is invoked, you need to break that out into a Runnable > class, and when you're invoked, create an instance of this class that > packages up the incoming args and info about the client making the call > and then submit that for asynchronous execution to a > java.util.concurrent.Executor that you'd need to set up during server > startup. Your remoting method could return a job id or just void once it > has queued an instance of your Runnable with the Executor. On the client > when you get a ResultEvent for your call you don't get the actual result > - you just know that your invocation was successfully queued for > asynchronous execution on the server. So the second half of the equation > is how to get the result or fault generated when the Executor runs your > Runnable back to the client. You need to take advantage of messaging in > BlazeDS or LCDS to achieve this. In your client app, create a Consumer > and subscribe to a destination you define that you can publish > results/faults as AsyncMessages back to target clients from your > Runnable. Your Consumer should subscribe to a subtopic that applies only > to it, or use a selector expression. When your Runnable runs and > generates the result or fault to return, you'd can create an > AsyncMessage containing the result of fault info and publish it to this > destination, using either a subtopic header, or some other message > header that will be evaluated against the Consumer's selector expression > such that the message is routed to the proper Consumer. That lets you > return async results or faults to clients in a truly asynchronous > manner. > > > > This is actually something I'd like to see us bake into the product > directly. Would one of you on the thread log an enhancement request here > and the rest of you vote for it: https://bugs.adobe.com/blazeds/ > > No promises because resourcing is always a juggle but lots of people ask > for this, I'd like to see it happen, and your votes matter J > > > > Seth > > > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of MyoT > Sent: Thursday, May 22, 2008 10:49 AM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Re: Async Concurrent Requests with AMF for BlazeDS > or LCDS > > > > If Flex (Flash) uses async request, does Single Threaded matter? > > I tried to have more than one channel, it doesn't help either. > > - Jay > > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> > , "twcrone70" <twcrone70@> wrote: > > > > Your server code might be able to run things concurrently but unless I > > misread something, Flash is currently single threaded I believe. So > > actually sending the requests at the 'same time' is difficult if even > > possible. > > > > - Todd > > > > --- In flexcoders@yahoogroups.com > <mailto:flexcoders%40yahoogroups.com> , "MyoT" <bighead007us@> wrote: > > > > > > Hi There, > > > > > > I am wondering is there any way, you can make concurrent requests to > > one destination via > > > RemoteObject over AMF. > > > > > > Basically, I want to issue multiple request of getItem operations to > > one destination. Currently, > > > my command is making multiple async requests but RemoteObject > > doesn't seem to be calling > > > server concurrently. Server got those request in sequential. > > > > > > Any help or pointer would help. > > > > > > Thanks in advance, > > > Jay > > > > > >
