Rishi Verma's Community Grids Lab Blog

NMI Testing notes

2008-04-07T12:43:00.000-07:00

Here are a list of things I had to do to get the OGCE build running on NMI:

Copy my own maven tar ball over to the NMI machine. For some reason, using the OGCE's bundled maven caused problems

NMI checking java pre-reqs for various platforms

2008-03-28T14:39:00.000-07:00

If you want to check which version of java a given platform provides, use the following command:
nmi_list_prereqs --platform= java

Here's a handy PERL script that goes through a whole list of platforms and tells you if they support a specific java version. You can easily modify it to just display the platform version.

#!/usr/bin/perl

# Author: Rishi Verma

# PURPOSE:
# This script goes through a list of platforms, checks whether each platform suppports
# a specific version of JDK, and prints the result (yes, no) onto the screen.

$jdk_version = "java-1.5.0_08";
$counter = 1;

# array for all non-mac platforms
@non_mac_platforms = ("x86_64_fc_4", "x86_64_fc_5", "x86_64_rhap_5", "x86_64_rhas_3", "x86_64_rhas_4", "x86_64_sles_8", "x86_cent_4.2", "x86_deb_3.1", "x86_deb_4.0", "x86_fc_2", "x86_fc_3", "x86_fc_4", "x86_fc_5", "x86_rh_7.2", "x86_rh_8.0", "x86_rh_9", "x86_rhap_5", "x86_rhas_3", "x86_rhas_4", "x86_slc_3", "x86_sles_8", "x86_sles_9", "x86_slf_3", "x86_suse_10.0", "x86_suse_10.2", "x86_ubuntu_5.10");

# go through each platform, check if jdk_version exists for it, and print yes or no
foreach(@non_mac_platforms)
{
$output = `nmi_list_prereqs --platform=$_ java`;

if ($output =~ /$jdk_version/)
{ print "$counter) Platform: $_ supports $jdk_version ? => YES\n"; }
else
{ print "$counter) Platform: $_ supports $jdk_version ? => NO\n"; }

$counter++;
}

XBaya load problem

2008-03-26T09:35:00.000-07:00

XBaya doesn't seem to launch properly coming straight out of the box (as part of OGCE).

PROBLEM:
I keep getting the following:
An error occurred while launching/running the application.
Category: Launch File Error
The field codebase has an invalid value: @HOST_BASE_URL@/xbaya/

I tried changing the value of "@HOST_BASE_URL@" to "${host.base.url}" in xbaya.jsp and xbaya.jnlp (in portlets/xbaya/src/main/webapp), but this yields pretty much the same problem.

SOLUTION:
In tomcat/webapps/xbaya/ open up xbaya-final.jsp and xbaya.jnlp, change "@HOST_BASE_URL@" to "http://localhost:8080".

Proxymanager GFAC credential problem

2008-02-29T15:05:00.000-08:00

To try and resolve the proxy credential mismatch between proxy-manager portlet and gfac, I tried just manually deleting the following two jars from gfac deployment directory:

cog-jglobus, version: 1.2-050621
proxymanager-api, version: 4.3

No longer am I getting the old error (from GFAC Portlet) that I use to be getting - related to the portlet not being able to get a proxy credential, now I have a new problem when I first obtain a credential from proxy-manager and then try to open up gfac:

xsul.XsulException: The credential is not a Globus credential. at xsul.invoker.gsi.GsiInvoker.createPuretlsContext(GsiInvoker.java:51) at xsul.invoker.gsi.GsiInvoker.(GsiInvoker.java:43) at xregistry.utils.Utils.createWSIFClient(Utils.java:151) at xregistry.client.DocumentRegistryClient.(DocumentRegistryClient.java:82) at edu.indiana.extreme.gfac.external.impl.XregistryServiceWrapper.(XregistryServiceWrapper.java:49) at edu.indiana.extreme.gfac.external.ExternalServiceFactory.createRegistryService(ExternalServiceFactory.java:30) at edu.indiana.extreme.gfac.util.ui.GlobalContext.init(GlobalContext.java:117) at org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:251) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.gridlab.gridsphere.portlet.jsrimpl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:57) at edu.indiana.extreme.gfac.util.ui.ServiceMapGeneratorPortlet.doView(ServiceMapGeneratorPortlet.java:200) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:201) at javax.portlet.GenericPortlet.render(GenericPortlet.java:140) at org.gridlab.gridsphere.provider.portlet.jsr.PortletServlet.service(PortletServlet.java:387) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.gridlab.gridsphere.portletcontainer.impl.SportletDispatcher.include(SportletDispatcher.java:299) at org.gridlab.gridsphere.portletcontainer.impl.SportletDispatcher.service(SportletDispatcher.java:162) at org.gridlab.gridsphere.portletcontainer.PortletInvoker.service(PortletInvoker.java:187) at org.gridlab.gridsphere.layout.PortletFrame.doRender(PortletFrame.java:554) at org.gridlab.gridsphere.layout.PortletColumnLayout.doRender(PortletColumnLayout.java:51) at org.gridlab.gridsphere.layout.PortletRowLayout.doRender(PortletRowLayout.java:37) at org.gridlab.gridsphere.layout.PortletTableLayout.doRender(PortletTableLayout.java:193) at org.gridlab.gridsphere.layout.PortletTab.doRender(PortletTab.java:271) at org.gridlab.gridsphere.layout.PortletTabbedPane.doRender(PortletTabbedPane.java:330) at org.gridlab.gridsphere.layout.PortletTab.doRender(PortletTab.java:271) at org.gridlab.gridsphere.layout.PortletTabbedPane.doRender(PortletTabbedPane.java:330) at org.gridlab.gridsphere.layout.PortletPage.doRenderHTML(PortletPage.java:550) at org.gridlab.gridsphere.layout.PortletPage.doRender(PortletPage.java:453) at org.gridlab.gridsphere.layout.PortletLayoutEngine.service(PortletLayoutEngine.java:106) at org.gridlab.gridsphere.servlets.GridSphereServlet.processRequest(GridSphereServlet.java:270) at org.gridlab.gridsphere.servlets.GridSphereServlet.doGet(GridSphereServlet.java:138) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.gridlab.gridsphere.filters.GridSphereFilter.doFilter(GridSphereFilter.java:77) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.gridlab.gridsphere.filters.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:72) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595)

MySQL won't start problem

2008-02-29T11:29:00.000-08:00

Was trying to run MySQL, but came across a really annoying problem - it kept saying it couldn't find a "socket" file and thus wouldn't start.

eg.
> mysql
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

Here's how to fix it, just start the MySQL daemon again and all will work:

> /usr/local/mysql/bin/mysqld_safe &

Grid FTP / MDSS testing

2008-02-20T15:07:00.000-08:00

Time has come to test the file-manager portlet once again. I'm using the same "MDSSLoadTesting.jmx" file as before, just with slightly bigger files this time.

I have downloaded the files, and just need to run the test within JMeter. I need to add three accounts however to the OGCE portal: ogceUSER1, ogceUSER2, ogceUSER3.

Find out if something is running on port 8080

2008-02-20T14:58:00.000-08:00

For my remote NMI builds, there is a problem I am facing that the portal I am building won't start on port 8080 because it is "being used by" something else.

Here's a test you can perform automatically to verify if the port is indeed being blocked, and by what (use the "lsof" command). By the way this doesn't actually help me any for my NMI builds since the NMI machines don't have the "lsof" command.

echo -------- IS THE TOMCAT PORTAL ALREADY RUNNING, OR IS PORT 8080 BEING USED? ---------
# COMMAND TO FIND OUT WHAT IS RUNNING ON PORT 8080
lsof -i :8080

if test $? -ne 0; then
echo " => PORT 8080 IS FREE, NO PROBLEMO"
else
echo " => PORT 8080 IS BLOCKED, TRY SHUTTING DOWN TOMCAT SERVER"
portal_deploy/apache-tomcat-5.5.12/bin/shutdown.sh
fi

echo ------------------------------------------------------------------------------------

OGCE Local build/run tests almost done

2008-01-18T15:07:00.000-08:00

The build and JMeter run tests for the OGCE portal are almost done. I've got a script finished that builds the portal from scratch, runs the JMeter tests, and sends all the result files to SVN.

Things to do:

Try somehow to show the HTTP response errors for the JMeter modules that failed

Maybe give a URL link to the errors within the XML document?

Highlight the tests that failed within the XML document (via XSL stylesheets!)

Adding XSL stylesheet info line on second line of XML document

