Concurrency

[kramer]

Hoping I could get a little advice/info on this conundrum that I am having...

I have a singleton bean defined with two methods, run() which does some work and takes anywhere up to 30 seconds to run, and progress() which reads an int (value 0-100) on the same object as a value to use in a Flex ProgressBar. My remote object is defined like this:

	<mx:RemoteObject id="ro" destination="testService" concurrency="multiple">
		<mx:method name="run" fault="Alert.show(event.fault.message)"/>
		<mx:method name="progress" result="resultHandler(event)" fault="Alert.show(event.fault.message)"/>
	</mx:RemoteObject>

A timer is started when a button is clicked and calls progress() twice every second. Immediately after that, run() is called:

            timer.start();
			ro.run(startDate.selectedDate, endDate.selectedDate, c, startingEquity.text);

What is happening is that the progress calls are being queued up until after the run() call returns. It's like the RemoteObject is 'synchronized'.

Anyone know why I'm getting this behaviour?

Many thanks in advance.

[imilina]

Try not to call run() and progress() functions on your remote object at roughly the same time. If you, for example, call

ro.run();

and imeediately after that call

ro.progress();

flex will send only one request (not two, as you would expect) to the server. This request will contain both function calls, but since they're in the same request, BlazeDS will return only one response, containing both function return values. The generation of this response on the server will take whatever time it takes to complete all function calls that were in the request.

So, if you want to call your progress() function twice per second, do so, but start the timer with, for example, 500ms delay after you call your run() function.

Hope this helps,
Igor.

[kramer]

Thanks very much for that information. That explains what's happening very well. In the end, what I did was make 2 separate remote objects pointing to the same server side object, it does the job... but I will probably switch to your suggestion.

I am using AMF for communication (copied and pasted from the blazeds test drive example)... if I used one of the other protocols, would this 'batching' still happen?