StackOverflow, meet Raspberry Pi

Like many people (in the hundreds of thousands, so I understand), I'm waiting for a Raspberry Pi.

As an avid StackOverflow user, I'm very much interested in promoting a new beta site they're proposing, whcih will be dedicated to the Pi. StackOverflow's model promotes participation and moreover, promotes correct answers, and I find I'm using it more and more, searching for answers, asking questions and trying to help others.

If you're awaiting a Pi like me, take a look, cast a vote:

Awesome JQuery from Ubuntu

Ubuntu 11.1 has an online demo, which is made up from a load of Javascript, but looks like a real UI. The virtual Firefox app has history states and lets you open other websites - including the demo site...

It's an awesome bit of coding with massive potential. They're not far away from making a web based UI layer that would allow users to manage virtual servers over port 80...

http://www.ubuntu.com/tour/#

My experiences with JMeter and PeopleSoft

Over the past few months, I've carried out more performance testing than I'd have chosen to, mostly against PeopleSoft in different environments. There are a number of sites that gave me useful tips to get through the process, and I thought I'd share them here.

It's also useful to know what breaks :)

About JMeter

JMeter is an extensible Java based tool to conduct various different types of testing, including functional, regression, load, soak and stress testing. Tests are controlled either from a graphical user interface or from the command line, and the ‘master’ host can control several ‘injectors’.

JMeter is an open source package from the Apache Software Foundation. For this project, it carries several advantages:

1. It carries no license fee
2. It can be extended
3. It has a fairly simple user interface
4. It supports multiple test injectors, required to push the system to its limits

JMeter is not a perfect tool, and has some disadvantages too, such as a slightly buggy user interface and slightly sparse reporting capabilities. Despite this, it is the best of the crop of open sourced options. Utilizing third party plugins can mitigate the sparse reporting.

My PeopleSoft test plans generally follow this structure:

Basically, this test will just perform a login. It includes a bunch of required elements for any PeopleSoft test - it extracts a session variable using a regular expression, ICSID, which you can use in other test elements further down, it includes a cookie manager (set to 'compatibility mode' - default setting will not work), and it includes a sampler to 'grab test data' - this accesses a simple web service I wrote that provides a row of test data in XML format - this adds next to no additional time to the test, but is really useful because when testing using multiple test injectors, it means that I don't need to copy data across to each server.

Recording the test is reasonably straightforward, but there are some gotchas. Firstly, you want to add an HTTP proxy element to the 'workspace' element, and set that up to use HTTP Client for the HTTP samplers. You also want to add some variables to a config element, including the PeopleSoft environment name, host, port, and protocol. For example:

1) PsEnv=DMO

2) host=localhost

3) port=80

4) protocol=http

If you do this, then when the proxy is recording test elements, it'll automatically replace DMO with ${PsEnv}, etc., saving an awful lot of time processing your test afterwards. You'll also find that most processes in PeopleSoft actually entail multiple GET and POST requests to the same URL. When you run your test, these will get grouped in the results. You can tell JMeter to prefix each sampler name with a counter by editing the JMeter.properties file.

An article on how to configure the ICSID parameter is here: http://www.erpassociates.com/peoplesoft-corner-weblog/utilities/using-jmeter-for-peoplesoft-performance-testing.html

With the ICStateNum parameter, if you leave it in your tests, you'll get the login page all the time. It seems to be OK to simply remove it from tests.

When you're looking at results, always add a 'View Results Tree' element while you're developing the test - this will allow you to see individual HTTP requests and responses (rendered as HTML!). This is incredibly useful.

If you decide to add 'user wait time' to your test, so you can pad out a transaction to take about as long as a real user would take, be aware of the scope of timers in JMeter. If you have a sampler followed by a timer, followed by two more samplers, then each sampler will get the same delay added. This is probably not what you want. Instead, add timers as child nodes for a sampler you want to have a delay after.

I also found the following useful:

• http://javaworks.wordpress.com/2010/06/15/functions-in-jmeter-bean-shell/
• http://www.javaworld.com/javaworld/jw-07-2005/jw-0711-jmeter.html?page=1
• http://code.google.com/p/jmeter-plugins/downloads/detail?name=JMeterPlugins-0.4.1.zip

