Finally we made it. Thanks to Alex the healthcheck binaries are available now in the public sonatype repository. If you have already included the this repository to your pom.xml, you only need to add these dependencies to your pom.xml:

<dependency>
<groupId>de.joerghoh.cq5.healthcheck</groupId>
  <artifactId>core</artifactId>
  <version>1.0.0</version>
  <type>pom</type>
</dependency>
<dependency>
  <groupId>de.joerghoh.cq5.healthcheck</groupId>
  <artifactId>core</artifactId>
  <version>1.0.0</version>
  <type>pom</type>
</dependency>

I also recommend you to add the jmx-extension bundle, as it adds some really useful MBeans.

<dependency>
  <groupId>de.joerghoh.cq5.healthcheck</groupId>
  <artifactId>jmx-extension</artifactId>
  <version>1.0.0</version>
  <type>pom</type>
</dependency>

We will continue the development over at github, we appreciate your feedback.

The overall performance test is usually grouped into smaller test chunks (I call them scenarios), which replicate certain aspects of the daily operation like:

• normal operation
• many people login into the system during the start of the business hours
• your marketing campaign got viral and now huge traffic spikes come over from Twitter/Facebook/G+/…
• how can your system handles traffic when some are down for maintenance?
• you are preparing a huge amount of new content on authoring
• (and many more …)

Collect the scenarios you know you will have, and detail them out. If you have historical data on them, use them. If you don’t have such data, start with rough estimations. You will adjust them afterwards anyway by any feedback of your production system.

A performance test scenario consists at least of these items:

1. Objectives what should be tested (the “questions” of part 2); this objectives should detailled and clear, usually they are oriented on the aspect of the daily operations you just identified.
2. A number of test cases, which are executed during the performance test; in most real-life situations multiple different activities are carried out in parallel, and your performance test scenarios should reflect that.
3. Systems and environments, where the tests are executed and can deliver meaningful results.
4. Facilities to monitor the systems, which are involved in the test execution; it should be described, which information is considered valuable for this test scenario and which should preserved for analysis.
5. Instructions how to interpret the monitoring data gathered throughout the test execution.
6. Instructions how the test should be executed.
7. In the end there should be a clear answer if the objectives have been met.

All of the aspects should be covered. And now it is clear, why good performance test is nothing which can done without preparation and within 1 day. Such adhoc tests usually never deliver proper results, because they heavily focus on the test execution and less on proper preparation of the test cases and the interpretation of the results.

Even if you plan much more scenarios than you will ever execute: Just thinking of them, planning and defining them often gives you valuable input for your application design. As in many cases functional test planning makes you think about system, about expected behaviour and error handling. It’s the same here.

(Applying the TDD mechanisms to performance tests would be an interesting exercise …)

Performance tests sometimes have a myth around them, depending on the personal experience people have made with them. For some it’s just a waste of time and effort, because the last test they conducted has not delivered any value. For others it’s the best since sliced bread.

With performance tests it’s the same as with every test: You need to ask a question and model an appropriate test case, then you get an answer for it. A performance test cannot tell you things about your system, which you have not asked. Especially it cannot give you any guarantee, that you system is rock-solid and fast (even if you ask this question :-))
It is not a silver bullet for any problem. But it is an important step to a point where you can start to trust your system to function properly.

So, what’s this “asking”? In Performance testing you ask questions by designing and executing a test case. When your test case is like this “Execute 100 requests to this specific URL with 10 concurrent threads, the response should be received within 500 milliseconds, no errors are allowed”, the question could be like this “Can my system copy with 10 concurrent users and respond to them within 0.5 seconds with no  errors”. The execution of the performance test can then answer the question with “yes” or “no”, depending on the outcome.

If the outcome is “no”, we obviously have to change this and work on our systems and our code to get the answer we are aiming for: “ok”. But our success is limited then. Even in the “ok” case we cannot infer, that with 15 concurrent users the system is still working ok, but slower than with 10 concurrent requests. This is an assumption we often do because we have only a limited set of validated results, and technically we should validate them all. So every test case answers exactly one question, gives us only one piece of information about the performance behavior of the system. For all other questions we have to create different performance test cases. (There will be a follow-up article on this topic…)

So, as a conclusion, the quality of the results of your performance result is directly depending on the questions you ask. For this reason you should invest a good amount for the preparation of your performance tests to define the right questions.

The JCR 2.0 specifications says about sessions:

A user connects to a repository by passing a set of credentials and the name of the workspace that the user wishes to access. The repository returns a session which binds the user to the requested persistent workspace with a level of authorization determined by that user’s credentials. A session is always bound to exactly one persistent workspace, though a single persistent workspace may be bound to multiple sessions.

In the implementation of Jackrabbit/CRX it means that the session enforce authorization; if a user is not authorized to see nodes, the session will not expose them to the user. It’s just as they are not there. Workspace handling is in the case of CQ5 not really relevant, as only the “crx.default” workspace is used.

But what does this mean for your work with CQ5?

• So first of all, sessions are an integral concept of security within CQ5. A normal user session is different from an admin session. In a user session normally less nodes than in an admin session are visible. You cannot just switch the user context within a session, but you create a new one.
• In an admin session you are not restricted at all, you can do everything.
• In the context of requests to templates and components, you will work with an authenticated session (or anonymous sessions in the standard publish case). Sling authenticates the request and provides you an appropriately authenticated session, and closes this specific session when the request processing is done. Do not close this session!
• In a request scope you normally should not need to create a new session. You should leverage the session associated with the request.
• Not closing a single session isn’t a problem, but not closing many session will cause a serious memory leak.
• Sessions are cheap. You can create as many of them as you need. So it’s perfectly ok to open a session to change a few properties and then close that session again. Try to have sessions as short-lived as possible.
• The only exception from this rule are sessions, in which you have registered a JCR observation listener. But use these sessions only for reading. If you need to write to the repository in an observation listener, create a new session for these write operations.
• In most cases Unix daemons work in the context of a specialized user to limit the impact of a security breach through this daemon. You should act alike and use specialized user sessions if you work with JCR sessions. For 99% of all usecases you should not use an admin session!
• If you want to run a session with a less privileged user than the admin, you should use the impersonation feature of JCR. Do not hardcode any user password in your code. This code fragment shows how you can use impersonation to create a session with a different user than admin, but without hardcoding the password of that user:

private static final RUNAS_USER="technical_user";
@Reference
SlingRepository repo;
Session adminSession = null;
Session userSession = null;
try {
  Session adminSession = repo.loginAdministrative(null);
  userSession = adminSession.impersonate(new SimpleCredentials(RUNAS_USER,"".toCharArray()));
  adminSession.logout();
  adminSession = null;
  doSomethingWith(userSession);
} catch (RepositoryException e) {
  // report exception
} finally {
  if (adminSession != null) {
    adminSession.logout();
  }
  if (userSession != null) {
    userSession.logout();
  }
}

Update March 19th 2013: My colleague Alex Klimetschek recommended me to add this statement: “Admin sessions sound so useful. But they are dangerous!”
Update April 9th 2013: SimpleCredentials take in the constructor a char array as password, not a String. Thanks Anand.

In between all the hyping of the CQ5 healthcheck I want to tell you some bits which has more impact on your daily life as a developer. Today I want to tell you some bits and pieces about logging.

Logging is one of the unloved children of a web project. It’s mostly never stated in the project requirements, but every developer adds logging statements. Everybody has some ideas, what should be logged, but it is never explicitly defined. While I base my recommendations on CQ5 projects, they can be applied widely. And for Java there are — of course — lot of great postings out there, which have tips and tricks on that topic. I just found 10 tips for proper application logging. Sounds pretty good.

But here goes my personal list of best practices (all of them pretty obvious, right?)

• Use the SLF4J logging framework, as it is the standard logging for sling; there’s no need to introduce another logging framework.
• Do not use the log levels INFO,WARN and ERROR for debugging your code during development. You won’t have the time to fix them, and then you will pollute the production log with your debugging statements. Your operation people will hate for that, because the CQ5 standard loglevel is “INFO”.
• Instead use the loglevel “DEBUG” and a special logging configuration for your development environment, which logs your debug statements.
• Cleanup your debug statements when you are done with development. In production environment I recommend to setup logging on level DEBUG if there are problems with some parts of the application. The last thing I want to see are statements like “loop1”, “Inside for-loop” and “1234” (yes, I have seen them.)
• Ask yourself: Does a piece of code, which does not have logging statements, really perform any function? Even it is perfect written code with no bugs it is sometimes interesting, what information are processed. So every code should contain debug statements.
• Stacktraces are sometimes a valuable asset. Which also means, that not always a full stacktrace is required.
• And the most important: Do not use “System.out.println()”!

If you ask yourself “What should I log”, change perspective. Just imaging that someone strongly assumes an issue in your code. What information do you need to investigate on this? — Add this information in proper DEBUG statements.

So, that’s for today’s lesson. Stay tuned! CQ 5.6 is coming …