Develop Reference

Adobe Flex Mobile Background Process

What is the best solution for multi threading in flex, I notice if I play a mp3 in flex and do something else at the same time something ends up giving out, either the song stops playing or the UI hangs for about a split second. It doesn't have that fluid response that I am looking to achieve. If possible I would like to call a multi threaded java class to do some of the client-side end back end processing. I just don't know if that is possible. Any insight would be greatly appreciated I am stuck on this one.
-Phil

Flex/Flash alone don't support multithreading - Adobe keeps argumenting that multithreading is not necessary for most of potential flex applications and would just increase complexity for the average flex developer too much.
Looking for solutions myself I have only found snippets where the task to be done simultanously gets logically cut into smaller pieces, then you run them piece by piece, letting UI get time slices in between. It might work for some but is no solution to your problem.
Now to Java - using the native process api could make it work. Java process would take over some part of the processing and you would control its working writing to and reading from input/output streams which gets connected between java process and flex app. Another possibility could be inter-process socket communication (did it myself before native process api was there - works!)

If the UI is hanging you have another issue. It seems to me like you are looping through some sort of data to make this "lag". What you can do is format the data better so you don't run into this. Or look into your process that you run when the hanging happens and optimize it better.

Flex/Flash has no blocking methods and so doesn't need threading, just call a function on a timer or enterframe, and make sure it yields in under 25ms or so. As for speed, Java (running in Android's 'Dalvik' VM ) is not a lot better... C is the only option for ultimate speed.

Here is a rather complete 'Greean Thread' lib - http://blog.generalrelativity.org/actionscript-30/green-threads/
I have found it useful, as irrespective of Tom's views Threading is most definitely often a needed things that is not supported properly (yet??)

Also bear in my mind that the debug player behaves very differently from the standard player, and (a separate issue) that during a debug session, significant slowdowns can be apparent with performance critical code... Only believe the browser plugin, non-debug version, running in a browser, not debugging. That is the only reliable test. I have seen speed up of 25-30x just by changing to the release player (extreme case). Thought I had a major performance problem, but actually didn't :)

How to test your website against multiple users(extended)

There is similar question on this topic I participated in it, but it doesn't really answer what I need at this moment.
How to rigorously test a site?
I noticed java.util.ConcurrentModificationException in my server log, so I fixed that one, but I still don't know if this or some other concurrency will ever occur without testing it.
I've tried to create test in jmeter which just does simple GET and simulates 100 users.
The problem :
I retrieve some information from server when page is done loading, so I'm interested in that part(because that part cause this exception before).
But jmeter gets only the page when its loaded, and all ajax pending requests if any are not displayed in the logs. Actually I can't see anything in logs because, jmeter never reaches these ajax calls when document is ready, it exits just before that.
Naturally when I refresh page from browser I can see logs, what exactly is going on on the server side. Is there a some kind of tool, that waits for all pending requests or can stay on the website for n amount of time, or is there a smarter way to test this to avoid further concurrency exceptions.

AJAX requests are simple GET requests as well, so you just need to configure JMeter to directly call the servlets which serve them.

If you use Selenium instead of JMeter for your tests, you will spawn real browsers that will perform AJAX request exactly like the real application. Simply because it is the real application that is being run.
The problem is... Selenium is for regression testing and compatibility with browsers, not for raw performance. You can't run more than a few browser per computer. Some companies provide cluster of browserd (up to 5000 and up to 500 000 virtual user for browsermob) that you can rent for your performance campain.
You can also use the desktop computer in your office, let say the night to perform your tests.
I know this might be a little complicated and not be the best solution.

Servlet called from Icefaces webapp creates constantly high CPU usage on client

I'm developing a web application (using JBoss and Icefaces) which uses a Servlet to create a Excel or PDF file and sends it to the browser.
But I'm experiencing performance problems after the servlet was called, resulting in a constantly high (~50%) CPU consumption of the browser. Testet in Firefox and Internet Explorer on different machines. The high cpu usage arises with a little delay (half a minute) after the servlet was called and stays high (until I close the browser or reload the page).
Whether I download the created file or open it directly makes no difference.
I'm clueless how this can happen...
Is there a way to analyze/debug the browser to find out, what is causing the cpu consumption?
UPDATE:
I've found out that is definitly related to the Icefaces webapp. When I replace my direct html-link to my servlet with a javascript call which opens the servlet in a new window (with window.open), then I can download the created file without problems.
Also when I logout inside my application, the CPU usage goes back to normal again!
UPDATE:
Ok, now Firebug helped me on: After the servlet was called I can see in the Firebug Console that there are XMLHtppRequests every milliseconds. Now I can understand the CPU usage!
POST http://localhost/webapp/block/receive-updated-views
is coming on and on. Have to check this...
UPDATE:
Ok I found an iceface thread (with the corresponding iceface jira bug) but the bugtracker states this should be fixed already... somehow not for my case!

Have you tried FindBugs or other tools for static code analysis?
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Java