Especially the last item - JMeter plugins has some very useful charts, including threads over time - if your test uses many injectors, this is a useful way to see when your test is ramped up, and if there are problems with the injectors failing.

Finally, it's a good idea to run JConsole against your injector JVMs. This will give you a feel for how much load you can push through from a single host. In our tests, with user wait times, we found we were able to push through 800 to 1000 users (threads), each with user wait time. All this took was to tweak the JVM heap size in the jmeter.bat file, since the servers we were using as injectors each had plenty of CPU power and memory.

• 
  

Java just isn't being friendly today

Is it just me? Shouldn't Java app servers be more consistent?

I'm developing a commercial web application. This app must work in a variety of application servers, on a variety of databases, with minimal configuration of the kind that doesn't require users to understand Java.

So, I'm using Hibernate, and after a lot of faffing, have got Hibernate to work using a SequenceStyleGenerator (very nice) so it can handle different id generation schemes (sequences vs auto-increment).

I'm also using Spring, for dependency injection, transactions, and a bunch of other things like MVC, annotations and security. Spring is very nice for all of these things, but is a bit of a pain when it comes to changing anything without opening up the WAR / EAR.

My datasource, defined in Spring config, gets DB connections from a JNDI lookup. I define that JNDI lookup in the application server, but of course every application server exposes JNDI in a different way, so unless I want to maintain different WAR file builds for different application servers, I need a way to change the properties on startup.

Recently, I started using Spring's PropertyPlaceholderConfigurer, which takes a properties file as an argument: in my case 'classpath:my.properties'. This allows me to externalise the properties for the key things that need to be changed, like the datasource.

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
 <property name="location">
  <value>classpath:my.properties</value>
 </property>
</bean>

So now my datasource bean declaration is

<jee:jndi-lookup id="dataSource" name="${myDatasource}" />

All well and good. In most app servers, you then just drop the properties file on the classpath. In Weblogic (on Windows in this case), however, try as I might, I just couldn't get the thing to recognise the properties file, and since the datasource is pretty central to the app, it just didn't start. It's apparently not enough to just put it in the lib directory that Weblogic happily loads JAR files from.

The solution, which was simple, took a long time as I tried different things. It involves editing %WL_HOME%/user_projects/domains/base_domain/bin/setDomainEnv.cmd and adding the following line near the top:

set CLASSPATH=.;%CLASSPATH%

All this does is add the current directory to the classpath. Then, just drop the properties file into %WL_HOME%/user_projects/domains/base_domain and you're good to go.

Next problem! JNDI woes. I'd done this before in Weblogic and thought I had it sussed, so was disappointed when it suddenly stopped. I'd created my datasource with a JNDI name of jdbc/myDS, and I was looking up that same name from my Spring config (no need to prepend java:comp/env/ in Weblogic). But it didn't work. The solution, again simple when you know, is to make sure that you don't click 'Finish' prematurely when creating the datasource, but click 'Next' straight to the final screen, where you choose the 'targets'. If you're using a default install, that target will be 'AdminServer'. Then it will work.

Nice slides about negative corporate environments

Corporate Design vs Startup Design - A Love Story

View more presentations from Amir Khella.

Sequences not allowed here

OK, this was just annoying, but since I couldn't find anything on the web when I looked, here's what my problem was:

I was modifying some hibernate code to use the SequenceStyleGenerator annotation, so it will work cross-DB. I'd initially developed using MySQL, and had a MySQL hibernate dialect specified in my config files. I exported the schema to an Oracle XE instance using hbm2ddl in Eclipse, and started using an Oracle driver in my datasource.

Every time I tried to insert anything, I got an oracle error - Sequence not allowed here. Ultimately, just removing the dialect entirely from the config files worked, since Hibernate can auto-detect the dialect most of the time.

Hibernate / Spring WAR issues in Weblogic 10 - antlr

I had an issue today deploying a straightforward WAR file to WLS 10. The classloader hierarchy was preventing Hibernate from using the correct version of the antlr jar that was bundled in my webapp.

For my particular situation, the solution had to be simple. In the end, I created a new Eclipse project to bundle the WAR into an EAR, and then added a file called weblogic-application.xml in the META-INF folder of that EAR with the following content:

<weblogic-application>
   <prefer-application-packages>
       <package-name>antlr.*</package-name>
   </prefer-application-packages>
</weblogic-application>

..which solves the problem.