Su instalación y ejecución es muy sencilla (debemos tener Java instalado). Descargamos la última versión desde la página de descargas de JMeter, que en el momento de escribir esta entrada es la 2.9 (que requiere Java 6 o superior). Descomprimimos el paquete descargado en un directorio a nuestra elección y dentro de la carpeta /bin de dicho directorio ejecutamos jmeter (.bat si estamos en Windows y .sh si estamos en Linux o Mac).

En la ventana principal de JMeter, observamos en la parte izquierda el «Plan de Pruebas» y el «Banco de Trabajo». Si nos situamos sobre cualquiera de ellos, con el botón derecho del ratón nos aparecerá el menú contextual que nos permite añadir componentes sobre cada uno.

Sobre el «Plan de Pruebas» lo habitual es añadir un «Grupo de Hilos» (Añadir / Hilos (Usuarios) / Grupo de Hilos). Un grupo de hilos representa el número de usuarios que ejecuta nuestro plan de pruebas. Para las primeras pruebas lo dejaremos sin tocar, es decir, con un hilo que realiza un único bucle.

Sobre el «Grupo de Hilos» añadiremos las peticiones que irá realizando cada uno de los hilos. Como hemos dicho lo más habitual es que sean peticiones HTTP, por lo que añadiremos una «Petición HTTP» (Añadir / Muestreador / Petición HTTP).

En la imagen superior vemos que en la «Petición HTTP» podemos poner los parámetros de una petición: servidor, protocolo, método (GET, POST, etc.), ruta y demás. Por ahora ponemos:

• Servidor: google.com
• Método: GET

En el «Grupo de Hilos» también añadiremos un «Informe Agregado» (Añadir / Receptor / Informe Agregado). Esto nos creará un pequeño informe con los resultados de la prueba. Hay otros muchos receptores que incluyen gráficas, detalles de la petición y respuesta, etc.

Es aconsejable que guardemos nuestro plan de pruebas desde el menú Archivo / Guardar Plan de Pruebas como.

Ahora si pulsamos el botón Arrancar (o desde el menú Lanzar / Arrancar) ejecutaremos nuestra primera prueba con JMeter. Si seleccionamos el «Informe Agregado» veremos los resultados de nuestra prueba.

Como vemos podremos ver el número de peticiones (muestreos), los tiempos en milisegundos (media, mediana, máximo, mínimo y la línea del 90%), el rendimiento en páginas por segundo y en Kb por segundo. En nuestro primer caso los tiempos son todos iguales porque hemos hecho un único muestreo. Para limpiar los resultados pulsaremos el botón de Limpiar Todo o desde el menú Lanzar / Limpiar Todo.

Otro receptor que yo suelo usar sobre todo al crear los planes de prueba es el de «Ver Árbol de Resultados» (no confundir con el de «Ver Resultados en Árbol»), que permite ver todos los datos de la petición y de la respuesta. Por ejemplo en este caso apreciamos cómo hay dos redirecciones antes de la respuesta definitiva.

Y listo. Añadiendo más peticiones HTTP y modificando los hilos (más hilos y más bucles) ya podréis hacer unas pruebas reales (mejor contra vuestros servidores de prueba claro). Tened en cuenta que la máquina desde la que ejecutéis las pruebas también influye en el resultado, por lo que mejor que sea siempre la misma (para comparar resultados) y que en el momento de la prueba se dedique sólo a eso.

Estad atentos porque en breve publicaré una forma más cómoda para grabar las peticiones según navegamos en la web, así como algunos otros trucos y consejos para trabajar con JMeter.

Esto que es cómodo en principio, hay algunas ocasiones en que no es lo deseable. Por ejemplo si queremos ver si otro usuario tiene acceso.

Yo al final la manera más cómoda que he encontrado para eliminar esa caché es a través de la línea de comandos.

Para mostrar las unidades a las que estamos conectados:

net use

Para eliminar la caché de una de las entradas:

net use \\unidad /delete
net use \\ip /delete

También podemos eliminar todas las entradas:

net use * /delete

