From the Blogosphere

Mobile SOA with Tuscany Android

Mon, 23 Nov 2009 20:30:00 EST

In Apache Tuscany, we have been experimenting with Google Android Platform to build Mobile SOA Applications, and we now have couple Android based samples that demonstrate a Android mobile application consuming SCA services available on the cloud. Store-android: A front end to our "Store Getting Started Guide" that consumes the catalog and shopping cart services and allow you to shop for fruits and vegetables. SCATour-android: A front end to the "SCA Tour" scenario that allows you to search for trips direct from your Android phone.

IT's Groovy Time Flashback

Tue, 17 Nov 2009 09:30:00 EST

As virtualization-lite creates swarms of increasingly dense VLANs in the data center, the IT industry appears to be responding by consolidating into coalitions, including Arcadia (EMC, VMW, and CSCO); HP/COMS; and IBM/JNPR. Each coalition will likely produce its own "branded container" dedicated to the simplification and tactical orchestration of growing VLAN empires. This consolidation takes us back to the 70s when IBM and the BUNCH offered ever-shrinking choices to smocked IT decision makers. Years later the network evolved and disrupted the consolidation with new equipment categories, new solutions and emergent demands soon addressed by a mushrooming venture capital industry and hordes of tech entrepreneurs.

Microsoft to Open Source the .NET Micro Framework

Tue, 17 Nov 2009 00:30:00 EST

(I'm currently in Tokyo, so I'll leave my insights into this news for another time)

Today, at the Microsoft Professional Developer Conference (PDC) in Los Angeles, Microsoft announced the release of version 4.0 of the.NET Micro Framework, but also that they are open sourcing the product and making it available under the Apache 2.0 license, which is already being used by the community within the embedded space.

The .NET Micro Framework,a development and execution environment for resource-constrained devices, was initially developed inside the Microsoft Startup Business Accelerator, but recently moved to the Developer Division so as to be more closely aligned with the overall direction of Microsoft development efforts.

See complete blog post here >

Apache Software Foundation Completes 10 Years

Wed, 09 Sep 2009 02:25:00 EDT

Apache Software Foundation (ASF) was founded in June 1999. A list has been published that's a presentation highlighting top 11 Apache projects and also 10 projects for the future. Hadoop is the project to watch out for because it is inspired by Google Map Reduce and Big Table. 11 Apache Technologies that Have Changed Computing in the Last 10 Years 10 Apache Technologies that Will Change Computing in the Next 10 Years 1. Apache HTTP Server 1. Hadoop For building scalable 2. Tomcat Application [...]

Control Your NAS like You Control Your SAN

Fri, 10 Jul 2009 11:15:00 EDT

I was pondering over the weekend the concept that a SAN is relatively easy to manage – at least on the surface – because it is, in essence, a network in and of itself. Separated from the IP network, you have a switch that connects various SAN arrays and when your arrays become over-burdened, you can just drop another one in and plug it into the switch. Easy. And since the switch is not generally from the same vendor as the storage array, you can plug in whatever array you find most appealing this week. Migrating data between arrays can be tricky, but these days there are solutions for that. Initialization can be painful, particularly if you want to add it to an existing pool and distribute data across it like it had always been there or you’re using at-rest encryption, but that’s just time you have to wait while it runs, your staff isn’t required unless something goes wrong.

Stress & Load Testing Web Apps (Even ADF & Apex) Using Apache JMeter

Wed, 24 Jun 2009 11:00:00 EDT

A couple of years ago I presented Take a load off! Load testing your Oracle Apex or JDeveloper web applications at OOW and AUSOUG. I can't recommend enough the importance of stress testing your web applications, it's saved my bacon a number of times. Frequently as developers, we develop under a single user (developer) model where concurrency issues are easily avoided. When our programs hit production, with just 1 more user, suddenly our programs grind to a halt or fall over in bizarre places. Result, pie on developers' faces, users' faith in new technologies destroyed, and general gnashing of teeth all round. Some simple stress and load tests can head off problems way before they hit production.

