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 :)
Related
I am doing a project that requires me to repeatedly run a java function in python (it's like designing a learning algorithm in python but the value function was provided in java)
So what would be the practice for this scenario? Shall I use subprocess.run() to call the java function every time or shall I use the things like Py4J, Jython or JPype? What's the difference between using subprocess.run() and the others?
The efficiency should be the top concern since I need to run the same java function repeatedly.
Using subprocess has two problems. If neither one is relevant, it'll work fine.
If you're sending large amounts of data back and forth, you have to serialize it in some format to pass in via files and command-line arguments, or pipes or sockets, which can be slow.
If you're calling a whole lot of short functions instead of one occasional huge one, you'll be spending more time setting up and tearing down the JVM (and warming up the JIT) than doing actual work.
Jython has two problems. Again, if neither one affects you, it'll work fine.
It can't use many popular third-party libraries because they're built in C, for CPython.
It's out of date. The latest version implements Python 2.7, which is less than 2 years away from going out of support.
JPype has one problem, but it's a doozy. If the current fork does what you need and has no bugs blocking you, maybe it's ok anyway.
It's a vaporware project abandoned over a decade ago. It was picked up and knocked into shape by someone else a few years ago, and the current maintainer is keeping it running, and occasionally gets patches for things like working in 64-bit cygwin or updating to OS X 10.9, but it's not exactly a vibrant project with major support behind it.
Py4J has two problems.
It's incomplete. Not unusuable, and not completely moribund, but there hasn't been any visible work on it in over a year, and nobody seems interested in anything but the minimal functionality needed for Apache Spark.
It's doing the same kind of serialization you'd do with subprocess behind your back, and more beyond that for every call you make, and the FAQ justifies this by saying performance is not a priority. (Spark just ignores all of that and uses its own channels for everything.)
For more minimal use—just starting up a JVM and setting up a socket to it—it may be better than subprocess because you don't have to keep starting and tearing down a JVM, but writing a socket protocol on both sides is a little bit more work than storing files and passing filenames on the command line. (Not a huge hurdle, but a problem if you've never done this kind of thing before.)
You may also want to look at transpilers. I don't know much about any of them, but I've talked to people who are using BeeWare to compile Python 3.4 code to Java source code that they then build together with their native Java code. I'm pretty sure this won't work if you're using any C extension, but if that's not a problem for you, it might be worth considering.
What happens within a Java application running locally on a PC when the power is switched off?(Plug pulled from wall).
Does Java have a way of handling an event like this or is it simply wiped from memory as soon as the power is killed?
Edit: To be a bit more clear, I'm wondering if Java as any way of safely exiting an application in the last moments of an unexpected shutdown.
Java programs (like all programs) require a CPU and memory to operate instructions. Both elements are complex electrical circuits, they cannot work without electricity.
The only thing you can do to persist the state of your application, is to write information regarding that state to disc. The Google File System uses this method to ensure not too much information is lost if one of their (usually inexpensive machines) goes down.
Short of this. No there is no way Java can handle a power out.
I have to write a program that is thought to run 'forever' , meaning that it won't terminate regularly. Up until now I always wrote programs that would run and be terminated at the end of the day. The program has to do some synchronizations, pause for n minutes and than sync again.
AFAIK there should be no problem with my current implementation and it should theoretically run just fine, but I'm lacking any real-world experience.
So are there any 'patterns' or best practices for writing very robust and resource efficient java programs that have a very long runtime? What could be possible problems after for example a month/year of runtime?
Some background :
Java : 1.7 but compiled down to 1.5
OS : Windows (exact version is not certain yet)
Thanks in advance
Just a brain dump of all the things I've had to keep in mind when writing this kind of app.
Avoid Memory Leaks
I had an app that runs once at mid day, every day, and in that I had a FileWriter. I wasn't closing that properly, and then we started wondering why our virtual machine was going into melt down after a few weeks. Memory leaks can come in the form of anyhing really, with one of the most common examples being that you don't de-reference an object appropriately. For example, using a class's field as a method of temporary storage. Often the class persists, and so does the reference. This leaves you with objects, sitting in memory and doing nothing.
Use the right kind of Scheduler
I used a java Timer in that app, and later I learnt that it's better to use a ScheduledThreadPoolExecutor when another app was changing the System clock. So if you plan on keeping it completely Java based, I would strongly recommend using that over a Timer for all of the reasons detailed in this question.
Be mindful of memory usage and your environment
If your app is loading large amounts of data each and every day, and you have other apps running on the same server, you may want to be careful about the timing. For example, say at mid day, three of the apps run their scheduled operation, I would say running it at any other time would probably be a smart move. Be mindful of the environment in which you're executing your code in.
Error handling
You probably want to configure your app to let you know if something has gone wrong, without the app breaking down. If it's running at a certain time every few hours, that means people are probably depending on it, so I would have a function in your Java code that sends out an email to you, detailing the nature of the exception.
Make it configurable
Again, if it needs to run at various points in the day, you don't want to have to pull the thing down for a few hours to work out some minor changes to your code. Instead, port it into a java Properties file, or into an XML Config (or really, whatever). The advantage of this is that you can update your program and get it up and running before anyone really noticed the difference.
Be afraid of the static keyword
That bad boy will make objects persist, even when you destroy their parent reference. It is the mother of all memory leaks if you are not careful with it. It's fine for constants, and things that you know don't need to change and need to exist within the project to run well, but if you're using it for random values inside a project, you're going to quickly wonder why your app is crashing every few hours rather than syncing.
Props to #X86 for reminding me of that one.
Memory leaks are likely to be the biggest problem. Ensure that there are no long-term references held after an iteration of your logic. Even a relatively small object being referenced forever, will exhaust the memory eventually (and worse, it's going to be harder to detect during testing if the growth rate is 1GB/month). One approach that may help is using the snapshot functionality of profilers: take a snapshot during the pause, let the sync run a few times, and take another snapshot. Comparing these should show the delta between the synchronizations, which should hopefully be zero.
Cache maintenance is another issue. The overall size of a cache needs to be strictly limited (whereas often you can get away without in short-running programs, because everything seen will be small enough to not cause problems). Equally it's more important to do cache-invalidation properly - broadly speaking, everything that gets cached will become stale at some point while your program is still running, and you need to be able to detect this and take appropriate action. This can be tricky depending on where the golden source of the cached data is.
The last thing I'll mention is exception-handling. For short-running processes, it's often enough to simply let the process die when an exception is encountered, so the issue can be dealt with, and the app rerun. With a long-running process you'll likely need to be more defensive than this. Consider running parts of your program in threads, which can be restarted* if/when they fail. You may need a supervisor-type module, which checks that everything else is still heartbeating and reboots it if not. If appropriate to your structure, this is anecdotally a lot easier to achieve with actors-style libraries rather than Java's standard executors. And if it's at all possible, you may want to have hooks (perhaps exposed over JMX/MBeans) that let you modify the behaviour somewhat, to allow a short-term hack/workaround to be affected without having to bring the process down. Though this requires quite some amount of foresight to predict exactly what's going to go wrong in several months...
*or rather, the job can be restarted in another thread
I'm new here and I'm not that very good in CPU consumption and Multi Threading. But I was wondering why my web app is consuming too much of the CPU process? What my program does is update values in the background so that users don't have to wait for the processing of the data and will only need to fetch it upon request. The updating processes are scheduled tasks using executor library that fires off 8 threads every 5 seconds to update my data.
Now I'm wondering why my application is consuming too much of the CPU. Is it because of bad code or is it because of a low spec server? (2 cores with 2 database and 1 major application running with my web app)
Thank you very much for your help.
You need to profile your application to find out where the CPU is actually being consumed. Java has some basic profiling methods built in, or if your environment permits it, you could run the built in "hprof" compiler:
java -Xrunhprof ...
(In reality, you probably want to set some extra options: Google "hprof" for more details.)
The latter is easier in principle, but I mention the possibility of adding your own profiling routine because it's more flexible and you can do it e.g. in a Servlet environment where running another profiler is more cumbersome.
Paulo,
It is not possible for someone here to say whether the problem is that your code is inefficient or the server is under spec. It could be either or both of those, or something else.
You are going to need to do some research of your own:
Profile the code. This will allow you to identify where your webapp is spending most of its time.
Look at the OS-level stats that are available to you. This might tell you that the real problem is memory usage or disk I/O.
Look at the performance of the back-end database. Is it using a lot of CPU?
Once you have identified the area(s) where the CPU is being used, you need to figure out the real cause of the problem is and work out how to fix it. And once you've got a potential fix implemented, you can rerun your profiling, etc to see it has helped.
We have a bug we're trying to find that happens non-deterministically (well, it's deterministic, but we just don't know what's actually causing it) and it only happens once every couple hours.
We read a lot of network data, and we have many threads, so there's a likelihood it's from an input, race condition, or combination of both, but for the most part, unreproducible.
I'm wondering if there are any JVM recorders / replayers out there that can store everything that happened in a JVM so we can then go through it step by step and recreate the steps to the exception.
I've found one. (I'm not going to post it so people don't think I'm trying to advertise a product.), but I'm wondering if there are others, and more importantly, others that people have used, and can report that work well.
Edit to add:
I've found Replay Solutions. I've never used it, and I've never heard of it, so I don't know how good it actually is.
We use JProfiler, but I don't think it actually has support to record/replay everything.
I would suggest using Chronon it worked well for me, but I haven't used it extensively yet.
It is not possible (except maybe for micro-benchmarks) to record everything, especially because of the thread interleavings: the performance degradation/slowdown would be too severe. If the problem you are trying to reproduce is a concurrency bug you may want to try systems that perform partial logging and complete the interleaving using SMT solving:
http://www.gsd.inesc-id.pt/~nmachado/software/Symbiosis_Tutorial.html
To the extent of my knowledge, this is the most recent system, and is available open-source (in java, c and c++).