If the CPU consumption is really coming from the browser, then you can't do anything about it - it is either the PDF or excel viewer .
If the server is on the same machine, and the cpu load comes from the servlet, then you have to optimize it. Give us code for that.

Browsers doesn't run servlets. Browsers runs/displays the output which is produced by the servlet. It's the output which is causing a high load. Based on the as far given little information, it's hard to tell what's the problem with the output. Firebug can give lot of insights of what's going on in the webbrowser.
Usually, an extraordinary large HTML table or an inefficent piece of JavaScript code can consume a lot of CPU/memory resources. But with a binary file download like XLS/PDF, this should in fact not happen. The cause is then probably deeper. Do you see lot a resource usage when you do a file-to-file copy on the harddisk? If so, then it may probably be a bad harddisk or bad harddisk driver or harddisk DMA is being turned off.
Update: as per your investigation with help of Firebug, it look like that you're using IceFaces' ice:commandButton or ice:commandLink to download the file. Replace them by the normal JSF h:commandButton or h:commandLink so that it doesn't unnecessarily generate JS code which is responsible for that.

Problem solved (actually it's more a workaround).
It's a Iceface Prob, which should be fixed according to the bugtracker.
But as it is actually still present I could only fix it by calling the servlet in a new windows, created by javascript. (As already mentioned in my edited question).
It's really not a nice solution and has the drawback, that browser must not block popups.
But it's also a solution I've seen several times in the net (like here).
public void exportToExcel(ActionEvent e) {
JavascriptContext.addJavascriptCall(FacesContext.getCurrentInstance(), "window.open (\"downloadServlet.dl?contentType=excel\",\"report\")");
}

Java Applet starts up very slowly for some users?

[UPDATE: I forgot to add that this 30 sec. freezing problem only happens the first time I try to load a file from the server. Subsequent loads are very quick. Maybe some strange reverse DNS lookup? I am hosting on Google's appengine.]
I started a little project recently called http://www.chartle.net which is build around an applet.
Startup time is an important factor in the user's experience of an applet. I collect statistics and am shocked that I find often very long startup times (factor 50 to 100 higher then necessary)
The applet starts in 1-3 seconds depending on the speed of your computer and connection. Still for some users it takes up to 100 sec.
I have mixed results from my own tests. Mostly it is very fast but sometimes freezes the browser for a long time and the Java console doesn't tell me why. Best guess is, that it stalls when loading a saved chart.
Please help me figuring this out - best test by opening an already saved chart (click on one of the 'create' links at http://www.chartle.net/gallery)
Cheers,
Dieter

This is generic help rather than specific for your demo (which loaded fine for me in a few attempts).
Freezing applets
In the JDK bin directory there is a very handy programme called jstack. Refresh your browser window until it crashes and then run:
jstack *process_id*
This will give you the stack trace of any frozen Java process. If Java is not a separate process then you can use the browser's process (eg for Opera).
The following few problems were/are common for me:
I reccommend you use invokeLater rather than invokeAndWait on the init method (although you can't do this if you use start/stop methods)
Opera's custom java plugin acts very poorly...
Deadlocks caused by synch blocks and invokeAndWait's
Slow applets
Possibly the browser is fetching resources from the server, unable to use the jar file?

It may be that only the old plugin causes these problems. That means basically all people running on OSX and other users with Java prior to 1.6_update_10.
So, I would really appreciate people with such setups to watch their Java console and describe the first startup behaviour.
Cheers,
Dieter

How to obtain a Java stack trace from a client running under web start?

I wanted to get ideas from the SO community about this issue.
Here is the problem:
We have a user on the other side of the world launching our app through WebStart. The user, however, is complaining that her whole application freezes up and becomes unresponsive. Usually, the client is doing a lot of database queries to a distributed database.
Questions:
If we ask her to do a CTRL-Break on her application, where would the JVM write the stack trace to?
Would it be enough just to use JConsole?
Would implementing JMX beans on the client be overkill? Would it actually help in troubleshooting issues in production?
Right now the users are running on JRE 1.5.0-b08, but we do plan on migrating to JRE 6 in a couple of months.
What do you think?

José, you can get a lot of information from the JVM in a number of ways.
The best might be to enable debugging in the remote JVM. You can set them using the j2se element in the descriptor XML, as shown here. Since you can set -Xdebug you have a good start; I've never tried to do remote debugging on a web start app, so it may be a little bit of an issue setting up the remote part.
You could also set some things up yourself by adding a separate thread to talk to you remotely and send debugging messages.
You could use a native java or log4j remote logger.
If it's hanging the way you describe, though, the odds are very high that what's happening is a network hangup of some sort. Can you put some tracing/debugging onto your end of the conversation?

Instead of these debugging suggestions, why don't you install an exception handler for your threads? See java.lang.Thread.
void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Here's the relevant javadoc:
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)
If you install that in your code, and once inside Swing's EDT, then just write some java code to e-mail it to yourself, save it on a server, show it to the user, etc.

You need to have the Java Console displayed (run javaws from the command line, and select this from the Preferences dialog), then hit "v"