Log4j configuracion recomendada.


Configuración recomendada para un buen registro de log con slf4j

Introducción
Una buena configuración del log es fundamental para la identificación de problemas o comportamientos no esperados. Nosotros consideramos este un punto importante en los procesos de desarrollo, pruebas y puesta en producción de las diversas aplicaciones tanto como web, bash y/o aplicaciones de escritorio.

La idea de esta publicación es indicar la configuración más óptima de slf4j en el archivo log4j.xml y además excluyendo información relevante en la escritura de la información de log.

Entorno :
1.- Java SE 1.7 (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html?ssSourceSiteId=otnes)
2.- IDE Netbeans (https://netbeans.org/)
3.- Apache-Tomcat 7 (https://tomcat.apache.org/download-70.cgi)
4,- Apache-Maven (https://maven.apache.org/download.cgi)
5.- slf4j (http://www.slf4j.org/)
6.- Sistema Operativo (Linux Ubuntu)

Que es slf4j?

La mejor descripción la podremos ver el https://es.wikipedia.org/wiki/SLF4J
Slf4j es una abstracción de varios frameworks de logging que permite elegir el  framework concreto en tiempo de despliegue.

Las implementaciones son :
  • java.util.logging
  • log4j
  • logback
  • tinylog

En general utilizamos slf4j ya que dispone de varias características. La Principal y la que nombra a esta herramienta lo indica su nombre “Simple Logging Facade for Java”.

Consideraciones.

1.- Modificamos el pom.xml donde incluimos dentro del tag dependencies :
   
       
           javax
           javaee-web-api
           6.0
           provided
       
       
           org.slf4j
           slf4j-log4j12
           1.6.4
           compile
       
       
           org.slf4j
           slf4j-api
           1.6.4
           compile
       
   

2.- Crear archivo de configuración log4j.xml

log.png









3.- Contenido del log4j.xml

1.- Vamos a revisar el contenido de appender solo lo mas importantes :
File : Ruta y nombre del archivo que se generará.
/tmp : En este caso como usamos linux ya existe el directorio /tmp
${logTomcat} : En este caso en el inicio del tomcat definimos un parámetros que identifica a este.
debug_menu_web.log : Al final completamos el nombre del archivo de log que se generará.

MaxFileSize : Tamaño máximo en kilobytes de los archivos generados. Por ejemplo 5000kb equivalen a 5 megas

MaxBackupIndex : Cantidad máxima de respaldo de archivos de log ejemplo de máximo de 7 días. Importante ya que depende mucho del disco disponible en el servidor.

ConversionPattern : Patrón en el que se escribirán las líneas de log.

%d{ISO8601} %-5p (%t) [%c{1}(%M:%L)] %m%n

Descripcion :
%d{ISO8601} – displays the date and time in the ISO format (see earlier post about this norm).
%-5p – the log level (such as DEBUG, INFO, WARN, …), formatted to occupy five columns (I like when things keep in line).
%t – the name of the thread logging this line.
%c{1} – the name of the class calling the logger (the {1} argument is there to restrict the number of packages displayed; {2} would display one package level before the class name, {3} would display two package levels, … and %c without the brackets would display the full package and class names).
%M – the method.
%L – the line number.
%m – the message to log.
%n – begin a new line.

logConfig.png




Conclusión.

Codigo : https://git-scm.com/

Notas :
Nunca esta demas una herramienta que te permite migrar tu antigua aplicación a slf4j. Aquí les dejamos el link del manual.

Referencia :
https://archive.keyboardplaying.org/2013/06/24/log4j-conversion-pattern/

Levenshtein en postgreSQL


Muy Simple. Como utilizar levenshtein en postgres por ejemplo en buscar direcciones.

select
dire_calle_predio,
comuna_cod,
numero ,
levenshtein( dire_calle_predio , 'PUNTA ARENAS') as distancia
from direccion
order by distancia asc limit 10;



Tuning Servidor de Apicaciones (Apache-Tomcat)


En mi trabajo hemos arrastrado un problema de de rendimiento del servidor de aplicaciones (Apache-Tomcat), El que básicamente consiste en que si la maquina recibe muchas peticiones el contenedor web se pega y no es capas de resolver (En este caso solo nos queda reiniciar el contenedor). Dado este problema me propuse mejorar el rendimiento en de las maquinas. Desarrollo, Test, 2 maquinas de producción y una productiva de respaldo. para ejemplo les comentare de solo una.

Esta maquina tiene las siguientes características.
Procesador Intel(R) Xeon(R) CPU E5405 @ 2,00Ghz (2 núcleos y 2threads ) Memoria del 8gb
Sistema Operativo Red Hat Enterprise Server realiase 5,3
Servidor de aplicaciones Apache-tomcat-6.0.16
Versión de Java jdk1.6.0_25 (Ver la actualización de esta versión en http://www.oracle.com/technetwork/java/javase/6u25releasenotes-356444.html)

1. Lo básico: versión de JVM, modo de ejecución y tamaño de heap de Java 

El contenedor web esta configurado con los siguientes parámetros para el catalina_opts /apache-tomcat-6,0,16/bin/catalina.sh

-Xms1024
-Xmx1024
-Xmn512
-XX:PermSize=128
-XX:MaxPermSize=512

La razón de utilizar la versión jdk1,6,0_25 http://www.oracle.com/technetwork/java/javase/6u25releasenotes-356444.html http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html

2. Tuning del recolector de basura: corriendo en paralelo 

Por default, el Garbage Collector de la máquina virtual de Java usa el modo “serial” de recolección, pero esto sólo sirve en máquinas con un solo CPU. Para servidores de aplicaciones con 2 o más cores, tenemos la dos opciones (modos) :

El Modo paralelo
-XX:+UseParallelGC

modalidad de “pequeños impulsos frecuentes”. Esta opción disminuye un poco el rendimiento del sistema a cambio de no congelar la aplicación cada que se llena el GC.

-XX:+UseConcMarkSweepGC
ó -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC

Nota: La recolección paralela y la recolección de elementos nuevos son mutuamente excluyentes, así que al mezclar los tres pueden tenerse resultados inesperados:

Ver http://www.oracle.com/technetwork/java/javase/6u22releasenotes-176121.html

5. Tuning del recolector de basura: hilos de ejecución 

Por default, el número de hilos de ejecución asignados al GC son equivalentes al número de threads disponibles en el procesador. Sin embargo, esto puede ser muy ineficiente en sistemas con una buena cantidad de multithreading, siendo de 1/2 a 1 la proporción aconsejable.

-XX:ParallelGCThreads=6

6. Tuning del recolector de basura: incrementando la generación joven

Cuando se ejecuta un programa en Java, todos los objetos que se van creando pertenecen a tres generaciones, como se muestra en el siguiente esquema:
Las tres generaciones de objetos en Java. (Fuente: java.sun.com) Cuando se crea un objeto nuevo en Java con la instrucción new, éste inicialmente se encuentra en el espacio Edén (Eden space). Conforme se van ejecutando varios ciclos de recolección de basura o se van creando nuevos objetos, éstos van migrando a través de “espacios de supervivencia” (Survivor spaces) al ser copiados sobre áreas menos transaccionales de la memoria. La región tenured es la más importante pues en ésta se genera la mayoría de las operaciones en Java. Finalmente, aquellos objetos que han permanecido activos por mucho tiempo pasan a formar parte del espacio permanente (perm space) pues difícilmente serán eliminados.

Así entonces, en un ambiente altamente transaccional, es conveniente que entre el 6 y el 12% de la pila de memoria sea parte de la generación joven, pues se están creando muchos objetos en Java que serán migrados rápidamente. El tamaño por default es de apenas 2 MB y puede crecer de manera ilimitada, quemándose todo el espacio dedicado al tenured o perm, por lo que siempre es conveniente definir su tamaño explícitamente: 
-XX:MaxNewSize=64m 
-XX:NewSize=64m 

7. Tuning del recolector de basura: pasando de generación

en generación El parámetro -XX:SurvivorRatio puede utilizarse para ajustar el tamaño de los espacios de supervivencia. Aunque no es tan importante para el rendimiento, sí permite ayudarnos a definir cuál será el espacio para el resto de las generaciones, pues si son demasiado pequeños, los nuevos objetos serán copiados directamente en el espacio tenured y si son demasiado grandes, se está desperdiciando memoria. Por ejemplo, -XX:SurvivorRatio=6 significa que existirá una relación de 6 a 1 entre el Edén y los survivor spaces.

Por otro lado, la JVM define por defecto un “porcentaje de ocupación” del 50% del survivor space actual para empezar a copiar los objetos que contiene al siguiente espacio. Esto puede significar un desperdicio del 50% de la memoria designada a los survivor spaces, por lo que conviene incrementarla para hacer un uso más eficiente de la misma. -XX:TargetSurvivorRatio permite definir el porcentaje de uso necesario para copiar los objetos del actual espacio al siguiente:

-XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90

8. Tuning del recolector de basura: incrementando la generación permanente

Así como estamos definiendo un tamaño para la generación joven, también es posible definir uno para el espacio permanente (perm space) que en aplicaciones con muchos objetos estáticos y utilerías (sobre todo en Ajax) pueden generar el temido java.lang.OutOfMemoryError: PermGen space. Cabe destacar que si estamos encontrando constantemente errores de este tipo aunque incrementemos el espacio considerablemente (>25% del espacio asignado al heap), significa que tenemos un problema de objetos no recolectados que requiere echarse un clavado en el código.

-XX:MaxPermSize=128m

9. Paginación de la memoria 

El objetivo de la paginación en Java es optimizar los búferes de traducción y búsqueda en memoria (Translation-Lookaside Buffers – TLB). Estos son en pocas palabras, caches que almacenan los últimos mapeos de memoria virtual a física. Modificando los valores correspondientes se incrementa la eficiencia del uso memoria. En la mayoría de los casos no se recomienda pasar de 6 MB de paginación pues puede ser contraproducente.

-XX:+UseLargePages
-XX:LargePageSizeInBytes=5m

10. Non-Uniform Memory Architecture (NUMA)

Debido a que una buena parte de las arquitecturas multiprocesador están basadas en el uso de memoria de acuerdo a posiciones relativas a otro procesador o a través de memoria compartida entre procesadores, es posible utilizar una opción de “escopetazo” denominada NUMA. El uso de este parámetro en combinación con -XX:+UseParallelGC puede incrementar significativamente el desempeño:

-XX:+UseParallelGC
-XX:+UseNUMA

El detalle consiste en que algunas arquitecturas no soportan esta funcionalidad, por lo que el valor aportado por este parámetro debe ser comprobado después de una serie de pruebas de desempeño.

Deploy en caliente en servidor Tomcat 6.

Segun Tomcat 6 es posible hacer un deploy en caliente de una aplicación configurando algunos parámetros del contenedor.

Son dos los parametros que tenemos que considerar

antiJARLocking : If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false.

antiJARLocking is a subset of antiResourceLocking and therefore, to prevent duplicate work and possible issues, only one of these attributes should be set to true at any one time.

antiResourceLocking : If true, Tomcat will prevent any file locking. This will significantly impact startup time of applications, but allows full webapp hot deploy and undeploy on platforms or configurations where file locking can occur. If not specified, the default value is false.

antiJARLocking is a subset of antiResourceLocking and therefore, to prevent duplicate work and possible issues, only one of these attributes should be set to true at any one time.

Please note that setting this to true has some side effects, including the disabling of JSP reloading in a running server: see Bugzilla 37668.

Please note that setting this flag to true in applications that are outside the appBase for the Host (the webapps directory by default) will cause the application to be deleted on Tomcat shutdown. You probably don't want to do this, so think twice before setting antiResourceLocking=true on a webapp that's outside the appBase for its Host.

Esto es algo asi como "Bajo su propia responsabilidad" (No le aseguramos que funcione) Por esta razon no es recomendable para aplicar en Produccion. PLOP!!!!!

La verdad es que se es así, no me sirve de mucho. Pero bueno veamos que wea.

Estos parametros se pueden ingresar en dos partes

1.- En el context.xml de nuestro proyecto

2.- en el context.xml del contenedor [CATALINA_HOME]/conf/context.xml


La línea a agregar es :

< Context antiJARLocking="true" antiResourceLocking="true" ...

Pero cuidado como leimos arriba.

Calcular diferencias en días entre dos fechas

Estimados

Me presentaron el siguiente problema en el trabajo calcular entre dos fecha cual seria la diferencia en días de ambas.

Ejemplo :

public static void main(String[] args) {
// Crear una fecha new Date( 2010, 12, 11 ); Esta deprecada
Calendar cal = Calendar.getInstance();
cal.set(Calendar.DATE, 1);
// Enero = 0, asi que Diciembre = 11
cal.set(Calendar.MONTH, 11);
cal.set(Calendar.YEAR, 2010);

Date fecha1 = cal.getTime();
Date fecha2 = new Date();

Long dif = difDiasEntre2fechas( fecha1 , fecha2 );

System.out.println( "Dif " + dif );

}

/*
* getTime() Returns the number of milliseconds since
* January 1, 1970, 00:00:00 GMT represented by this Date object.
* http://download.oracle.com/javase/1.4.2/docs/api/java/util/Date.html#getTime()
* Ciendo Mayo fecha2
*/
public static long difDiasEntre2fechas( Date fecha1 , Date fecha2 ){

long difms = fecha2.getTime() - fecha1.getTime();
long difd=difms / (1000 * 60 * 60 * 24);

return difd;
}

Espero que les sea de utilidad.

Ahora si tienen un ejemplo mejor agradecería que me la envíen Saludos.

Tengo Prueba Jajaaaa..

Tengo una prueba lo bueno de estas pruebas es que me obligan a estudiar o repasar algunos conceptos por ejemplo en la prueba no pueden faltar las preguntas :

¿Qué es un interface?

¿Diferencias entre un interface y una clase abstracta?

interface Cloneable (Simple y compuesto)

¿Diferencias entre Runnable y Thread?

¿Defina que hace un método synchronizable?

Describa de ServletContext

Bueno también tendrán que mostrarme un ERROR. (Alguna Exception)

Espero que no me pidan hacer un modelo de objetos.



Por ahora voy a dejar esas no mas, ya que estoy en el terminal de buses. y por hoy se me ocurren esas no mas. :D

Saludos.

Distancia de Levenshtein [código]



La distancia de Levenshtein es una herramienta muy potente y aplicada en diferentes correctores ortograficos de editores de texto. La distancia de Levenshtein, que también es conocida como la generalización de la distancia de Hamming, determina la medida de similitud entre dos cadenas de caracteres.


Este algoritmo fue propuesto por Vladimir Levenshtein en 1965 y desde entonces ha sido ampliamente usado para realizar el matching entre cadenas de caracteres con diferente longitud.

La implementación eficiente de éste algoritmo requiere del uso de la programación dinámica puesto que implementa el uso de una matriz de tamaño (n + 1) × (m + 1), donde n y m son las longitudes de los cadenas que se comparan. Su implementación es sencilla y se las presento a continuación. (Esto no lo escribí yo, es un copi paste lo deje así ya esta clara la reseña sobre distancia de Levenshtein lo copie de aqui)

Un ejemplo en java desarrollado con netbeans.
http://www.2shared.com/file/oG5kzucg/Levenshteintar.html

Ahora mas fácil aun encontraran en la api de apache common land la clase StringUtils esta clase tiene un método getLevenshteinDistance

http://commons.apache.org/lang/api-release/org/apache/commons/lang/StringUtils.html#getLevenshteinDistance%28java.lang.String,%20java.lang.String%29

Sobre este tema hay mucha más información por ejemplo :

http://en.wikibooks.org/wiki/Algorithm_implementation/Strings/Levenshtein_distance
http://es.wikipedia.org/wiki/Distancia_de_Levenshtein
http://jc-info.blogspot.com/2009/03/distancia-de-levenshtein-codigo.html