Podemos comprobar que las entradas se han eliminado.

Ahora si volvemos a intentar entrar en el recurso compartido nos volverá a solicitar el usuario y la contraseña.

Pongo el enlace a la ayuda completa del comando net use (en inglés ).

Espero este año 2012 poder actualizar algo más. No me pongo objeivos, pero peor que 2011 será difícil.

Por eso publico una imagen que circula por las redes sociales y que a mi modo de ver resumen muy bien el origen de los movimientos. Con el contenido de este manifiesto estoy completamente de acuerdo.

Prometo recuperar próximamente la temática del blog.

Si hace un año estaba bastante satisfecho de la marcha del blog, este segundo año no lo estoy tanto. Mi insatisfacción se refiere sobre todo a lo poco que he publicado este año. Cambios laborales y personales (mi segundo hijo) me hacen tener menos tiempo que dedicarle a esto. Sigo aprendiendo cosas pero no saco el tiempo para compartirlas con vosotros. Así que como propósito de enmienda o en grande en esa lista TODO tengo el conseguir ese tiempo para publicar al menos una vez al mes (lejos ya de la entrada o dos entradas semanales que me ponía como objetivo en un principio).

En cuanto a datos de acceso, sigo estando bastante contento. El promedio de visitas diarias ha subido y está en el entrono de las 80, con un record de 174 visitas en un día y 40.945 visitas totales. Para mí está bien.

En cuanto a temas, CakePHP sigue caliente (a ver si le dedico alguna entrada en un futuro próximo).

De nuevo daros las gracias a todos los que visitáis Tus Ceros y Mis Unos, ¡permaneced a la escucha!.

Partimos de un servidor Hudson instalado (y con una JDK y Ant configurados) y un proyecto que utilice Ant para su construcción (tendremos su build.xml que compila las fuentes y crea un jar por ejemplo).

Por ahora vamos a integrar tres herramientas de análisis estático de código: PMD, CPD (integrado en PMD) y FindBugs. Necesitaremos descargar y extraer en un directorio ambas herramientas.

Partimos de un script de Ant como el que sigue:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>	

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

</project>

Crearemos una nueva tarea en Hudson, introduciremos un nombre y seleccionaremos la opción de «Crear un proyecto de estilo libre».

Después seleccionaremos una JDK, configuraremos el control de versiones (en mi caso Subversion) y en la sección de «Ejecutar» seleccionaremos «Ejecutar Ant» e introducimos el nombre de nuestra tarea de Ant para compilar. Con esto ya podríamos lanzar la primera ejecución en Hudson para comprobar que funciona.

Para integrar los tres análisis voy a utilizar una misma estrategia basada en variables de entorno que nos permitirá que nuestra configuración Ant sea válida tanto en local como en el servidor Hudson. Para ello en la configuración de Hudson definiremos dos variables de entorno que apunten a los directorios de PMD y FindBugs.

Hecho esto modificamos el build.xml para incluir las nuevas tareas:

<?xml version="1.0"?>