2008-01-18T12:59:00.000-08:00

Solution for #1:
Clip the ?xml...? first line from the XML document, and copy the rest of the XML file into a temporary file. Then insert XSL tag-sheet info as well as the XML document header (which you clipped) into the original file (overwrite the file). Finally, append the temp file's contents to the original file and voila! You've inserted the XML stylesheet info on the 2nd line of your file!

num_of_lines=`cat OGCEJMeterResults.xml | wc -l`

tail -n $[$num_of_lines - 1] OGCEJMeterResults.xml > OGCEJMeterResults-temp.xml

echo (THE XML AND XSL HEAD TAGS HERE) > OGCEJMeterResults.xml

cat OGCEJMeterResults-temp.xml >> OGCEJMeterResults.xml

rm OGCEJMeterResults-temp.xml

Local OGCE build/run test

2008-01-16T14:30:00.000-08:00

I'm setting up a local (non-NMI) build and run test of the OGCE framework.

Steps completed:
1) Script made that:
- svn checks out portal
- does a clean build on portal (maven, tomcat bundled)
- starts up portal on tomcat server
- runs JMeter test file against portal and stores results of test in XML file
2) XSLT Style sheet made that converts JMeter resultant XML output file into readable HTML

Things to do:
1) Auto insert XSL tag into the JMeter resultant XML output file (tag specifying the XSL stylesheet must but at the top of XML file to have it display properly):

2) Send the XML test results file and stylesheet to soureforge account
3) Store build text output in a file, and send to soureforge account

JMeter Load Testing - how to use the test file

2007-12-13T16:22:00.000-08:00

The following represents rough directions on how to do load testing with the mdss jmeter test file.

1) Open the file in JMeter (File->Open)
2) You will need to give the test file your MyProxy login information for the tests to work.
- In the left hand navigation, click on the HTTP request titled "Proxymanager (request proxy)"
- Enter your username in the username field, and password in the password field
3) If you want to increase the load, just add more users (and respective files to upload)
- In the left hand navigation, click on the "User parameters" link
- Click the "Add User" button at the bottom of the screen
- Add a corresponding "FileName", "usernameValue", and "mdssFileIndex" for each new user
- mdssFileIndex should be one higher than the corresponding value for the previous user
4) Decide on how many users you want to run this test with
- Click on the "Thread Group" link at the top of the left-hand navigation
- In the "Number of Threads" input box, enter how many users you want to run the test with (note: it is limited by the number of users you have specified in step number 3 above).
5) Run the test
- Click the "Run" dropdown menu at the top toolbar, then select "Start"
- The green square at the top right of the screen means the tests are still running
- To see the test results live, click on "View Results Tree" in the left hand navigation at the bottom
6) Analyze results
- Click on the "View results tree", "Graph Results" etc.. links in the left-hand navigation at the bottom to see statistics on the results of the test-run.

MDSS/BigRed Load Testing

2007-12-13T14:17:00.000-08:00

I am working on a JMeter testing file to test the uploading and downloading capabilities of the file-manager portlet via connecting to MDSS (HPSS) and BigRed.

Important notes of the testing scheme:
- Each "user thread" within JMeter represents a unique portal user who will upload, transfer, and download a unique file
- To do more intense load testing, just add new users and new files for those users. Right now the test is set up to have a maximum of 3 users
- Sending the file from MDSS to BigRed requires knowing the "index" of the file. These all need to be hard-coded. For example, for my MDSS account, the first file is hard-coded to be at index 12 in the file-manager list, the second file is index 13, and the next at 14.. and so on. This is the case because whenever you upload a file to MDSS, it gets placed at the bottom of the list. My mdss account had 12 files originally (index starts from zero), so after the first upload, the newest file was given an index of 12 (remember index starts from zero).

How to upload different files for each user thread in JMeter

2007-12-06T14:31:00.000-08:00

The way to have each individual JMeter thread (user) upload a different file to a remote web server is to add entries to the "User Parameters" module.

1) In your thread-group, Add Pre Processors > User Parameters to Thread Group
2) To add variables specific to each user, see: http://jakarta.apache.org/jmeter/usermanual/component_reference.html#User_Parameters

JMeter Load Testing on IU HPSS/MDSS

2007-12-06T14:26:00.000-08:00

Here is the scenerio I'm proposing:

Test files:
+ 1-10MB
+ 50-200MB
+ 1GB+

Steps in load testing:
1) Log into OGCE
2) Get MyProxy credentials
3) Open file-manager portlet
4) Open connection to BigRed on left
5) Open connection to MDSS on right
6) Upload test file to MDSS
7) Transfer test file from MDSS to BigRed
8) Delete test file from MDSS
9) Transfer test file from BigRed to MDSS
7) Download test file
8) Repeat step 6 with other test files

Random build failures with maven

2007-11-16T14:21:00.001-08:00

Some builds are seemingly failing at random, the cause is the fact that maven is downloading corrupted jar files during build time. A possible cause for this is network timeout.

What I am planning to do to correct for this is to try rebuilding the portal up to 3 times if the build fails. Below is script code for how to detect build failures and rebuild if necessary.
The key line is: "if test $? -ne 0; then"
This detects a maven build failure.

maven-2.0.7/bin/mvn -e clean install

if test $? -ne 0; then
echo ----------- MAVEN BUILD FAILED, TRYING AGAIN.. ATTEPMT 1 -----------
maven-2.0.7/bin/mvn -e clean install
fi

if test $? -ne 0; then
echo ----------- MAVEN BUILD FAILED, TRYING AGAIN.. ATTEPMT 2 -----------
maven-2.0.7/bin/mvn -e clean install
fi

if test $? -ne 0; then
echo ----------- MAVEN BUILD FAILED, TRYING AGAIN.. ATTEPMT 3 -----------
maven-2.0.7/bin/mvn -e clean install
fi

if test $? -ne 0; then
echo ----------- MAVEN BUILD FAILED, EXITING -----------
exit 0
fi

Crontab

2007-11-01T10:24:00.000-07:00

To get an NMI build running nightly, use a crontab as such:

1) Type:
> crontab -e
2) Enter the following into the crontab file:

MAILTO=youremail@domain.com
20 12 1 11 4 (. /nmi/bin/config.sh && nmi_submit <$HOME/yoursubmitfile.submit>)

The above crontab entry runs "nmi_submit <$HOME/yoursubmitfile.submit>" at 12:20noon, 1st day of the month, november (11), at 4th day of the week (thursday).
Consult this webpage for more details about cron: http://www.adminschoice.com/docs/crontab.htm

Build process steps for NMI

2007-10-30T11:58:00.000-07:00

These are the important steps for establishing nightly builds on NMI
1) Set your project name: OGCE
2) Make sure $JAVA_HOME is set correctly - currently I am setting it manually in my build scripts
3) Put email addresses in NMI submit file so that relevant people are informed
4) Add cron tabs for scripts

Problem compiling portal through NMI testbed on Linux distros

2007-10-26T09:59:00.000-07:00

For some reason, the portal will not compile on any of the NMI testbed linux distros; however, it will compile for macos_10.4

These are the types of compile time errors I was getting:

[WARNING] repository metadata for: 'artifact org.apache.maven.plugins:maven-clean-plugin' could not be retrieved from repository: central due to an error: Specified destination directory cannot be created: /home/vm1-user/.m2/repository/org/apache/maven/plugins/maven-clean-plugin
[INFO] Repository 'central' will be blacklisted
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

[INFO] Error executing ant tasks

Embedded error: Directory /home/vm1-user/.globus/GridPortRepository creation was not successful for an unknown reason

The reason for the above errors is that both the .m2 directory and the .globus directory are using the incorrect $HOME value. I fixed the .m2 repository directory path by modifying maven/conf/settings.xml

${env.HOME}/.m2/repository

The incorrect globus directory is all over the place, need to fix it still

NMI Build & Test issues

2007-10-05T14:56:00.000-07:00

I'm trying to build the OGCE portal on NMI framework, but I'm getting some problems.

The script I'm using is further down, but anyways whenever it tries to build using the script, I get the following error from maven:
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks

Embedded error: The following error occurred while executing this line:
/Users/condor/execute/dir_26580/userdir/ogce-portal-only/containers/gridsphere/gridsphere-2.1.5/config/build/build-compile.xml:22: /Users/condor/execute/dir_26580/ogce-portal-only/portal_deploy/apache-tomcat-5.5.12/common/lib not found.

----------------------------------------------
The script I made:

echo
echo --------- Which java are we running? ---------
which java
java -version

