Fork and Join: Java Can Excel at Painless Parallel Programming Too!

Fork and Join: Java Can Excel at Painless Parallel Programming Too!:

How do the new fork/join tasks provided by Java SE 7 make it easier to write parallel programs?

Published July 2011

Downloads:
 Java SE 7
 Sample Code(Zip)

Multicore processors are now widespread across server, desktop, and laptop hardware. They are also making their way into smaller devices, such as smartphones and tablets. They open new possibilities for concurrent programming because the threads of a process can be executed on several cores in parallel. One important technique for achieving maximal performance in applications is the ability to split intensive tasks into chunks that can be performed in parallel to maximize the use of computational power.

Dealing with concurrent (parallel) programming has traditionally been difficult, because you have to deal with thread synchronization and the pitfalls of shared data. Interest in language-level support for concurrent programming on the Java platform is strong, as proven by the efforts in the Groovy (GPars), Scala, and Clojure communities. These communities all try to provide comprehensive programming models and efficient implementations that mask the pain points associated with multithreaded and distributed applications. The Java language itself should not be considered inferior in this regard. Java Platform, Standard Edition (Java SE) 5 and then Java SE 6 introduced a set of packages providing powerful concurrency building blocks. Java SE 7 further enhanced them by adding support for parallelism

The following article starts with a brief recall of concurrent programming in Java, starting with the low-level mechanisms that have existed since the early releases. It then shows the rich primitives added by the java.util.concurrent packages before presenting fork/join tasks, an essential addition provided in Java SE 7 by the fork/join framework. An example usage of the new APIs is given. Finally, a discussion on the approach precedes the conclusion.

In what follows, we assume that the reader comes from a Java SE 5 or Java SE 6 background. We present a few pragmatic language evolutions of Java SE 7 along the way.

'via Blog this'

High Scalability - High Scalability - Google Architecture

High Scalability - High Scalability - Google Architecture:

Lessons Learned

1. Infrastructure can be a competitive advantage. It certainly is for Google. They can roll out new internet services faster, cheaper, and at scale at few others can compete with. Many companies take a completely different approach. Many companies treat infrastructure as an expense. Each group will use completely different technologies and their will be little planning and commonality of how to build systems. Google thinks of themselves as a systems engineering company, which is a very refreshing way to look at building software.
2. Spanning multiple data centers is still an unsolved problem. Most websites are in one and at most two data centers. How to fully distribute a website across a set of data centers is, shall we say, tricky.
3. Take a look at Hadoop if you don't have the time to rebuild all this infrastructure from scratch yourself. Hadoop is an open source implementation of many of the same ideas presented here.
4. An under appreciated advantage of a platform approach is junior developers can quickly and confidently create robust applications on top of the platform. If every project needs to create the same distributed infrastructure wheel you'll run into difficulty because the people who know how to do this are relatively rare.
5. Synergy isn't always crap. By making all parts of a system work together an improvement in one helps them all. Improve the file system and everyone benefits immediately and transparently. If every project uses a different file system then there's no continual incremental improvement across the entire stack.
6. Build self-managing systems that work without having to take the system down. This allows you to more easily rebalance resources across servers, add more capacity dynamically, bring machines off line, and gracefully handle upgrades.
7. Create a Darwinian infrastructure. Perform time consuming operation in parallel and take the winner.
8. Don't ignore the Academy. Academia has a lot of good ideas that don't get translated into production environments. Most of what Google has done has prior art, just not prior large scale deployment.
9. Consider compression. Compression is a good option when you have a lot of CPU to throw around and limited IO.

'via Blog this'

Netflix Log4J Optimizations Yield Logging at Massive Scale

Netflix Log4J Optimizations Yield Logging at Massive Scale:

Blitz4k, Netflix’ internally optimized version of log4j, has been released to Github. Blitz4j efficiently generates logs within a massively concurrent and heavy traffic environment while consuming fewer resources than other, more traditional logging technologies. It achieves this by overriding sections of log4j’s code where synchronization and deadlocks may occur.

Netflix changes to log4J include:

1. Removing all critical synchronizations with concurrent data structures.
2. Providing extreme configurability in terms of in-memory buffer and worker threads
3. More isolation of application threads from logging threads by replacing the wait-notify model with an executor pool model.
4. Better handling of log messages during log storms with configurable summary.

Netflix reports that the cost of logging 300-500 lines per second has dropped by at least 75% by using Blitz4j and spikes of processor activity associated with synchronization have disappeared completely. Applications are now able to respond within an acceptable timeframe even during periods of heavy usage and heightened logging.

As their traffic and need for logging per instance increased, Netflix noticed that log4j consumed more and more resources and slowed the very processes it was logging. They were hesitant to move to a different logging technology such as LogBack because of their heavy investment in log4j. They instead chose to override log4j and customize it for non-blocking, asynchronous logging. The log4j framework is largely unchanged; only the areas that affected scalability were altered.

Netflix’s Karthikeyan Ranganathan recognizes that Blitz4j may not be the best choice for projects just getting off the ground. LogBack is a product from the team that delivered log4j that addresses many of the concerns offered by the Netflix team. In this aspect, projects without the investment in the traditional log4j framework or have been built against slf4j should consider using LogBack over Blitz4j. But for companies with a significant investment in log4j, Blitz4j is a valid option to enable logging at internet scale.

'via Blog this'

Java Heap Dump: Are you up to the task? | Java Code Geeks

Java Heap Dump: Are you up to the task? | Java Code Geeks:

'via Blog this'

Java 7 #8: NIO.2 File Channels on the test bench | Java Code Geeks

Java 7 #8: NIO.2 File Channels on the test bench | Java Code Geeks:

'via Blog this'