<project name="TCYMU" default="compile" basedir=".">

	<property environment="env"/>
	<property name="src.dir" value="${basedir}/src"/>
	<property name="lib"	value="${basedir}/lib"/>
	<property name="classes"	value="${basedir}/classes"/>
	<property name="reports" value="${basedir}/reports"/>

	<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="cpd" classname="net.sourceforge.pmd.cpd.CPDTask">
		<classpath>
			<pathelement location="${env.PMD_HOME}/lib/pmd-4.2.5.jar"/>
		</classpath>
	</taskdef>

	<taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
		<classpath>
			<pathelement location="${env.FINDBUGS_HOME}/lib/findbugs-ant.jar"/>
		</classpath>
	</taskdef>

	<target name="clean" description="Limpia el proyecto">
		<delete dir="${classes}"/>
		<delete dir="${dist}"/>
	</target>

	<target name="cleanReports" description="Elimina el directorio de compilacion y destino">
		<delete dir="${reports}"/>
	</target>

	<target name="init" description="Crea el directorio de compilacion y destino" depends="clean">
		<mkdir dir="${classes}"/>
		<mkdir dir="${dist}"/>
		<path id="compile.class.path">
			<pathelement path="${lib}/*.jar"/>
		</path>
	</target>	

	<target name="compile" description="Compilacion" depends="init">
		<javac debug="on" srcdir="${src.dir}" destdir="${classes}" classpathref="compile.class.path"/>
	</target>

	<target name="pmd">
		<mkdir dir="${reports}"/>
		<pmd rulesetfiles="ruleset.xml">
			<formatter type="xml" toFile="${reports}/pmd.xml"/>
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</pmd>
	</target>

	<target name="cpd">
		<mkdir dir="${reports}"/>
		<cpd minimumTokenCount="50" format="xml" outputFile="${reports}/cpd.xml">
			<fileset dir="${src.dir}">
				<include name="**/*.java"/>
			</fileset>
		</cpd>
	</target>

	<target name="findbugs" depends="compile">
		<mkdir dir="${reports}"/>
		<findbugs home="${env.FINDBUGS_HOME}"
	              output="xml"
	              outputFile="${reports}/findbugs.xml"
	    	      jvmargs="-Xmx1024m">
			<sourcePath path="${src.dir}" />
			<class location="${classes}" />
		</findbugs>
	</target>

</project>

Las novedades que presenta son bastantes:

• Configuro la propiedad environment para tener acceso a las variables de entorno.
• Configuramos un nuevo directorio que albergará el resultado de los distintos análisis. Es el directorio que he llamado reports.
• Defino las tareas Ant que se incluyen con PMD y FindBugs mediante la etiqueta taskdef, y buscando los jars a través de las variables de entorno.
• Defino la tarea pmd indicando xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. PMD puede realizar análisis en base a un buen número de reglas. Podemos configurar las reglas que utilizaremos bien mediante etiquetas anidadas en la tarea Ant o mediante un archivo separado de reglas (lo que se indica en la tarea Ant como rulesetfiles). En mi caso he utilizado para probar la configuración que aparece bajo «Add some rule references to it» en la sección de crear un conjunto de reglas en la web de PMD. En el siguiente enlace podemos encontrar más información sobre la configuración de PMD.
• Defino la cpd de forma muy parecida a la de pmd. Se indica xml como formato de salida, el directorio que contiene el código fuente y el archivo de salida. Para CPD no hay archivo de reglas. En el siguiente enlace se puede encontrar más información sobre la configuración de CPD.
• Defino la tarea Ant para FindBugs. Además de directorio de fuentes y archivo y formato de salida, necesitamos indicarle el directorio de instalación de FindBugs y el directorio donde encontrar las clases compiladas ya que FindBugs las utiliza para su análisis. Por este último motivo declaramos la tarea de findbugs dependiente de la de compilación. Más información en el capítulo de tarea Ant de FindBugs.

Para la integración necesitaremos instalar algunos plugins para Hudson. Iremos al apartado de plugins dentro de la configuración de Hudson e instalaremos Static Analysis Utilities, PMD Plug-in, Duplicate Code Scanner Plug-in y FindBugs Plug-in.

Por último modificaremos la configuración de nuestra tarea Hudson. En la sección de «Acciones para ejecutar después» activaremos el visualizador de PMD, CPD y FindBugs. En la configuración de ant lanzaremos las tareas cleanReports, pmd, cpd y findbugs.

Tras mandar a Hudson que nos ejecute el proyecto obtendremos una salida similar a la siguiente:

y podremos ver detalles de nuestro análisis siguiendo los enlaces:

Hasta aquí esta entrada que seguro no será la última sobre Hudson, seguid atentos.

Parece ser que en Oracle RAC la URL de conexión a la BBDD mediante JDBC no permite una de sus versiones clásicas. Así por ejemplo una conexión del estilo:

jdbc:oracle:thin:@<HOST>:1521:<SID>

no funciona saltando la siguiente excepción:

java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
The Connection descriptor used by the client was:
...