echo
echo --------- What about javac? ---------
which javac
javac -version

## Untar apache tomcat server and move it to portal dir ##
cd ogce-portal-only/portal_deploy
tar xzf apache-tomcat-5.5.12.tar.gz

## extract maven and move it to portal dir ##
cd ..
tar xzf maven*.tar.gz

## do the ogce portal maven build ##
maven-2.0.7/bin/mvn install

Grid Proxy/Credential set up

2007-09-18T14:05:00.000-07:00

Check list for making sure your grid-credential files and setup is correct:

Make sure you have non-expired grid credential files in your .globus directory

usercert.pem
userkey.pem

Be sure you have your proxy on myproxy.teragrid.org (or wherever you need to keep it)

myproxy-init -s myproxy.teragrid.org

Make sure your ".globus/certificates" folder has the right certificates files, get them from your CA's certificates folder and makes sure you have all of the ones listed in the CA's folder.
Remove any ".r0" files in your ".globus/certificates" folder. These are unnecessary.

Runtime error checking

2007-09-14T14:41:00.000-07:00

The question often arises, which error messages should one check for to make sure everything is working?
The following are the runtime error message patterns I am checking for using JMeter (via Assertion Response):

Portlet (gpir-browser-2) specific:

"Error message" <-- Appears in most exception messages
"An error has occurred!" <-- Appears in most exception messages
"Stack Trace:" <-- Appears in most exception messages
"Portlet Exception" <-- Appears in most exception messages
"at java.lang.Thread.run" <--- appears in most java exception messages
"Portlet unavailable!" <-- caused by a misconfigured portlet pom.xml file
"Error contacting web service" <-- caused by incorrect webservice URL in portlet.xml for gpir-browser-2 portlet
"The requested resource.*is not available" <-- caused by incorrectly configuring portlet in web.xml

Main gridsphere page specific:

"GridSphere portal failed to initialize!" <-- Caused by a misconfigured pom.xml file
"Stack Trace:" <-- Appears in most exception messages

Maintaining login session with JMeter

2007-09-14T10:42:00.000-07:00

I was facing a problem where I was testing my Gridsphere based portal with JMeter, but the only page that was getting recorded was the page immedietely after the login screen. All the other pages (when simulated using JMeter) only showed the login screen when they should have actually shown some content. Basically the problem was that the "login session" was not being maintained across the JMeter thread, and only the first page (because the user entered login/password information) showed up in JMeter's simulation.

The way to maintain "login session" is to add a "HTTP Cookie Manager" to the thread group.
Go: Thread Group->Add->Config Element->HTTP Cookie Manager

And select your browser type.

Fixed error of gridsphere not loading

2007-09-13T09:09:00.000-07:00

With Marlon's help, fixed the problem of getting to the Gridsphere login page, and seeing this error message:

GridSphere portal failed to initialize!

Unable to create portlet web application: portlets-driver Stack Trace:
Unable to create portlet web application: portlets-driver Caused by: Unable to load portlets from: portlets-driver + due to mapping error!

Problem was that I had run the command: mvn install from the "portlets" directory and not the root directory of the OGCE installation. So remember to always run mvn install or mvn compile from the top-most directory.

JMeter proxy w/ localhost server

2007-09-07T14:50:00.000-07:00

Seems to be some configuration problem. When I'm using JMeter's proxy, it only seems to record responses from non-local servers. For example, google.com and yahoo.com will record results in JMeter, but nothing from localhost seems to be recording.

Possible explainations:

JMeter only handles HTTP responses, ie only things from servers running on port 80 (but I have apache2 running on port 80, why doesn't anything record from that?)

JMeter proxy success

2007-09-07T10:05:00.000-07:00

I was able to get a JMeter test-plan to work via JMeter's proxy server.
I used the following tutorial to do it:
http://jakarta.apache.org/jmeter/usermanual/jmeter_proxy_step_by_step.pdf
A few questions still in my mind, hopefully I'll have an answer soon:

Why was it necessary to specify 'jakarta.apache.org' in the HTTP Request Defaults section? Does this make sure that only traffic to/from this server is recorded?
What is the aggregate report doing? What do the numbers mean exactly?

First Post

2007-09-06T10:35:00.000-07:00

This blog will include relevant discussion on JMeter testing, Grid Portlets, and NMI testbed.