Intro to Mule webinar

27 червня відбудеться вебінар Intro to Mule ESB

Посилання на реєстрацію тут

Garbage Collection in Java (4)

G1: Garbage First

The G1 collector is the latest collector to be implemented in the hotspot JVM. Its been a supported collector ever since Java 7 Update 4. Its also been publicly stated by the Oracle GC Team that their hope for low pause GC is a fully realised G1. This post follows on from my previous garbage collection blog posts:

1. Overview of GC in Hotspot.
2. Parallel Garbage Collectors.
3. Concurrent Mark Sweep.

Garbage Collection in Java (3)

This follows on from my previous two garbage collection blog posts:

1. Overview of GC in Hotspot.
2. Parallel Garbage Collectors.

Concurrent Mark Sweep

The parallel garbage collectors in Hotspot are designed to minimise the amount of time that the application spends undertaking garbage collection, which is termed throughput. This isn't an appropriate tradeoff for all applications - some require individual pauses to be short as well, which is known as a latency requirement.

The Concurrent Mark Sweep (CMS) collector is designed to be a lower latency collector than the parallel collectors. The key part of this design is trying to do part of the garbage collection at the same time as the application is running. This means that when the collector needs to pause the application's execution it doesn't need to pause for as long.

At this point you're probably thinking 'don't parallel and concurrent mean something fairly similar?' Well in the context of GC Parallel means "uses multiple threads to perform GC at the same time" and Concurrent means "the GC runs at the same time as the application its collecting".

Garbage Collection in Java (2)

Parallel Scavenge

Today we cover how Parallel GC works. Specifically this is the combination of running a Parallel Scavenge collector over Eden and the Parallel Mark and Sweep collector over the Tenured generation. You can get this option by passing in -XX:+UseParallelOldGC though its the default on certain machine types.

You may want to read my first blog post on Garbage Collection if you haven't since this gives a general overview.

Garbage Collection in Java (1)

This is the first in a series of posts about Garbage Collection (GC). I hope to be able to cover a bit of theory and all the major collectors in thehotspot virtual machine over the course of the series. This post just explains what garbage collection is and elements common to different collectors.

Why should I care?

Your Java virtual machine manages memory for you - which is highly convenient - but it might not be optimally tuned by default. By understanding some of the theory behind garbage collection you can more easily tune your collector. A common concern is collector efficiency, that is to say how much time your program spends executing program code rather than collecting garbage. Another common concern is long that application pauses for.

There's also a lot of hearsay and folklore out there about garbage collection and so understanding the algorithms in a bit more detail really helps avoid falling into common pitfalls and traps. Besides - for anyone interested in how computer science principles are applied and used, JVM internals are a great thing to look at.

Fridays Fun

Webinar: Decomposing Applications for Deployability and Scalability

10 Tips for Proper Application Logging

1) Use the appropriate tools for the job

Many programmers seem to forget how important is logging an application’s behavior and its current activity. When somebody puts:

1	log.info("Happy and carefree logging");

happily somewhere in the code, he probably doesn’t realize the importance of application logs during maintenance, tuning and failure identification. Underestimating the value of good logs is a terrible mistake.

In my opinion, SLF4J is the best logging API available, mostly because of a great pattern substitution support:

1	log.debug("Found {} records matching filter: '{}'", records, filter);

In Log4j you would have to use:

1	log.debug("Found " + records + " records matching filter: '" + filter + "'");

This is not only longer and less readable, but also inefficient because of extensive use of string concatenation. SLF4J adds a nice {} substitution feature. Also, because string concatenation is avoided and toString() is not called if the logging statement is filtered, there is no need for isDebugEnabled() anymore. BTW, have you noticed single quotes around filter string parameter?

SLF4J is just a façade. As an implementation I would recommend the Logback framework, already advertised, instead of the well establishedLog4J. It has many interesting features and, in contrary to Log4J, is actively developed.

The last tool to recommend is Perf4J. To quote their motto:

Perf4J is to System.currentTimeMillis() as log4j is to System.out.println()

I’ve added Perf4J to one existing application under heavy load and seen it in action in few other. Both administrators and business users were impressed by the nice graphs produced by this simple utility. Also we were able to discover performance flaws in no time. Perf4J itself deserves its own article, but for now just check their Developer Guide.

Additionally, note that Ceki Gülcü (founder of the Log4J, SLF4J and Logback projects) suggested a simple approach to get rid of commons-loggingdependency (see his comment).

Estimating Might Be Broken, But It’s Not Evil (не по темі, але цікаво)

Ron Jeffries's essay Estimation is Evil talks about how absurd estimating can be on a software project, and the nightmare scenarios that teams can end up in:

…Then we demand that the developers “estimate” when they’ll be done with all this stuff. They, too, know less about this product than they ever will again, and they don’t understand most of these requirements very well. But they do their best and they come up with a date. Does the business accept this date? Of course not! First of all, it’s only an estimate. Second, clearly the developers would leave themselves plenty of slack—they always do. Third, that’s not when we want it. We want it sooner. 

So we push back on the developers’ estimate, leaning harder and harder until we’re sure we’ve squeezed out all the fat they left in there. Sometimes we even just tell them when they have to be done. 

Either way, the developers leave the room, heads down, quite sure that they have again been asked to do the impossible. And the business people write down the date: “Development swears they’ll be done November 13th at 12:25PM.”

JUG 22 Feedback

В четвер пройшла остання наша зустірч і невиликий фідбек по ній:

Перш за все, хочу сказати спасибі автору, Сергію і  всім хто пиєднався.
Цього разу нас було близько 50 людей.

Як ви мабуть занєте, це була перша самостійна зустріч, тому пива не була, але були халявні ручки :)

Також хочу нагадати про JDay.com.ua  - поспішайте зареєструватись.
Залишилось мало часу і ще менше вільних місць!


Відео:
http://www.youtube.com/watch?v=LR8fQiskYII
http://www.youtube.com/watch?v=NvWTnIoQZj4

Презентація:

Right Tool for the Job: Як правильно вибрати мову програмування from Serhiy Batyuk

Java in One day (not finished)

http://www.paradise.caltech.edu/cook/Workshop/Java/Overview.html

Fridays Fun

JUG 22 Right Tool for the Job: Як правильно вибрати мову програмування

Вперше JUG Львів проводить повністю незалежну зустріч.

Запрошуємо вас 13 четвер о 19.00  За адресою вул.Федьковича 60а - 2-ий поверх - конференц зал.

На зустрічі будем слухати призентацію про вибір мов програмування для різних проектів:
Right Tool for the Job: Як правильно вибрати мову програмування

Доповідач: Сергій Батюк

Мапа: тут

Як завжди просимо Вас зареєструватись:  

JBoss AS changed name ...

JBoss AS changed name  to Wildfly.

You can find more details and interesting info here: http://www.wildfly.org/

Guava's EventBus - Simple Publisher/Subscriber

Looking over recent additions to Google's Guava Libraries Release 10 I noticed the addition of EventBus. This is a lightweight implementation of a publish-subscribe style messaging system. This is similar to the publish-subscribe model provided by JMS, however the messages remain within the application rather than being broadcast externally.

EventBus allows you to create streams within your program to which objects can subscribe; they will then receive messages published to those streams. Although this inter-object communication is not particularly difficult to recreate using patterns such as singletons, EventBus does provide a particularly simple and lightweight mechanism. Singletons also make having multiple event buses of a single type more difficult, and are hard to test.

As an example I am going to create a simple multi-user chat program using sockets that several people will connect to via telnet. We will simply create an EventBus which will serve as a channel. Any messages that a user sends to the system will be published to all the other users.