(For the remainder of this post I'll infer "stress testing" and "load testing" as the same thing, though strictly speaking one tests for your application falling over, and the other how fast it responds under load)

So how to go about stress testing a web application?

There are numerous tools available to stress test web applications, paid and free. This post will look at the setup and use of Apache's JMeter, my tool of choice, mainly because it is free! ... to undertake a very simple stress test. Apache JMeter is available here, version 2.3.3 at time of writing.

On starting JMeter (<jmeter-home>/bin/jmeter.bat on Windows) you'll see the following:

Creating a Thread Group

From here what we want to do is set up a Thread Group that simulates a number of users (concurrent sessions), done by right clicking the Test Plan node -> Thread Group option. This results in:

As you can see the Thread Group allows us to set a number of threads to simulate concurrent users/sessions, loop through tests and more.

Creating HTTP Requests

From here we can create a number of HTTP requests (Test Plan node right click -> Add -> Sampler -> HTTP Requests) to simulate each HTTP request operation (Get, Post etc), HTTP headers, payloads and more. However in a standard user session between server and browser there can be a huge array of these requests and configuring these HTTP requests within JMeter would be a major pain.

Configuring the HTTP Proxy Server

However there's an easier way. Apache JMeter can work as a proxy between your browser and server and record a user's HTTP session, namely the individual HTTP requests, that can be re-played in a JMeter Thread Group later.

To set this up instead right click the Workbench node, Add -> Non-Test Elements -> HTTP Proxy Server:

To configure the HTTP Proxy Server do the following:

* Port – set to a number that wont clash with an existing HTTP server on your PC (say 8085)
* Target Controller – set to "Test Plan > Thread Group". When the proxy server records the HTTP session between your browser and server, this setting implies the HTTP requests will be recorded against the Thread Group you created earlier, so we can reuse them later
* URL Patterns to include – a regular expression based string that tells the proxy server which URLs to record, and those to ignore. To capture everything set it to .* (dot star). Be warned that during recording however, if you use your browser for anything else but accessing the server you wish to stress test, JMeter will also capture that traffic. This includes periodic refreshes by web applications such as Gmail or Google Docs that you don't even initiate; I'm pretty sure when replaying your stress test, Google would prefer you not to stress test their infrastructure for them; stick to your own for now ;-)

The end HTTP Proxy Server setting will look something like this:

You'll note the HTTP Proxy Server has a Start button. We can't use this just yet.

Configuring your Browser

In order for the JMeter HTTP Proxy Server to capture the traffic between your server and browser, you need to make some changes to your browser's configuration. I'm assuming you're using Firefox 3 in the following example, but same approximate steps are needed for Internet Explorer.

Under Firefox open the Tools -> Options menu, then Advanced icon, Network tab, Settings button which will open the Connection Settings dialog.

In the Connection Settings dialog set the following:

* Select the Manual proxy configuration radio button
* HTTP Proxy – localhost
* Port – 8085 as per the JMeter HTTP Proxy Server option we set earlier
* No Proxy for – ensure that localhost and 127.0.0.1 aren't in the exclusion list

The above setup makes an assumption that the server you want to access is accessibly without a further external proxy required.

Recording your HTTP session

Once the browser's proxy is setup, to record a session between the browser and server do the following:

1) In Apache JMeter hit the Start button on the HTTP Proxy Server page
2) In your browser enter the URL of the first page in the application you want to stress test

Thereafter as you navigate your web application, enter data and so on, JMeter will faithfully record each HTTP request between the browser in server against your Thread Group. This may not be immediately obvious, but expand the Thread Group and you'll see each HTTP request made from the browser to server:

As can be seen, even visiting 1 web page can generate a huge amount of traffic. Ensure to stop recording the HTTP session by selecting the Stop button in the JMeter HTTP Proxy Server page.

Configuring the Thread Group for replay

Once you've recorded the session in the Thread Group there are a couple of extra things we need to achieve.

For web application's that use Cookies and session IDs (JDeveloper's ADF uses a JSessionID for tracking sessions) to track each unique user session, we cannot replay the exact HTTP request sequence with the server through JMeter, as the session ID is pegged to the recorded session, not the upcoming stress test sessions.

To solve this in JMeter right click the Thread Group -> Add -> Config Element -> HTTP Cookie Manager. This will be added as the last element to the Thread Group. I usually move it to the top of the tree:

Next we need to configure the Thread Group to show us the results of the stress test. There are a number of different ways to do this, from graphing the responses, to showing the raw HTTP responses. In this post we'll take the later option.

Right click the Thread Group -> Add -> Listener -> View Results in Tree, which will add a View Results in Tree node to the end of the Thread Group:

Finally save the Thread Group by selecting it in the node tree, then File -> Save.

Running the Thread Group

To commence your first stress test run, it's best to leave the number of spawned sessions to 1, just to see the overall test will work in it's most basic form. The default Thread Group number of threads is set to 1, so there is no need to make a change to do this.

To run the test, simply select the Run menu -> Start. On running the Thread Group, you'll see the top right of JMeter has a little box that tells if it's still running, and the number of tests to go vs total number of tests:

Once the tests are complete, this indicator will grey out.

We can now visit the View Results Tree:

This shows the HTTP requests that were sent out and on selecting an individual request, you see the raw HTTP request and the actual response. You'll note the small green triangles showing a successful HTTP 200 result. If different HTTP errors occur the triangles show different colours. Also remember that sometimes application errors don't perculate up to the HTTP layer in your web application, so you should check your application's logs too (in the case of a JEE application, this will be your container's internal logs).

Running a Stress Test

The obvious step from here is to change the Thread Group number of threads to a higher number.

From here take time out to explore the other features in JMeter. It includes a wide range of features that in particular make it useful for regression testing.

Caveats

Firstly remember when doing this you're not only stress testing your application, your stress testing a server, potentially stress testing databases, stress testing your networks and so on. Therefore you can have an affect on anybody sharing those resources. "Hard core" stress tests should be on separate infrastructure, after hours, aiming for as little impact on those around you!

Also keep in mind, besides seeing your application fall over at 2 users, 10 users, 100 users, which is an important test, try to be realistic about your stress tests. Stress testing you're brand-new-application to a 1 million concurrent users is probably not being realistic. How many concurrent user requests do you really expect and what response times do you need? Normally when I ask managers this question they'll answer with, "oh we have 1000 concurrent users, the application must support that many at any one time". However what they really mean is the application has 1000 users, potentially all logged into the application (ie. sessions) at the same time, but not necessarily hitting the server with HTTP requests at any onetime.

Cloud Spending To Be Up 21% This Year: Gartner

Sun, 12 Apr 2009 07:00:00 EDT

Gartner thinks that global revenues from cloud computing will surge 21.3% this year and top $56 billion, according to Reuters reporting from Finland. IT spending is obviously shifting in search of cost-effectiveness as the economy goes to hell.

Java for Managers -- What Should They Know?

Mon, 09 Mar 2009 22:00:00 EDT

Last month, JavaBlackBelt completed a survey where developers said their teams would be 25% more productive if their management committed to skills management... which led me to consider: Which Java technologies do developers think that managers should understand better in order to make great decisions about skills management?

As Enterprise RIA Development Market Mushrooms, Marc Fleury Joins Board of Appcelerator

Sun, 06 Jan 2008 12:00:00 EST

Appcelerator CEO Jeff Haynie is quoted as saying about Fleury, 'We believe the knowledge he developed building JBoss, to the point where it quickly became a true challenger to much larger competitors and a substantial industry force, will be invaluable to Appcelerator as we look to achieve similar dominance in our pursuit of the enterprise RIA development market.' According to Fleury the company delivers cross-platform functionality on the server side, supporting the .NET, Java, Ruby or PHP architectures. On the client side, its RIA widgets are standards-based and portable across browsers.

Debugging Both Flex and Tomcat Java Programs in Eclipse

Wed, 14 Nov 2007 08:15:00 EST

If you use Adobe Flex Web applications that connect to Plain Old Java Objects on the server side, chances are you use a popular, robust, and freely available server called Apache Tomcat. If you use Eclipse-based Flex Builder, you can smoothly debug both Flex and Java code without leaving Eclipse. Flex Builder debugger does not need any special configuration. But we need to add a couple of parameters to the startup routine of Tomcat so it'll engage the Java Platform Debugger Architecture (JPDA), which will allow other applications attach to JVM that runs Tomcat and debug deployed Java classes remotely.