Para solucionarlo podemos utilizar la otra forma corta de url que aparece por ejemplo en este listado de formatos de conexión JDBC (en inglés ):

jdbc:oracle:thin:@//<HOST>:1521/<SID>

También podemos utilizar una URL en formato largo:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST>(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=<SID>)))

Si tenemos varios servidores deberíamos poner una URL en el siguiente formato:

jdbc:oracle:thin:@<HOST1>^<HOST2>:1521:<SID>

jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST1>) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=<HOST2>) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=<SID>)))

aunque esto último no lo he podrido probar lo he visto en el JUG de Padova (en inglés ).

Espero que le pueda servir de ayuda a alguien.

A veces se hace multiplicando pasando a entero y dividiendo, pero no es una forma fiable.

La forma de hacerlo sería mediante el método setScale de la clase java.math.BigDecimal:

public static double round(double value, int decimalDigits) {
	BigDecimal bd = new BigDecimal(value);
	bd = bd.setScale(decimalDigits, BigDecimal.ROUND_HALF_UP);
	return bd.doubleValue();
}

Tenemos varias opciones a la hora de redondear que podemos ver en la documentación de BigDecimal.

Espero que os ayude.

Este mensaje indica que en la respuesta a nuestra petición segura https se acceden algunas partes mediante el protocolo no seguro http. Esto es un riesgo de seguridad y por eso nos alerta.

Tras varias pruebas intentando localizar el contenido no seguro di con una gran entrada de Eric Lawrence sobre el tema del contenido no seguro ( en inglés) que me ayudó a solucionar el problema.

Por un lado desde el punto de vista del navegador podemos hacer que no nos aparezca la ventanita. Evidentemente no es la solución óptima el obligar a que el navegador no nos muestre un aviso de seguridad, pero para un aprieto (una demo por ejemplo) nos puede ayudar. Para ello abrimos las opciones del navegador («Herramientas->Opciones de Internet») y vamos a la pestaña de «Seguridad». En la parte de «Internet» pulsamos «Nivel personalizado…» y buscamos la opción de «Mostrar contenido mixto». Cambiamos de «Preguntar» a «Habilitar».

Como desarrolladores debemos preocuparnos de que si nuestra aplicación va a ejecutarse bajo https nuestras páginas no llamen a contenido no cifrado. Para descubrir si hacemos peticiones http podemos utilizar el Web Developer para Firefox o una buena herramienta que también descubrí gracias al post mencionado anteriormente como es Fiddler.

En nuestro caso y tras ver que no hacíamos ninguna llamada http descubrimos que lo que ocurría es la posibilidad que señala Eric en su sitio. Parece ser que Internet Explorer marca como contenido no seguro una llamada a JavaScript del estilo:

<br />
&lt;script type=&quot;text/javascript&quot; id=&quot;contentloadtag&quot; src=&quot;javascript:void(0)&quot; &gt;<br />

Con eliminar el parámetro src se solucionará el problema. Una de las librerías JavaScript que utilizábamos tenía una llamada de ese tipo.

Espero que os sea útil.

Si hacemos una comparación con Strings al estilo de:

<s:if test="propiedad == 'SI'">
  <div>Mostrar texto</div>
</s:if>

obtendremos el resultado esperado (mostrará el texto si nuestra propiedad vale «SI»), pero si la comparación es:

<s:if test="propiedad == 'S'">
 <div>Mostrar texto</div>
</s:if>

veremos que aunque nuestra propiedad valga «S» no aparece el texto. Es decir, que cuando hacemos comparaciones de Strings de un sólo carácter nos falla. La responsable es la librería OGNL que evalúa las expresiones ya que al encontrar se un sólo carácter lo toma como un tipo Char y no un String.

Para solucionarlo nos basta cambiar las comillas:

<s:if test='propiedad == "S"'>
  <div>Mostrar texto</div>
</s:if>

o bien escapar las comillas dobles:

<s:if test="propiedad == \"S\"">
  <div>Mostrar texto</div>
</s:if>

Espero que le pueda servir a alguien.