YantraStructure

The better your JVM performs, the better your installation of Tomcat will perform. It's as simple as that. Getting the most out of your JVM is a matter of configuring its settings to match your real-world performance needs as closely as possible. Update your JVM to the latest version, establish some accurate benchmarks so you have a way of quantifying any changes you make, and then get down to business. Effective Memory Management The main thing to consider when tuning your JVM for Tomcat performance is how to avoid wasting  memory  and draining your server's power to process requests. Certain automatic JVM processes, such as garbage collection and memory reallocation, can chew through memory if they occur more frequently than necessary. You can make sure these processes only occur when they need to by using the JAVA_OPTS -Xmx and -Xms switches to control how JVM handles its heap memory. If your JVM is invoking garbage collection too frequently, use the -Xmx switch to s

Optional References NulPointers are like  stubbing your toes  - you’ve been doing it since you could stand up, and no matter how smart you are today - chances are you still do. To help with this age-old problem Java 8 is introducing a new template called  Optional<T> .   Borrowing from Scala and Haskell, this template is meant to explicitly state when a reference passed to or returned by a function can be null. This is meant to reduce the guessing game of whether a reference can be null, through over-reliance on documentation which may be out-of-date, or reading code which may change over time. Optional < User > tryFindUser( int userID) { or - void processUser( User user, Optional < Cart > shoppingCart) { The Optional template has a set of functions that make sampling it more convenient, such as isPresent()  to check if an non-null value is available, or   ifPresent()  to which you can pass a Lambda function that will be executed if isPresent is true. T

Launching an OS process from within your code is right there with JNI calls – it’s something you do half-knowing there’s a good chance you’re going to get some unexpected results and some really bad exceptions down the line. Even so, it’s a necessary evil. But processes have another nasty angle to them - they have a tendency to dangle. The problem with launching process from within Java code so far has been that is was hard to control a process once it was launched. To help us with this Java 8 introduces three new methods in the  Process  class - destroyForcibly  - terminates a process with a much higher degree of success than before. isAlive  tells if a process launched by your code is still alive. A new overload for waitFor() lets you specify the amount of time you want to wait for the process to finish. This returns whether the process exited successfully or timed-out in which case you might terminate it. Two good use-cases for these new methods are - If the process d

// For Index SELECT  relname FROM pg_class WHERE oid IN     (SELECT indexrelid FROM pg_index, pg_class        WHERE pg_class.relname='emp'         AND pg_class.oid=pg_index.indrelid         AND indisunique != 't' AND indisprimary != 't'); // For unique SELECT  relname FROM pg_class WHERE oid IN     (SELECT indexrelid FROM pg_index, pg_class        WHERE pg_class.relname='emp'         AND pg_class.oid=pg_index.indrelid         AND indisunique = 't' AND indisprimary != 't'); // For primary SELECT  relname FROM pg_class WHERE oid IN     (SELECT indexrelid FROM pg_index, pg_class        WHERE pg_class.relname='emp'         AND pg_class.oid=pg_index.indrelid         AND indisprimary = 't');

Multi-threaded code has long been the bane of server developers (just ask Oracle Java Language Architect and concurrency guru  Brian Goetz ). Over time complex idioms were added to the core Java libraries to help minimize thread waits when accessing shared resources. One of these is the classic ReadWriteLock that lets you divide code into sections that need to be mutually exclusive (writers), and sections that don’t (readers). StampedLock has an "optimistic" mode that issues a stamp that is returned by each locking operation to serve as a sort of admission ticket; each unlock operation needs to be passed its correlating stamp. Any thread that happens to acquire a write lock while a reader was holding an optimistic lock, will cause the optimistic unlock to be invalidated (the stamp is no longer valid). At that point the application can start all over, perhaps with a pessimistic lock (also implemented in StampedLock.) Managing that is up to you, and one stamp cannot be us